Some months ago a number of bloggers wrote about The Spamhaus Project's "new" spamtraps. Some asserted that we were suddenly targeting transactional messages. Others noticed the timing of new SBLs based on those "new" traps and one concluded that we had decided to publish our advisories during the Christmas season, the time of year that retail companies see the bulk of sales and that would therefore most affect marketers. Links to a few of these blogs are provided below:

In addition to other sources of data, The Spamhaus Project uses all sorts of spamtraps; we haven't suddenly started using typo domains (domains a few characters different than a popular domain) as a data source. We have been doing this for well over a decade. Change is a constant at Spamhaus as elsewhere and some things did change around December of 2012. These included greater cross-referencing amongst our various spamtraps, closer communication amongst their maintainers, and greater machine analysis of spam headers.

Being leaders in the anti-spam community, we are often asked for our opinion and guidance in building and operating anti-spam systems. We have often stated that, when operating spamtrap farms, care should be given to identification of transactional messages, and they should be handled differently than other email sent to spamtraps. We do not list IP addresses because of one-off transactional emails sent to a few spamtraps. If the email stream is persistent over time, especially high volume, and drifts outside the relationship of individual transactions, we will start to find these messages a problem. An example of this is when the transactional email stream to the spamtrap also contains marketing messages.

The Spamhaus Project publishes advisories for its users. We attempt to list spam sources when spam is being emitted or, in some cases, even before it has started. As such, we do not wait for specific times of the year to publish our advisories. We publish as we become aware of the problem, and only for as long as we see the problem still exists.

Before we look into some case studies, there is an important point to note: not all Spamhaus Project spamtrap systems accept all email. (It is a common misconception that they do.) Some reject a percentage of the messages sent to them. Some reject mail from specific sources. Some even reject all email whatsoever. The behavior of any spamtrap can also change over time. This is important because in the examples that we will be presenting all messages were rejected. Had the senders been paying attention to their error logs, as all bulk emailers should, they would presumably not have continued to send email to obviously closed/dead email addresses.

Case Study 1.

A transactional message (in this case a receipt) was sent to an email address that had never requested it. That message bounced, but that didn't prevent the company's marketing department from pushing advertisements to that email address. They stopped sending to the email address eventually, but nine months later they moved to another ESP and attempted to re-engage the email address.

Please note: this email address had rejected every message sent to it over the course of the year. It never "opened" an email. It never "clicked" a link. Even if the marketing department had not been given access to the mail logs or told which email addresses were bouncing, if they had simply paid attention to the engagement statistics for this email, they would have known that nobody was reading it.

We view the message sent on 2011/08/19 as a transactional message, most likely entered at a point of sale. We view the message sent on 2011/08/22 as an opt-out message from the marketing department, since no permission had ever been given to send marketing email messages to that email address. To repeat ourselves, every one of these messages was rejected. It is the view of the Spamhaus Project that email addresses used for transactional mail should not be used for marketing email without permission.

Case Study 2.

Sometimes an email address is acquired at a point of sale and saved into a database for future marketing. Transactional messages, when saved into a database to be reused, should have some sort of confirmation process to ensure that new messages are in fact going to the proper person.

As with the previous case study, all of these messages were rejected during the SMTP conversation. Had the sender been processing rejections ("bounces"), the sender would have known that their email was not being delivered. Email to this email address should have stopped after AT MOST three rejections.

In addition to being sent to an email address that had rejected all previous email, the message sent on 2013/01/28 had a completely different sender envelope address than the previous messages. For example, assume that the receipts were sent from receipt@brand-a, but the new email was sent from rewards@superduperrewardsclub. Even if the new email had been sent to an actual customer email address instead of a spamtrap, unless the customer did considerable research, the customer would not realize that they were being contacted by "Brand A", which also owned "Brand C". The email would look like spam from a company that they'd probably never heard of or done business with.

Case Study 3.

Sending transactional messages doesn't mean that you can forget about list hygiene. In this example, a domain expired in early to mid-2010, was re-registered by Spamhaus, and was placed in timeout for more than two years. (Most new spamtrap domains are placed in timeout for at least six months, and many for year or more, before being put into production as a spamtrap. While email is properly rejected during that aging process, data can still be collected before the SMTP rejection, hence the Subject history during that period.) This spamtrap was configured to reject all email from this particular source, but the sender after two years still hasn't realized that the original recipient is not receiving their messages.

In the example above it is painfully obvious that this sender isn't even looking at their rejection logs. They are also not performing any sort of hygiene on the email addresses that they are sending to, as each of those messages were rejected in the SMTP conversation.

We hope that these case studies help to illustrate the problems caused when senders of transactional and bulk email ignore SMTP rejections. The ongoing flow of presumably-unintended bulk email from unattended mail systems operated by well-intentioned but careless senders is unsolicited bulk email (spam). It wastes recipient mailserver resources and annoys innocent third party recipients who did not ask for that email.

Spamhaus' mission is to keep unsolicited bulk email out of our users' mailboxes. We do make adjustments in the data available for SBL listings and in how we handle that data. Sometimes, as was the case in December, those adjustments bring to light ongoing spam problems, but they do not create those spam problems.