Spam reports are an important mechanism to detect abuse occurring on or from your network. Reporting spam is a long and venerable tradition on the internet. Most ISPs consider well-crafted spam reports to be a favor to them; they want to know about the problem so they can fix it, before it becomes worse or listed in SBL. There are even specific abuse role accounts required by the RFC documents which are the blueprints of the internet.

A role account is an e-mail address which serves a particular function, not an individual person, for example "sales@" or "info@". Postmaster@domain (RFC2821) and abuse@domain (RFC2142) are the two role accounts which every ISP, webhost, mail service and DNS host must have in order to promptly identify spam and abuse related problems on their network. Networks which do not tolerate spammers are careful to look at their abuse mail every day and take effective actions to stop any problems which arise.

A Feedback Loop (FBL) is an automated stream of spam reports sent by prior agreement between individual receiving and sending networks, often based on a "This Is Spam" button in the user interface. FBLs are intended to help streamline and automate the spam reporting process with specific machine-readable parts. A standard Abuse Reporting Format (ARF, RFC5965) is specified and implemented for FBLs. ARF follows existing RFC2045 MIME standards for e-mail (and the earlier RFC1341). More about ARF is here and here.

DMARC records in your domain's DNS can help you detect spoofing or misuse of your domain used in spam or phishing. Some malware uses the domain of its local host when it spreads in spam, and DMARC could help you spot that infection on your server and clean it up.

A single spam report could be a fluke or someone reporting mail they actually signed up for, or it could represent 10,000 or more spam recipients. For wide-scale, pure-spam mailshots, the reporting rate is often even less than one in 10,000 due to filtering and "LART fatigue" of many who used to report spam. In general, hand-crafted reports are more likely to be actual spam than reports from automated http://tinyurl.com/kda37"This Is Spam" (TIS) buttons. Even TIS reports average in excess of 80% spam, though. Evaluate reports as you will; ignore them at the risk of your network's reputation and e-mail deliverability. (Ignoring them includes setting barriers to accepting them, such as imposing requirements like ARF, which is not supported by end-user mail clients, or DKIM or SPF, or content filtering your abuse mailbox.)

WARNING: FBLs can produce very high volumes of e-mail. Use a specifically designated e-mail account and allow plenty of disk space and server cycles to accept the full stream of reports. Some networks use a seperate server to accept the flow (for example, fbl@abuse.domain.tld). Do not apply content-based spam filters to FBL or abuse@ accounts or you will discard the very messages you need to keep your network clean.

Here are some tools which can help direct spam reports to your proper role account:

1. The Network Abuse Clearinghouse
Not a reporting service or FBL per se, but a database of correct addresses for spam reports based on domain. Registered users can send spam reports via its mail server, or anyone can query it to find reporting addresses for a particular domain. Since reports are not automated, volumes tend to be lower and reports hand-crafted. This may identify some of the more stubborn spam issues on a network, for example HTTP redirectors or DNS. See the Abuse.net website for instructions on using and updating its services.

1b. Abusix' Abuse Contact DB provides the Abuse point-of-contact (POC) from network whois records with an easy DNS query in inverse IP format, just like a DNSBL query. Check your network's IP-whois records to be sure you have registered an Abuse POC.

2. SpamCop
SpamCop reports the spam source, SMTP relay and spamvertised URLs in the message body based on IP. Registered users can use SpamCop to parse and report spam. A SpamCop feed might be high volume depending on your network size and output. The instructions on this page explain how anyone can receive SpamCop daily or hourly summaries about spam problems in specified IP ranges. For more information see the SpamCop FAQ for abuse-desks and administrators.

3. AOL Feedback Loop: http://postmaster.aol.com/tools/fbl.html
When AOL users click the "This Is Spam" button in their e-mail client, this system generates a "SCOMP" report to you. While it can be high-volume, it offers excellent feedback on proxies, virus infections and spammers on your network. You need to sign up for this free service with AOL. (And same with the MSN, Yahoo! and Outblaze systems, too.) AOL's whitelist info is here.

