Shooting the messenger
Along with an exponential rise in spam in the last few years, I've noticed a corresponding rise in the number of commentators who have concluded that the only solution is to dump SMTP.
Occasionally it's a government representative who'd like the ability to tax email. Often it's a pundit. A recent ZD piece being a perfect example: "SMTP is outdated, we need a new protocol with proper certification to reduce spam".
Now I don't love SMTP. I don't want to marry it. I've just escaped almost 4 years of professional mailserver/listserver adminning. Trust me, there's still some residual bitterness. But, hold on. You want the world to abandon an infrastructure in use and constant development for over 20 years because of a handful of spammers. Impose some quick technical solutions onto a social problem?
I'm not convinced that certification is the solution is really going to make that much of an impact. Perhaps people are confusing spammers with Rumplestiltskin? Maybe there's a genuine belief that as soon as you know the spammer's "True Name" they'll no longer have any power over you. That, if pushed, you could take a trip down to Boca Rotan and hand-deliver them a freshly opened can of "whoop-ass", or key their car, whichever.
Except we know who the spammers are already. And even when their clients attempt to remain anonymous, unusual in marketing, the credit card company usually knows who they are. This doesn't stop them spamming. They don't really care that you disapprove. There's a reason most spammers operate out of Florida - the relevant laws are so weak. Fines are too small to represent a disincentive.
Which is not to say that certification wouldn't be useful - but we don't need to abandon SMTP to get it (we already have TLS for message transit and S/MIME amongst others for message contents).
If the European Union can change the money that 300 million people use all on one day, we can change our email protocol. Let's find a protocol with decent authentication and with micropayments to make spam uneconomical, and let's set a deadline, maybe two years in the future, when SMTP will simply be turned off. Everybody will know it's coming, just like Y2K, and everybody will have to be ready.
Oh yes, micropayments. Our saviour. Everyone's got a stack of internet business plans that'll turn into liquid gold the very second the micropayment infrastructure arrives. I know I do. So where is it?
It seems that dozens of web-toonists and mp3-remixers are dropping dead of starvation on an almost daily basis - nothing. Quirky web-loggers right across the Bay area may one day soon have to go without the latest titanium-coated whatever. Yet no micropayment infrastructure? A few paypal donation links, but I've yet to see a real "402 Payment Required" returned in the wild.
So the plan is to force micropayments onto users for email? Now maybe there'll be an elegant and completely fair design out there that manages to strike the right balance. But the idea here is to undertake a massive infrastructure overhaul and impose a charging system, just in order to get spam back down to 1997 levels. Mmmm, compelling.
In fact I'm already used to a "micropayments" messaging infrastructure - SMS. Just pennies per messsage, not enough to dissuade normal use. Except normal use for some people can get expensive. And is there such a thing as SMS spam? Sadly, yes.
Forcing a micropayment system on everyone in order to fight spam feels like punishing the victims.
Of course there are some problems with SMTP that have been exasperated by spammers.
I've been on the recieving end of "Joe jobs" in the past - addresses which delivered to me have been forged to be the return path for a few large-scale spams. Thousands of bounce messages from servers across the world have streamed into my mailbox and I was powerless to stop it. All you can do is tweak your filters and ignore them.
It's a weakness that SMTP will trust any claim of who messages are coming from in most circumstances. This potential problem is amplified by the fact that many SMTPd implementations will accept a message that is immediately known to be undeliverable before bouncing it back.
If you're the recipient of a joe-job go right ahead and blame fundamental design problems with SMTP. Perhaps call for its abandonment. In the short term perhaps a more productive way of looking at it is that almost every single bounce message (that hadn't already been rejected) was generated by a machine that had accepted an undeliverable mail from (in my case) an open relay.
If all the mailservers involved were configured to reject mail from open-relays then this wouldn't have been a problem.
The overriding philosophy in the design of Internet protocols has
tended to be
Jon Postal's
robustness principle:
"Be liberal in what you accept, and conservative in
what you send."
(from
RFC1122
and earlier in
RFC760).
It's a good basis for the net. For a sprawling de-centralised network held together by rough consensus, things break less often than they should. The same approach is generally adopted with email.
Sadly, this approach has created the ideal ecosystem for spammers. So perhaps it's time to get a little more... anal.
In the megacity of my mailbox I'm leaning toward the Judge Dredd position: if you want order, punish the guilty - no matter how minor the transgression.
The following are things that can be done to clean up SMTP. They aren't measures that directly combat spam, but rather begin to clean up the SMTP ecosystem in which spammers run rampant.
- Reject connections from open relays. Yeah, a bit obvious, but the point is: don't reject mail from open relays because it's likely to be spam, reject it merely because it's coming from an open relay.
- Reject mail from known open-proxies. You can already do this using DNSDB (blacklist) zones such as the Monkeys.com UPL.
- Reject connections from clients with invalid or no reverse DNS (newer SMTP servers should be able to handle this already).
- Reject mail without the full compliment of completely valid headers. Including a valid Message-Id:. Possibly even from local hosts authorised to use it as their local mail relay. If we're going to try fixing SMTP, lets promote port 587.
- Reject mail based on the quality of the sender's domain name
or IP range.
- If the domain or IP range has no working abuse contacts.
- If the mailserver for the domain rejects mail addressed to the postmaster.
- If the mailserver for the domain rejects DSN (Delivery Status Notification Messages).
- If the domain name or IP range has inaccurate (or blatantly incorrect) whois registration details.
And, if were going to be changing things, perhaps a few from my personal SMTP wishlist:
- Reject mail from systems that send "Out of office" replies to mailing list postings. Not an anti-spam, but there's plenty of broken servers out there I'd like to see replaced. It's a real shame that the "Precedence:" header still isn't considered standard, because as far as I know there's no real standard for how auto-responders should work.
- Reject mail from servers that don't generate delivery failure messages in the format described by RFC3464. Plenty of servers generate their own acceptable failure messages, but plenty of servers send back that are next to useless. Especially if they're in a language I can't read. Again, if we're going to fix SMTP this is the sort of thing that would be nice.
- Enforce the use of MX records, even for hosts with no backup MXes.
Technically my last wishlist item is goes against the RFCs. SMTP has something called the "implicit MX" rule:
If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host.
The upshot is that for a host/domain to start receiving mail, no additional DNS record is required. The benefits of this (as far as I can see) is slightly smaller DNS zones, and a small amount of time saved by not explicitly adding them. The downside - there's no correct way of determining if a host is intended to receive mail. If it's not answering on port 25 it may be a temporary failure, so retry later. Every day mail servers are continually attempting to deliver bounce messages either from spam, or misconfigured servers (usually via cgi scripts).
Now there might be an argument for keeping "implicit MX" in the long term. But if it takes you longer to think of one that just add the damn records, it'd better be good.
So another day, another call for a new anti-spam SMTP infrastructure. This time from "legitimate" e-marketeers.
Volume Mail Standards: A process that requires standardisation of all sender info in the mail header including the use of an identifiable, trackable unsubscribe URL.
Well if someone's going to spend time promoting the adoption of List-Id: and List-Unsubscribe: headers, I'll support them in that, regardless of who they are.
I'd rather technical specifications weren't dictated by politicians. Because how far is "why can't we enforce the adoption of a mail-transfer protocol that prevents spam?" from "why can't we enforce the adoption of a file-transfer protocol that prevents the transmission of offensive pornography?".
net: posted at 20:34, link