2015-02-27
Email from generic word domains is usually advance fee fraud spam
One of the patterns I've observed in the email sent to my sinkhole
SMTP server is what I'll call the 'generic word domain' one. Pretty
much any email that is from an address at any generic word domain
(such as 'accountant.com', 'client.com', 'online.com', or 'lawyer.com')
is an advance fee fraud spam. It isn't sent from or associated with
the actual servers involved in the domain (if there's anything more
than a parking web page full of ads), it's just that advanced fee
fraud spammers seem to really like using those domains as their
MAIL FROM addresses and often (although not always) the 'From:'
in their message.
Advance fee fraud spammers use other addresses, of course, and I haven't done enough of a study to see if my collection of them prefers generic nouns, other addresses (eg various free email providers), or just whatever address is attached to the account or email server they're exploiting to send out their spam. I was going to say that I'd seen only a tiny bit of phish spam that used this sort of domain name, but it turns out that a recent cluster of phish spam follows this pattern (using addresses like 'suspension@failure.com', 'product@client.com', and 'nfsid@nice.com').
I assume that advance fee fraud spammers are doing this to make their spam sound more official and real, just as they like to borrow the domains of things associated with the particular variant of the scam they're using (eg a spam from someone who claims to be a UN staff member may well be sent from a UN-related domain, or at least from something that sounds like it). I expect that the owners of most of these 'generic word' domains are just using them to collect ad revenues, not email, and so don't particularly care about the email being sent 'from' them.
(Although I did discover while researching this that 'nice.com' is a real company that may even send email on occasion, rather to my surprise. I suspect that they bought their domain name from the original squatter.)
(This elaborates on a tweet of mine, and is something that I've been noticing for many years.)
2015-02-22
Unsurprisingly, random SMTP servers do get open relay probes
One of the things I do with my sinkhole smtp server is run a copy of it on my home machine. Unlike my office workstation, my home machine has never been an active mail machine; it has nothing pointing to it and no history of various (pseudo)email addresses that attract spam. Under normal circumstances there should be absolutely no one with any reason to connect to it.
Indeed, it doesn't attempts to send me any email (spammers might
plausibly try, say, postmaster@<machine>). What it does get is a
certain amount of open relay probes. Originally these probes were
sent with outside MAIL FROM:s (and outside RCPT TOs, obviously),
but lately they've been forged to come from various addresses at
the machine's overall domain.
(What's actually pretty interesting about this is that the overall
domain isn't valid for email; it has neither an A nor an MX
entry, and never has. The spammers are just assuming that, eg,
'support@<domain>' is a valid address and using it as the MAIL
FROM.)
It used to be that the relay probes made one or two attempts and
then stopped. The recent run of relay probes has dumped a whole
series of email on my machine all at once, varying at most the MAIL
FROM address; I assume it's trying to see if some will go through
where others fail. At the moment addresses on GMail appear to be
the popular collection point for results. The Subject lines of
recent relay attempts clearly contain tracing information and suggest
that the software involved is normally used against things that
require SMTP AUTH, as it seems to be including passwords in the
Subject: information.
The exact details and mechanisms have changed from earlier attempts and will undoubtedly change again in the future. What's really interesting is two things: people really do scan more or less random addresses in an attempt to find open SMTP relays, and when they find something they don't immediately start trying to shovel spam through it but instead attempt to verify that it actually is open.
(Some days I'm tempted to manually 'relay' one of these messages to its collection point just to see if there would be a future attempt to spam through my machine. But so far that's far too much work and probably a certain amount of risk.)