5. Microsoft (msn.com, live.com, hotmail.com) has Feedback Loops and other information for bulk mailers at http://postmaster.msn.com/. Their Smart Network Data Services includes delivery numbers and any Spamhaus Zen listings within your IP ranges at SNDS, "Junk Mail Reporting Program" FBL at JMRPP and other services. Senders may also be interested in this PDF to help their delivery.

9. "USA.net offers a feedback loop service, operated by Return Path, free of charge, to parties sending large amounts of mail to USA.net members. The feedback loop (FBL) will forward any mail reported as spam originating from the associated IP addresses back to the listed email address. We highly recommend the use of a dedicated e-mail address for this purpose." (Spamhaus: good advice for any FBL!) And, of course, http://postmaster.usa.net/.

Tip: Do not put your FBL or abuse@ account behind content-based spam filters. What's the point of filtering away the evidence you need to clean up your network?

Finally, be sure that your network has an enforcible Acceptable Use Policy (AUP) as a part of your contract with each and every customer! More examples are here. Seek legal counsel to ensure that your AUP will cover you in the event of account termination for abuse.

Provide proper role accounts in RIR whois records, including abuse role accounts. Be sure such accounts are read frequently by admins with the authority to fix the problems identified by reports to that address.

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 many spam reports. Filter out spam reports and 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.

But we're not seeing any spam reports!?

There are any number of reasons you didn't see spam reports before your IPs were listed by Spamhaus, or by other lists or networks. Among them:

You're not signed up for sufficient Feedback Loops. (scroll up for FBLs!)

Filters are catching spam from your IPs before it hits reporting addresses.

People, users and ISP admins, are tired of reporting spam and simply block it as soon as it's detected, no questions or comments. Sometimes called "LART fatigue".

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 also have many other means to wash away the symptoms of their ill-gotten lists while not fixing the basic problem (i.e., no opt in).

What can we do about accounts which are not breaking the law? (AUP)

Laws regarding the Internet vary by jurisdiction; different countries each have their own laws which cover some abuses, but possibly not all. Besides, police or court intervention is often too slow to be effective at stopping Internet abuse. To effectively stop all abuse in a timely manner, each ISP must enforce a set of rules on all of their customers and users, often called an Acceptable Use
Policy (AUP). Those policies should be written into contracts with every customer of the ISP and apply 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 against those other networks.

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, policies which all of our users--including very large networks--agree with. Again, any network which wants to exchange e-mail (or other traffic) with Spamhaus users
must enforce policies prohibiting abuse by all users of their network.

If you don't have an AUP yet you can use our free AUP builder to create one. Be sure to have your company lawyer adjust it so that you can effectively enforce the policies you need for your network's traffic to be acceptable to other networks.

We are an ESP and send lots of mail. What should we do about bad customers ?

Please refer to the Best Current Practices documents prepared by M3AAWG (Messaging Malware Mobile Anti-Abuse Working Group [MAAWG]):

What can we as an ISP do to prevent spam through compromised accounts?

User account compromises are a growing problem, especially with malware targetting specific services and providers for stealing of user login/password combinations. More information on this subject can be found in our blog article Spam through compromised passwords, can it be stopped?.

Dynamic IP ranges--dialup, cable, and DSL--are a huge source of spam. The users of those ranges are most vulnerable to attacks by viruses and Trojan Horse proxy software installed by virus infections which turn their computers into botnet zombie spam spewers. 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:
RFC2554,
RFC2476,
RFC4409.

The best way to stop the massive amounts of dynamic IP spam is for your network to filter port 25 on dynamic ranges, only allowing port 25 access to your smarthosts (or not even that, if your smarthosts use AUTH). The Messaging Malware Mobile Anti-Abuse Working Group, M3AAWG (formerly MAAWG), has its recommendations on port 25 blocking, available in various languages:

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.

Besides being a good Internet neighbor and helping other networks avoid spam from your users, listing your dynamic addresses in those lists makes those ranges less attractive to spammers because they know they can't deliver to many networks which use those lists, and you'll get proportionally fewer spam reports.

The ISP configures its server 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 user configures his or her mail client (MUA) to connect via SMTP AUTH on port 587, with username/password. All current MUAs have that as an option; use the mail client's "help" menu.

In Outlook and Outlook Express, the menus for that are something like this:

