Problems which cannot identified don’t get fixed. Here are some suggestions to make it easier:

• Provide proper role accounts in RIR whois records, including abuse role accounts.
• Be sure such account inboxes are read frequently by admins with the authority to fix the problems identified by reports to that address.
• Properly identify subnet clients and SWIP them when possible. For example, ARIN requires public identification records for /29 (8 IPs) and larger ranges (section 4.2.3.7.2.).
• Be thoughtful about what is used as the rDNS of a range. If it is possible for the rDNS to reflect the intended purpose of the IPs, it should: dynamic, static, commercial, shared, CGNAT, etc.

There are tools and services designed specifically with the needs of an abuse desk in mind. These two come highly recommended, and are used in production environments at large ISP/ESP abuse departments:

• Abacus (Commercial)
• RT Incident Response (Open-source)

Procmail can be extremely useful for sorting an inbound mail stream. For example, you could flag and sort any mail which had any of your IPs in it. You could bundle it into /24 chunks (or whatever works for you) and triage based on relative volumes. Spammers can even turn themselves in, that way.Grepcidr is another handy tool for finding IPs or IP ranges from within a file. You could “$ grepcidr IP.Range spam.file” to pull out all the IPs in that range from your file of spam and abuse reports, for example.

Filtering an abuse@ mailbox can be tricky because much of the mail which it should receive looks like spam. Content filters will hit on most spam reports. By filtering out spam reports, you risk not identifying a problem on your network. Spamresource.com offers some thoughts on how to deal with all the spam aimed at the abuse box.

There are any number of reasons why you may not be getting spam reports or Feedback Loop emails. Among them:

• Your abuse@ account is filtered so spam reports don’t get through. Or..it goes over quota, has insufficient retention capacity, inadequate search tools, isn’t read frequently or completely, or is otherwise dysfunctional.
• You use a free email account or host your abuse@ account on a service such as Gmail who filter spam reports into the spam folder.
• Filters are catching spam from your IP addresses before it hits reporting addresses.
• Users and ISP admins get tired of reporting spam and simply block it as soon as it’s detected, with no questions, comments or reports.
• The use of “disposable e-mail addresses” means those who use them aren’t seeing spam in their primary accounts, so it doesn’t get reported.
• Spammers have improved their listwashing methods to eliminate spam reporting addresses. Some ISPs aid that process by passing reports along to spammers without verifying that the root problem is fixed.

Spammers have many other means to wash away the symptoms of their polluted lists, while not fixing the basic problem (i.e., no confirmed opt in, no sunset policy, etc).

Laws regarding the Internet vary by jurisdiction; different countries each have their own laws which cover some abuses, but possibly not all. Police or court intervention is often far too slow to be effective at stopping Internet abuse. To effectively stop all abuse in a timely manner, each ISP must create and enforce a set of rules on all of their customers and users, often called an Acceptable Use Policy.

Those policies should be written into contracts with every customer of the ISP, and applied to the customers-of-customers and all other users of the ISP’s network, too. ISPs which want to maintain good relationships with other networks MUST enforce AUPs which prohibit abuse.

Spamhaus is not a law enforcement agency, nor does it claim to know all the laws in every country. Instead, we build our anti-spam lists based on our own published policies, which all of our users – including very large networks – agree with. Any network that wants to exchange e-mail (or other traffic) with Spamhaus users MUST enforce policies prohibiting abuse by all users of their network.

Dynamic IP ranges – dialup, DSL, cable, and fiber – are a huge source of spam. The users of those ranges are most vulnerable to attacks by viruses and proxy software which turn their computers into spam cannons.

Dynamic IP users on your network should send their mail out through your network’s outbound customer servers, or through other dedicated outbound “smarthosts” accessible via SMTP AUTH (authenticated) on port 587 as outlined in the RFCs: RFC4954 and RFC4409.

The best way to stop the massive amounts of dynamic IP spam is for your network to disallow access to port 25 on dynamic ranges, enabling SMTP AUTH on the smarthosts. The Messaging Malware Mobile Anti-Abuse Working Group, M3AAWG, has recommendations on port 25 blocking, available in various languages:

