Observations on SPAM

Botnets

The most obvious source of spam is from botnets. We can identify these because we'll see a slew of emails from a wide range of IP addresses but all with something in common. Almost always it is the same sender.

Botnets have gotten much better these days and will correctly use a HELO string of their external domain name or literal IP address ([a.b.c.d]). This fails CheckHelo's RFC2821 checks if a.b.c.d results in a domain name that doesn't have a forward lookup ("A reverse but no forward? Amazing!") or which ever resolver they're using returns an internal domain name.

However, because they use the same sender then they are at trivial risk of a correctly set SPF record denying them usage.

You rarely see many emails from the same IP address.

That said, there have been botnets which switched modes from the "try sending an email at a time from each of several IP addresses" to the visually more aggressive "send lots of emails from one IP address." I guess that's either a random decision to switch attack mode or perhaps the spam software detected some weakness in the destination system from a particular IP address and tried to exploit it.

Usually the destination address is a set of users often including historic addresses and odd constructions: bob@example.com might become okbob@example.com or bobn@example.com which suggests corrupted results from scraping bulletin boards and the like from the rosy old days when email addresses were visible.

Usually, greylisting will defer these emails and we'll never see them again. We'll transiently accumulate senders and sender IP addresses in the database which will get cleared out eventually.

Interestingly, you don't often get any actual email from these systems. I wonder if they're simply scanning for valid email addresses to be sold on to others.

Another spin from spammers takes a leaf from legitimate email. If a legitimate system wants to track whether an email address is still valid then they will set the sender to something recipient-specific. So a message to bob@example.com might be sent from bounce-bob=example.com@corp.example. Here, if the email address bob@example.com is no longer valid (or has some other issue) a bounce message will be sent to the sender, bounce-bob=example.com@corp.example and the remote system can deconstruct the recipient, bounce-bob=example.com and determine that the problem was with the message sent to bob@example.com. Of course, in a more sophisticated age, the user component, bounce-bob=example.com, might be encoded in some way or even a random ID that can be matched to bob@example.com in a database.

Spammers, are starting to do the same. In this case, there is a tendency to reuse the same domain name and so you would want to place constraints on the domain name component rather than the specific email address.

Taking of bounce messages... These are identified as having a NULL sender. You'll see this in the logs most often as a blank (nominally hard to spot but from=, is easier and sometimes as <>) and is matched in PolicyD with an @ on its own. As an aside, by using a NULL sender the sending system is suggesting that it doesn't care for a reply if this message fails to reach a destination which in turn prevents a snowball effect of repeatedly bouncing "no such user" messages.

You would think that spammers might utilise NULL senders more as a means to surreptitiously sneak round any policies we set as the email can contain a Sender or Reply-To header which would be used in preference to the From header anyway. But they don't. Maybe they used to and email systems have cottoned on and so it is handled elsewhere.