That way, only authorized users can connect to your mail server, you know exactly what account it is, and they bypass "port 25 blocking". Users with "SMTP AUTH" can then send mail from their computer via your server from anywhere they can connect, so it is very good for travelers like business people and students.

A proxy is any computer which can perform a function as a surrogate for another computer, under control of a remote operator. When an insecure proxy is used by spammers to transmit spam, that proxy computer is said to be "hijacked." The most common proxies seen in spam are the virus-installed trojans which actually transmit the spam via SMTP (they usually receive their commands on other ports). Other proxies used in spamming include web-cache and promiscuous DNS proxies, explained in this presentation in your choice of .ppt or .pdf formats. Currently, the most popular proxy protocols used by these virus-installed trojans are SOCKS4, SOCKS5 and HTTP-connect, but they may operate on any port. Increasingly, computers controlled by these virus-installed trojans -- "zombies" -- are parts of larger botnets controlled by criminal spam gangs and other Internet criminals.

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 malware.

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. The "SecCheck" tool at MyNetWatchman.com is an excellent starting point, highly recommended, easy to use and free!

What is a "honeypot" or "proxypot"? What is a "proxy hijack source" or "C&C"?

[hijack source/C&C]---(SOCKS)--->[zombie PC]---(SMTP)--->[spam rcpt]

Even more important than securing proxies is locating the proxy hijack source - the command and control (C&C) server for a botnet composed of many proxies (tens of thousands). These C&C servers are the actual originating source servers which send spam out through compromised proxy systems. The proxies hide the originating IP address from showing up in spam headers, of course, so you probably will not see spam reports, but special honeypots called "proxypots" identify the server motherships. Proxypots mimic a zombie PC, but unlike the zombie, they record the spammer's source IP. Spamhaus uses proxypots -- and other techniques -- to identify those C&C or proxy hijack servers.

To confirm those detections, as well as to monitor your own network routinely, every ISP should have the tools and skills to do traffic flow analysis. When you look at traffic flowing from a C&C server, you will see many connections on high-number ports to many destination IP address around the 'net - thousands and thousands of connections on unusual high-number ports! The destinations are almost always compromised proxies on end-user broadband networks. Be prepared with a good network monitoring tool to check traffic flows from suspected hijack servers. Some of the tools we've heard of include Tippingpoint, Fortinet, Sandvine, Packeteer, Allot NetEnforcer, Cisco's P-cube, and flow-tools for collecting and processing netflow data from Cisco and Juniper routers. Also see Stager for sorting and presenting data collected by those tools.

Network operators can also subscribe to a daily report of reported C&Cs on their network. ISOTF's "Drone Armies" research team posted a summary of their work on the NANOG mailing list and invited interested admins to contact them at c2report@isotf.org. Those reports show IP, time, domain, and port.

Spamhaus hears two common excuses given by proxy spammers to trick abuse admins. One excuse is a cover-up for that unusual traffic flow pattern, "We're doing VOIP." A closer look at the packets will disprove that. The other common exuse is "we removed the virus from the computer." Since it wasn't a virus causing the problem, that obviously doesn't stop the spam. Remember, these are dedicated servers with large lists feeding into them. And also remember, if it was a virus problem, you'd see that IP in spam headers. *wink*

Should an ISP use the XBL to block their own users since it means they have a virus or open proxy?

We're getting a lot of reports of spurious blocking caused by sites using the Spamhaus XBL to block authenticated access to smarthosts / outgoing email servers. The XBL is only designed to be used on incoming email, i.e. on the hosts that your MX records point to.

If you use the same hosts for incoming email and smarthosting / outgoing email, then you should always ensure that you exempt authenticated clients from XBL checks, just as you would for dynamic/dialup blocklists.

As your users are often on dynamic IP addresses, a user may be assigned an IP address from his provider that is in the XBL due to the virus or open proxy situation of a previous user of that IP address.

Another way of putting this is: "Do not use the XBL to block your own users".

Using the XBL to alert an ISP's security department when a user's IP is in the XBL is permissible and a good thing. But remember, that user may not be the one with the virus or open proxy problem.

Note: This also applies to using the XBL to deny access to web-forums, journals or blogs.