• Managing Port 25 for Residential or Dynamic IP Space
• Port 25-Management im dynamischen IP-Netzbereich
• Gestion du port 25 appliquée à l’espace IP dynamique ou résidentiel
• Gestión del puerto 25 en el espacio de direcciones IP fijas o dinámicas
• Управление портом 25 для стационарного или динамического IP
• 为住宅或动态IP空间管理端口25
• إدارة ميناء 25 للمساحة IP السكنية أو الديناميكي

But even if you cannot block port 25, most other networks would rather not accept any mail from dynamic ranges. To assist them with that, it is polite for your network to list your dynamic, end-user IP ranges in the Spamhaus PBL.

In addition to being a good Internet neighbor and helping other networks avoid spam from your users, listing your dynamic addresses in the Spamhaus PBL makes those ranges less attractive to spammers because they know they can’t deliver to networks that use the PBL.

Please add your dynamic IP ranges to those lists!

Users of dynamic ranges with blocked port 25 can connect with SMTP AUTH “SUBMISSION” protocol as outlined in RFC 2554.

What is needed:

• The ISP must configure its server(s) to accept SMTP AUTH connections on port 587; all modern mail servers support it. Don’t block dynamic users from port 587, and don’t use PBL or Zen on 587 connections! Don’t block your own users!
• Each end user must configure their mail client (MUA) to connect via SMTP AUTH on port 587 with username/password. All current MUAs have this function as an option; use the mail client’s “help” menu.

The advantages:

1. only authorized users can connect to your mail server
2. you know exactly what account is connecting
3. port 25 being closed is transparent to your end users, resulting in a seamless experience
4. infected devices and spammers can no longer anonymously abuse your network

Users with “SMTP AUTH” can then send mail from their computer via your server from anywhere they can connect. This is very good for travelers, like business people and students.

You should also consider filtering outbound spam on your mail server, possibly with something like http://spamassassin.apache.org/.

"Proxy" - any computer that can perform a function as a surrogate for another computer, under the control of a remote operator. They can be used to do many things, from email verification, to sending spam, to exfiltrating data or spreading malware.

The most common proxies seen in spam today are the millions of infected personal devices that make up the networks of abused “residential proxies” which transmit the spam via port 25 (they usually receive their commands on other ports).

This is an example of how one end user discovered that his doorbell was sending spam.

ISP admins need to be able to identify proxies, secure them, and block unauthorized access to them, and remove the software if necessary. Many trojan proxies do not show up with routine port scans, either operating on obscure high-number ports or using evasive mechanisms to avoid detection. Their filenames are not consistent. It may be necessary to do complete forensics, including packet sniffing and system monitoring, to identify the proxyware.

For many end-user systems, it is simply more effective to wipe the hard disk and reinstall a fresh system, or to pay a professional to clean the system.

Limiting outbound port 25 access to mail servers and disallowing access to all other devices is a good way to limit the damage to your own network and avoid a Spamhaus listing, but it does not protect your network against the remote operator of that proxy.

Phishing and malware spam is sent by criminals. They hijack mail servers to get good delivery rates, usually forging the sender address and constantly changing the IP of origin to avoid detection.

To solve the problem you have to identify and fix the security hole. You have to analyze the logs to figure out what the spammers did: In many cases malware or viruses may be involved, but not always. Simply checking your server and software clients for malware is generally insufficient. Understanding what is actually happening is the first critical step to understand (and fix) how it's happening. Just blocking the IP currently used to inject the malicious messages, or filtering the (forged) sender is not going to fix anything, and can at best only provide a short-term relief while you investigate.

By far the most common scenario:

• The spam has been injected into your mailserver from an external IP, using a valid username and password. Find the involved account from the mail logs and contact its owner to arrange mitigation.

How those credentials got into the hands of the bad guys is the fundamental question that needs to be answered, as that will dictate what needs to be fixed, and in what way.

Here are some possibilites to consider:

• The password could have been easy to guess. In such a case, the credentials would need to be changed, and the legitimate user needs to be informed of the new ones. This would be a good time to implement solutions to enforce minimum password complexity requirements.
• The legitimate user of the mailbox may have been compromised by malware of some sort: stealing credentials and providing them to the bad guys is one of the first things most malware does; these credentials can then be used for other purposes (spreading malware, operating financial frauds of various sorts, "simple" spamming, etc.).
  • In this case, simply changing the password will work only for a short time, as the new credentials will soon be exfiltrated to the bad guys again. Identifying and fixing the compromised system(s) and THEN changing the credentials once again is paramount to solving this situation.
