2013-09-29
Spammers illustrating, well, something
I'm on the general mailing list for Exim and over time I've become used to seeing what I'll call 'please do my homework' requests there. By this I don't quite mean literally requests for this (so far no one seems to assign configuring Exim as homework for some class), but instead requests for help with problems which clearly show that the requester has not attempted to help themselves and is turning to the mailing list as a last resort; instead the mailing list is serving as a first or second resort. This is probably completely normal for any open source software with a decent usage level and I've long since gotten over being particularly irritated about it.
Every so often, though, the mailing list sees an unusually spectacular instance. Such as this recent one:
Hello,
Working with sending e-mail marketing and I'm using cpanel / whm with exim in its latest version.
Need to optimize the shipping of exim, and to receive e-mail the same now send direct to the recipient, and that was not generating the send queue.
I have noticed that the server is sending queue accumulating and analyzing the logs shipping seems that ISPs are blocking recipients immediate receipt, claiming the high flow of sending e-mail, noting that 100 IPS rotacioando have every referral, this set RDNS, SPF and DKIM,
[....]
I suppose I shouldn't be too surprised. (Self-admitted) e-mail marketers need to send their email using something and sometimes they're going to use the same mailer that I do. And some of them are going to ask other people to do their homework without entirely thinking the whole thing through.
(This message was met with a resounding complete silence on the Exim mailing list, which restored a bit of my faith in humanity.)
2013-09-24
A semi-wish for an official 'null MX' standard
I've written before about how it seems that spammers will scrape anything that looks like an email address and then attempt to spam them. Of course, much of what gets scraped is probably for (alleged) hosts that don't have anywhere to send email, so the spammers never even get as far as sending it. But through some sort of luck I have such a host that doesn't accept email but also happens to have an accessible mail server running on its IP address (because that IP address handles email for some other things).
Since I watch my SMTP logs (it's a low-activity mail server) this has
given me a nice ringside seat to the spam attempts and helped add things
to my personal blacklist. But as entertainment this palls after a while
and I'm starting to reach the point where I don't care and I would
rather that all of the would-be spammers just go away. To do this I'd
like what gets called a 'null MX', an MX entry that says 'this thing
doesn't get email, don't even bother trying to talk to its IP address'.
To my surprise there is no official standard for this. There
is a widespread habit of using an MX to '.' (dot, the
root of the DNS hierarchy) but it's not actually a standard
(although it was first put forward as a draft RFC in 2005 and is being tried
again this year). In
theory this has been around long enough as customary practice that many
mail servers should support it; in practice I have no idea how well it
works. If it's not very effective at reducing incoming spam attempts I
might as well not add the entry at all. I suppose I actually have a
relatively good opportunity to conduct a slow-moving scientific
experiment to find out.
(Probably the most reliable way to do this is to set the MX to a
public IP address under your control that doesn't exist or doesn't
accept incoming SMTP. I wouldn't use a private IP address or a 127/8
address because both of those may be ignored by legitimate mailers while
the only thing that's going to ignore an unresponding public IP as an
MX is spamware that is deliberately trying your A record even though
an MX exists.)