Should an ISP use the PBL to block their own users?

No! Spurious blocking caused by sites using the Spamhaus PBL to block authenticated access to smarthosts or outgoing email servers is very bad. The PBL is only designed to be used on incoming email, i.e. on the hosts that your MX records point to.

If you use the same hosts for incoming email and smarthosting or outgoing email, then you should always ensure that you exempt authenticated clients from PBL checks. As your users are often on dynamic IP addresses, a user may be assigned an IP address from his provider that is in the PBL.

Another way of putting this is: "Do not use the PBL to block your own users".

Note: This also applies to using the PBL to deny access to web-forums, journals or blogs.

Backscatter from spam firewalls and anti-virus systems

So-called "spam firewalls," software running in front of production servers to process out spam and viruses, can be a problem for other networks if they simply deflect the spam on to other mailboxes. Most spam and all mail-borne viruses use a forged Sender address, and bouncing it back to that address only results in sending unwanted and burdensome mail to innocent third parties. Either reject the SMTP connection with a 5xy message, silently discard it (your firewall identified it as spam, remember?), or file it in a quarantine area for *your* users to glean. Don't make it someone else's responsibility when they are almost certainly not involved.

The backscatter problem does not affect only spam firewalls though. Also regular MTAs can suffer of the same problem due to misconfigurations. The problem occurs every time a message is accepted from the original sender, then it is discovered that it can not be delivered for any reason and a non-delivery notification is generated and returned to the original sender. The problem is that the original sender is forged in spam, so those messages may go to someone who was not involved at all in the spam sending. The problem is solved by having the MTA detect that the message can not be delivered while the original SMTP transaction is still in progress, and reject the transaction without accepting the message. In this way, no mail will go to the forged sender.

On the Barracuda Spam Firewall, the option to turn spam bouncing off can be found in the Basic Tab under Spam Scoring. Near the bottom there is a check box for "Send Bounce." This is checked by default and should be unchecked. Instructions with screenshots are shown at http://postmaster.gtcs.com/CudaFix.php. Barracuda 300 may not have this option, but the 400 and 600 versions do have it. Barracuda Networks themselves have now published a document (pdf) on how to shut of this type of bouncing.

When using the amavisd-new content scanner, the configuration file amavisd.conf should contain:

Avoid the D_BOUNCE setting which is the one that causes problems. Note that the D_REJECT seeting has the same effect as a D_BOUNCE in a post queue filter. Thus D_REJECT should be used only for a pre-queue filter.

Note from the above example that the same principle applies to anti-virus notifications and bounces as well. If it's a virus, and it's after the year 2003, 99.9% of the time the return path will be bogus. DO NOT SEND IT THERE!

All that "backscatter" or "blowback" causes problems at the receiving end. Some sites see more than half their spam load due to blowback. Several techniques are available to minimize the impact of blowback spam.

Currently, the most effective protection is Bounce Address Tag Validation (BATV): "Bounce Address Tag Validation (BATV) provides a mechanism for assessing the validity of an email's envelope return (bounce) address. It permits the original submitter of a message to sign the SMTP MailFrom address. This enables detection of invalid bounce addresses."

My mail server is listed on the SBL as a phish spam source, what should I do ?

Phish spam is sent by criminals gangs usually based in Eastern Europe. They hijack mail servers to get good delivery rates, usually forging the sender address and constantly changing the IP of origin.

If you have this problem, you can not solve it by blocking specific IP addresses or email senders, or in general using filtering/blocking rules, antispam appliances, etc. The spammers exploited a security hole: it should be impossible for anyone external to your organization to use your server to send mail to arbitrary destinations. Your server should accept inbound mail or outbound mail, but it should reject at the SMTP level by default all mail attempting to "pass through".

So, to solve the problem you have to identify and fix this security hole. This should not be too difficult, because the spam was sent by your mail server and therefore evidences and traces have been left in the mail logs. You have to analyze the logs to figure out what the spammers did. If your mail server is Microsoft Exchange, see the FAQ entry below.

In most cases no malware or viruses are involved. Just checking your server and clients for malware is generally insufficient, usually not relevant and does not solve the problem. Obviously, blocking the forged sender address or the IP of origin also does not solve the problem, as those parameters are constantly changed.