• Depending on the affected setup, there may not be a "legitimate user" involved at all: the account might have been created by the bad guys directly, for example taking advantage of a "free account" policy, a misconfiguration, a 3rd party proxy installed on a device inside your firewall, etc.
• If for any reason you are unsure about which account account involved, then change all passwords, including those of much-abused role accounts such as admin or info or test.

It should be impossible for anyone external to your organization to use your server to send mail without permission. Your server should by default reject all mail attempting to “pass through” at the SMTP level without using SMTP authentication.

Sometimes no credentials have been compromised and the problem lies elsewhere:

The logs should always be checked to verify, before the following possibilities are even considered

• A (web?) application of some sort, or an entire server has either been abused or compromised, and the malicious mails are being generated directly from there; since the system originating such messages is considered "trusted", the malicious mails can just go through without any authentication involved. In this case, the only solution is identifying and fixing (or disabling) the application/system itself.
• The mailserver itself may be misconfigured to consider some systems as "trusted" where that shouldn't be the case, thus allowing bad actors to bypass security requirements such as SMTP authentication and simply inject malicious messages in the mailserver. This is (with several variations possible) a so-called "open relay". In this case the configuration error needs to be identified and corrected.

Do not forget to check the mail queues, and delete all the spam samples that may still be there waiting to be delivered. The SBL team can process a removal request for a listed phish source only after all of this has been done.

For a general perspective about this problem, you can also read this article.

Some Internet businesses use “affiliate” advertising: they pay a commission to partners who drive traffic to their website, for example. While such programs can be effective, they can also be attractive nuisances for spammers. If the spamming remains uncontrolled, such programs may have their IPs listed in SBL as spam support services (SMTP, HTTP, DNS). Here are some ideas for keeping spammers away from your affiliate program:

– Verify each affiliate’s real identity and check that they don’t have a spammy history before they are allowed in the program.

– Delay commission payments for 30 to 60 days and/or require paid-in-advance forfeitable damage deposit.

– Have a strong Acceptable Use Policy which prohibits spam and terminate promptly for spam with no payment nor refund of deposit. (see ISP General Questions)

– Maintain your role accounts and feedback loops and process them daily.

– Register affiliate sending IPs, domains and the domains they will use for URLs, and update www.abuse.net to report those domains to you (and the domain’s ISP).

– Monitor webserver logs for unusual traffic bursts from particular affiliates.

– Monitor “referer” headers in webserver logs for unusual traffic bursts from unexpected sources.

– Don’t accept HTTP referals from domains in domain blocklists, nor from IPs in SBL or XBL.

– Be suspicious of freshly registered domains and don’t allow anonymized whois or bogus registration info among your affiliates’ domains.

– Point URLs for terminated affiliates’ accounts to a “404” or similar non-promotional page which shows that you do terminate them and that you aren’t trying to drum up traffic via disposable spam accounts.

Reverse DNS (rDNS) consists of mapping IP addresses into hostnames. While most Internet applications do not require rDNS to work, there are several reasons why defining rDNS in your network is highly desirable:

• RFCs require certain standards for mail servers and rDNS using a fully qualified domain name (FQDN) is one of them.
• Publishing rDNS allows people to quickly and easily associate your IP address with your domain name, and therefore it makes easier to report abuse from your IP address space to your abuse desk (abuse@domain - all domains that send email must have a functional abuse@ address, per RFC)
• Publishing information about dynamically assigned IPs greatly helps other networks to distinguish the nature of different mail sources in your network (mail servers vs infected end user machines), and to block SMTP connections from dynamic addresses (if they wish to do so) without guessing and risking inadvertently blocking mail servers
• Publishing proper rDNS for statically assigned IPs – and in particular for those corresponding to proper mail servers – greatly reduces the likelihood that other networks will block those servers by mistake, thinking that the IP belongs to residential dynamic space
• Some networks are just refusing mail from IP addresses without defined rDNS
• On the client side, there are security benefits in running applications such as ssh from an IP with rDNS assigned