Even the most reputable senders, using strict, double opt-in methods, find it difficult to avoid spam traps. Bots place known spam trap addresses into every web form they can find that isn't image verified in an attempt to sway the use of this countermeasure or reduce the impact of a single hit. The idea is that if you can generate enough customer complaints about deliverability from reputable senders, gateways may reduce the impact on sender score of a spam trap hit. Using single opt-in forms makes you very susceptible to the insertion of spam traps. However, imagine the frustration of system administrators when they learn that their opt-in confirmation emails are hurting their sender-reputation. The only solution is to protect your opt-in forms with image verification.
Minding the Rules
The first spam traps were email addresses created and published in web pages, but never used in email subscriptions. If you were to email one of these recipients, it’s was assumed that you purchased a list from someone who scraped the address from a web page. In that case, you were in violation of CAN-SPAM rules. The sender reputation penalty for this is high. Only a few hits a day will reduce your deliverability at some major gateways. If you protect your opt-in forms, you should rarely send to one of these addresses. However, it does occur, since these are sometimes entered into forms by humans with bad intentions. Therefore, an occasional hit is tolerated.
Types of Spam Traps
Stale addresses are now used at some major gateways as spam traps. This is really a feedback handling test, but is often treated the same. If your email gateway attempts to deliver to a stale address multiple times, the recipient gateway will know your gateway isn’t handling feedback, since it sent you a delivery status notification warning you that the address was no longer valid. It’s assumed that multiple hits may occur before your gateway has a chance to handle the feedback, so the effect on sender reputation is less than a hit to an address posted in web pages. Feedback (bounces) handling is now a requirement in any sender gateway.
A Domain Name System (DNS) spam trap is a domain that is registered, but never used for email. If your email server attempts to deliver a message to one of these domains, the IP address of the server is logged when it does a DNS query for the mail exchanger for that domain. It’s concerning that an unintended consequence of this type of trap is that it can create a type of open relay in any gateway that allows localhost to relay. The mail exchanger query for those domains often return localhost as the address for the mail exchanger, so your server would route them to that address. Spammers now use a database of these traps to send messages through your server by making the envelope sender the intended recipient. This causes your server to create a delivery status notification to the intended recipient, most often containing the original email. This can seriously affect resource usage and sender reputation in your gateway, as this traffic is consistent and heavy now. If your gateway allows localhost to relay, you must make plans to change that.
Collecting a list of spam traps to use as a global “do not mail” list is futile. These addresses change and new ones are added all the time, and having to compare each recipient to the list would be a huge consumer of resources.