These are the most common mechanisms exploited, approximately ordered by number of occurrences, and their typical resolution path:

(by far the most common) the spam was sent as authenticated mail, injected from an external IP using a valid username and password. Find the involved account from the mail logs and contact its owner.

if the password was extremely easy to guess, just change it.

if the password was difficult to guess, it was probably stolen by a keylogger trojan running on a client PC or laptop. Disinfect all the computers used by that person, then change the password.

If for any reason you are unsure about the account involved, then change all passwords, including those of much-abused role accounts such as admin or info. test is also heavily abused.The logs should always be checked to verify this point, before the following rare possibilities 2, 3, and 4 are even considered.

the spam was not authenticated, but it came from a PC or laptop internal to the LAN, as shown by the local IP address in the logs: clean that computer, as there is malware on it.

the spam was not authenticated and it came from a web server in your LAN. In this case, the spammers injected the message via HTTP using a security hole on the web server. Check the web logs for a confirmation, and close the hole.

the spam was not authenticated and it was injected via SMTP from outside: in this case, you have an "open relay" configuration. Fix it.

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

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

My Exchange server is sending spam, but it is not an open relay! What should I do?

(See also the previous FAQ entry).
Most likely, the spammers are sending mails by authenticating on your server as an ordinary user. They obtained a valid account/password pair either by guessing (because one of your passwords was simple and so it was discovered through a brute force attack), or through a keylogger program running on a trojaned PC or laptop of somebody using your server to send his/her mail.

Then, first of all, all the PCs and laptops used by the owner of that account should be checked for malware, as it is possible that the access credentials were stolen by a trojan program running on a client. This is likely if the password was not a very simple one (a very simple password was probably guessed).

Then, the password of that account should be changed to a new and secure one. After that, keep the logs monitored for a few days to make sure that the abusers can not access the server any more.

It's difficult to keep the dedicated 419 scam spammers off of an ISP's webmail, but there are some techniques to make it much harder for them.

Add some systems to minimize the ability to easily and quickly sign up for multiple webmail accounts. Limit new accounts from the same IP address in a small time period. Use CAPTCHA tests. Watch for patterns of abusive usernames (user1, user1, user3, A_user, B_user, etc.) and remove all names within that pattern as soon as detected.

Block IP ranges as needed, often quite aggressively. Afrinic ranges are frequently the source of 419 connections. 419ers will log in from the same Afrinic ranges, or sometimes even RIPE ranges, until they are blocked.

Rate-limit RCPT_TO (419ers load up To, CC and BCC fields...what legit webmail needs more than a dozen or so RCPTs?).

Dump mail with more than 10 lines in the .sig (used by 419ers to avoid other field limitations).

Keep up with abuse@ reports and adapt *quickly* to new attack vectors as they are reported.

Apply outbound filtering with properly adjusted tools such as SpamAssassin. ("Properly adjusted" means you probably need to optimize the parameters for your application.)

In 2014 and 2015 we are seeing lots of DNS set up on hacked machines, usually on systems in commercial hosting facilities. Forensics on these intrusions have been minimal; usually the box just gets wiped, or maybe some ports blocked, but the actual intrusion vector may not be determined. We'd like to hear more from anyone knowledgable in these intrusions. Here are some of the ways we have heard of DNS being set up to use IP addresses without the owner's permission:

1. TinyDNS installed illicitly. TinyDNS is excellent and perfectly legitimate DNS software, but it is also widely used by bad guys for these rogue DNS installations. They probably like its small size and fast performance, same as legitimate users. Any hack that allows content to be written to the box could be the vulnerability used to install it.

Fast flux domain hosting involves the use of botnet zombie drones on broadband IPs infected to act as reverse proxies for the spammer's website or nameservers. The spamvertised domain's A-record is pointed at a rapidly changing series of zombie IPs (hence the name) with very short "TTL" values, usually less than five minutes (300s). When both the A and NS RRs use that type of bot hosting it is referred to as double flux. There are typically four or five A records to distribute the load and increase the odds of the website staying up in case a bot crashes or is taken offline. The proxy action hides the IP location of the spammer's dedicated servers. As the very act of hijacking computers is illegal in most jurisdictions, such fast flux hosting is mostly used for further criminal activities such as phishing, malware and child exploitation. These criminals know they could be identified if they used valid whois info so they always use bogus data, so registrars can confidently HOLD (suspend) the domain based on ICANN 3.7.7.2.

