4 February 2017

Information for spam report recipients

Nowadays, almost all email messages sent over the Internet are unsolicited. The continuous deluge of spam wastes enormous amounts of resources. In addition, spam is typically used to spread fraudulent solicitations, malicious software and other harmful content. These threats force organisations to drop or reject traffic from and to networks that support spam.

Frequently asked questions

‘What’s there to gain from acting on spam reports?’

Your reputation determines the extent to which administrators will allow traffic to pass between your networks and theirs. Various DNSBLs and other resources document network reputation. Some of them are public and some are private; some allow reconsideration requests and some do not. Abuse perpetrated using your networks damages your reputation, but if you quickly stop the abuse and ensure that it does not recur, your reputation will suffer less than if you allow the abuse to continue. In short, a spam report provides you with a damage control opportunity.

There may also be legal issues involved, both criminal and civil. They are not discussed here; ask your lawyer instead.

‘What should we do?’

How you prevent abuse is up to you. If you do not know how to secure your network, contact a local consultant. The Spamhaus FAQ for ISPs also includes valuable pointers.

Frequently presented objections

‘The message you reported wasn’t spam.’

Those sending unsolicited bulk email tend to define spam as ‘that which we don’t do’. However, the Internet community in general defines email spam as unsolicited bulk email messages (regardless of their contents). Bulk email is only to be sent to recipients who explicitly have requested it. Disclosure of one’s email address does not imply a request to receive bulk email.

Web shoppers typically provide their email addresses so as to receive essential transactional messages such as their order confirmation, any back order information and the invoice. Further messages, such as feedback requests and sales solicitations, require separate, explicit consent from the recipient.

Recipients must have opted in consciously and of their own free will. For example, if a ‘Yes, send me bulk email’ checkbox was ticked by default or if the sender’s terms of contract include a ‘We have the right to spam you’ clause, the recipient may not have intended to opt in.

Requests must be confirmed in a way that eliminates forged subscriptions. If bulk email is sent without such confirmed opt-in, it is spam and it will hurt the reputation of the networks involved with sending or facilitating it.

Each subscription request is limited to its stated extent: the subscriber must not be sent any other bulk email unless he or she explicitly has requested that as well. As an example, if an individual has signed up for software update notifications from company A, this request does not cover mailings on any other topic. Obviously, said consent also does not apply to mail from company B or C.

The subscriber must also be able to leave the list at any time. This means that bulk mail senders must read mail sent to the addresses they use in their messages. If the sender additionally offers a web-based unsubscribe facility, it should work with any browser – not require support for e.g. images, sound, scripting or cookies.

Keep in mind that email addresses may cease to exist, such as when a domain name registration is left to expire. Email addresses that are found undeliverable should be removed from the mailing list after the first 5yz or authoritative NXDOMAIN reply is received. If the address is kept on the list, the sender will end up spamming any third party who later creates that address. Also note that 4yz replies are often issued because the sender appears spammy. Because of this, it also makes sense to remove addresses that consistently return 4yz replies.

‘Complying with all those guidelines would be impossible.’

On the contrary: it is trivial. All the sender needs is normal mailing list software (rather than ratware designed for spamming) and an ounce of common sense.

‘The spam wasn’t sent from our network.’

Providing support for spam will damage your reputation even if the spam is sent through another network. Spam support may involve e.g.:

  • mailboxes to which spammers solicit replies;
  • web pages that are advertised through spam;
  • web redirection services pointing to sites that are advertised through spam;
  • e-shops and payment processing services used by spammers;
  • spam tools, including lists of email addresses;
  • registration and DNS service for domain names used by spammers;
  • routing of IP traffic for networks used by spammers.

‘You should ask the spammer to unsubscribe you.’

Whether a spammer is willing to exclude a particular email address from a particular spam run is not interesting. What matters is whether you allow spam, or spam support, to be continued.

‘Our customers are legitimate organisations.’

Great, but if they send unsolicited bulk email, they are also spammers – even if their spam does not violate the law in your jurisdiction. Read more about ‘mainsleaze’ spam.

‘We don’t agree with you.’

Fair enough. However, the views presented above are widely held by system administrators and security practitioners – in other words, by those who decide whether traffic from and to your network should be allowed at their sites and those of their clients.