The Spamcop Blacklist
Spamcop.net is one of the oldest DNSBL's of the many that are offered today. Their services were first publicly offered in 1992, and continue on to this day. On January 4, 2007 IronPort agreed to become a division of Cisco Systems, making SpamCop a Cisco service. While SpamCop is primarily a DNSBL, they also offer other services as well, such as email filtering, in which you can have SpamCop behave as an email delivery pre-filter.
SpamCop uses many of the same techniques as other DNSBL's, such as spamtraps, honeypots, open relays, open proxies, whitelists, and blacklist ranges. However, the primary method by which SpamCop gathers it's listing data is from end users. End users are encouraged to forward copies of their spam into the SpamCop system. These emails are then analyzed; if the email meets certain criteria, the IP address of the sending SMTP server will be listed in SpamCops DNSBL.
SpamCop previously had issues in which large free email providers such as Gmail, AOL, Yahoo!, and Hotmail would get listed as a spam source. While technically these listings were accurate, the end users of the SpamCop DNSBL did not want to block email from such major providers. The solution at the time, was for email administrators to whitelist the IP addresses of the larger providers that had a tendency to become listed in the block list. It has been a long time since these tactics have been necessary. SpamCop appears to have a very solid internal whitelist, which has learned over time, which systems to ignore, and which systems to list.
Having your SMTP server listed in SpamCop requires spam to have originated from your SMTP server. The first phase in determining if an email is spam is done by a human. Subscribers of the SpamCop service, which do not necessarily need to be subscribers of the SpamCop DNSBL service, will deem an email as being spam. Once an email has been determined to be spam, a copy is forwarded to a unique email address given to them upon signup of the service. Some users will automate this process with scripts internal to their email client.
This forwarded email is parsed and compared against a number of internal SpamCop systems to determine the accuracy of an end users report.
In order to prevent abuse, one user notifying SpamCop of what they believe to be spam, is not enough for a listing to occur. Listings require multiple reports as well as triggering a number of other failsafes designed to prevent false positives.
Prior to listing, there is an assumption that the reporter may have made a mistake. The reported email is scanned to see if the sending SMTP server has previously been reported or listed, has been seen in a spamtrap or honeypots, has poor reputation points, is an open relay or open proxy, or if that server is on the SpamCop internal whitelist.
If after all tests, the email is still determined to be spam, the SMTP servers IP address will be listed in the SpamCop DNSBL zone. This listing will inspire notification emails to be sent to the [email protected] and [email protected] addresses of the domain holder, complete with delisting instructions. If no administrative action is taken, the IP address of the SMTP server will be listed for 12 hours, after which time, it will naturally expire from the system. Continuing reports against the same SMTP server can "freshen" the listing time.
It is worth noting, not all reports to SpamCop are done by end users, though the majority are. Some SMTP server administrators configure their systems to also report any spam they detect that SpamCop misses.
bl.spamcop.net will return the standard 127.0.0.2 ip address when queried if the SMTP server is listed.
Removal from SpamCop is one of the simpler processes compared to other DNSBL's. Given the notification email that regarding an IP listing, there is time to look into the problem, and solve it. Once you have prevented future spam infractions from happening on your server, an administrator can lookup their IP address, and trigger the SpamCop system to delist the offending IP address.
There are some conditions in which removal is not as expedient. A normal listing, one that is caused by an accidental misconfiguration of the SMTP server, or a compromised users account, is something that can be dealt with swiftly. On the other hand, if your SMTP server was involved in sending spam to a SpamCop spamtrap or honeypot, the removal process may take longer. Given the nature of spamtraps and honeypots, the chances of an accidental email delivery to one of these systems is near impossible. As a result, much higher scoring against the SMTP servers IP address will be incurred.