It's a tricky way for a spammer to make their spam appear to come from a different IP than their dedicated server, but still on the same VLAN subnet.

To avoid the problem, design your VLAN so that:
- customers can't snoop on each other, even at broadcast level such as arp traffic;
- no customer can send out packets with any source IP other than their assigned one;
- no customer can generate ARP traffic for any IPs other than their own.

As for identifying what server it really is, can you put a port monitor on the switch port of your router and sniff its packets? You should be able to see the MAC address of anything returned from those IP addresses, even if they were injecting forged packets from somewhere else on the Internet. And you should be able to see the gratuitous ARPs.

This technique is in use in the wild. If you detect this on your network, Spamhaus would very much appreciate any details you can provide, including connection information for the spammer's "home base."

Note that the webmail module has been removed from the PHP-Nuke distribution due to its poor security since version 7.2 (march 2004). Using a more recent distribution of PHP-Nuke is of no help if the webmail module has been retained from a previous release, or has been downloaded later from some other site as an "add-on".

Also note that, according to user reports, it appears to be insufficient to disable the webmail feature to prevent the scammers from using it. You must delete the webmail module, causing removal of all the related files from the server.

Why should I worry about reverse DNS (rDNS)?

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:

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 to inadvertently block 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 their IP belongs to residential dynamic space

moreover, some networks are refusing mail from IP addresses without rDNS defined

on the client side, there are security benefits in running applications such as ssh from an IP with rDNS assigned

How do I get rDNS working?

You need to get a delegation of the reverse DNS zone, and then configure the zone. If your network is, say, 198.51.100.0/24, "getting a delegation" means having a NS record for 100.51.198.in-addr.arpa pointing to your nameservers, while "configuring the zone" means inserting the right information in the corresponding zone file in your nameservers.

Getting a delegation

You get a rDNS delegation from the same entity that gave you the IP addresses: it may be the ISP you are taking connectivity from, or the regional Internet registry of your area.

For general information about defining a reverse zone in your nameservers, see for instance
the APNIC guide or the RIPE pages linked above.

Note that you do not need to insert all the individual records by hand. If you are using Bind, once you have defined a naming convention for a portion of your space you can use the powerful $GENERATE directive (described in the Bind 9 manual) to define several records with a single line.
For instance, you can write in the 100.51.198.in-addr.arpa zone file:

Do not forget to check that matching forward A records are defined in the zone of example.net. This is very important because it "validates" the rDNS information. You can define them with another $GENERATE directive, like

Make it easier for other networks to identify your dynamic ranges, and thus to filter more appropriately, by using a fixed string like dynamic or dialup as a subdomain immediately below your main domain (also called "right anchored"). Put the geographical information (if it applies to your case) at the next level, and the most variable information (like the last octet of the IP) at the outer, left-most level. Use dots as separators rather than dashes or other symbols so as to create subdomains, and put the most variable information on the left-most part of the name. For instance, this is a good naming scheme:

123.adsl7.timbuktu.dynamic.example.com

Clearly the same information could be made available with another scheme like
dadsl7-123-tktu.example.com, but other people would have to define complex regular expressions to parse that, wasting resources and increasing the likelihood of making mistakes.

If you need to include the IP address or a part of it in the hostname, reverse the order of the octets, again to have the most variable information at the outer level. For instance, the reverse DNS for 203.0.113.167 should preferably be

167.113.0.203.timbuktu.dynamic.example.com

rather than 203.0.113.167.timbuktu.dynamic.example.com.

We also recommend to use similar conventions to identify static IPs and business connections as clearly as possible. For instance, you can use something like:

245.sdsl.timbuktu.business.static.example.com

Such a scheme helps your business customers to maintain good SMTP deliverability to other networks even when neighboring dynamic IP ranges are infected with bots and send spam. Assigning custom rDNS to properly identify mail servers of responsible customers is also a good practice, for example:

mail.example.com

My customer says it's not them; is that true or an excuse?

Some of the excuses commonly used by spammers and signs they are spammers:

- it was a customer of a customer or a reseller;
- it was affiliates (fake and real);
- the server was hacked (Sanford Wallace' "Hacker X" excuse)
- it's opt-in (the list they bought said so!);
- it's Double Opt In! We have IPs! (may come from "web bugs" in spam)
- it's not us, it's just our business model;
- moving servers around to new IPs or "morphing";
- using lots of domains, often with anonymized "whois";
- they turn servers back on as soon as the heat is off;
- spam is sent from a different network than their web hosting;
- using "VoIP" as an excuse to cover up proxy hijacking;
- insisting that proxy hijack software was installed by a virus (it's not; it is large, dedicated software installed intentionally by a server administrator to spam).

Other commonly seen tricks:

- redirector URLs on throwaway pages land at their "bulletproof" site hosted with you;
- VPN tunnels and port forwarding to hide from packet-sniffing (use traffic flow analysis);
- using multiple small blocks of IPs instead of a single aggregated block to camouflage spam sources, also used to game search engine optimization algorithms;
- asymetric routing via dynamic pools (rare);
- scripts installed on the same server as an MTA to send mail without leaving log tracks;
- firewalling the host's corporate IPs so the host can't see the spammer's website.

Steps to keeping your network free of spammers:

1. Review your new customers before you sell them accounts. Treat unusual requests with suspicions. If an offer sounds too good to be true, it probably is.

2. On your IP addresses, use "reverse DNS" which points to your domain.

3. Be sure to read "abuse@your domain" every day, and have your upstream provide you with spam reports sent to them about your IPs.

4. Establish "feedback loops" with SpamCop, AOL, and other networks as noted on this FAQ page (top), and read your role accounts every day.

5. When spam is reported, take prompt action to stop it.

6. Do not trust spammers; they are inherently dishonorable people.

7. Treat with extra suspicion clients who say their business involves "mailing".

8. Don't give mailer clients large IP address ranges and allow them to use port-25 out on every IP. Limit them with your routers or firewalls. AOL or Hotmail/MSN only use a handful of IPs for tens-of-millions of users and tremendous mail volumes; why would your client need more?

But I didn't receive any spam reports! Why not?

Some possible reasons you may not have seen spam reports before an SBL listing include:

Filtering stops most spam from reaching most mailboxes, so it never gets reported as spam.

LART fatigue: Many spam reporters have grown weary of trying to help ISPs keep clean houses and have stopped sending reports. Others report only to trusted ISPs.

You have a non-standard role account. The RFC2142 standard is abuse@domain. (See first item on this page.)

You haven't signed up for Feedback Loops (FBLs). (See first item on this page. Many first-time FBL subscribers get their server knocked down by the volume of such reports. Be prepared.)

Your abuse@ account is behind filters, particularly content filters, which filter out spam reports as well as spam.

Spammers have washed many reporting addresses out of their lists. Such third-party "suppression" lists are even available for sale. (Legitimate senders maintain legitimate suppression lists; they don't sell them.)

Spam services such as websites and DNS are reported less frequently than spam source. Other spam services such as spamming software or spam lists are reported even less frequently.

How do I control affiliate spammers?

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.

- 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. (That's mandatory for SBL removal.)

We're a USA based ISP and a spammer is threatening to sue us if we block his spam. Can he?

SEC. 4 (c)(1) ISP HELD HARMLESS FOR GOOD FAITH PRIVATE ENFORCEMENT- An ISP is not liable, under any Federal or State civil or criminal law, for any action it takes in good faith to block the transmission or receipt of unsolicited commercial e-mail.

Any spammer bringing such an action or threatening it probably knows the law very well. The filing of such an action could be considered a frivolous suit or a SLAPP suit. Based on this, one may wish to ask for additional punitive damages beyond the court costs when one requests the dismissal of any such suit.

"ARIN requires organizations to submit information for all IPv4 reassignments of /29 and larger and IPv6 reassignments of /56 or shorter prefix within seven days of the sub-delegation...There are two options for reporting reassignment information: SWIP and Rwhois."