Larry Seltzer wrote an interesting article for eWeek, on port 25 blocking, the reasons why it was being advocated, and how it would stop spam.
This quoted an excellent paper by Joe St.Sauver, that raised several technically valid and true corollaries that have to be kept in mind when blocking port 25 — "cough syrup for lung cancer" would be a key phrase. Yes, port 25 blocking is a good thing, but virus infected PCs can be hijacked by net abusers, and used for anything from hosting childporn sites to participating in DDoS attacks.
Now, George Ou has just posted an article on ZDNET that disagrees with Larry's article, makes several points that are commonly cited when criticizing port 25 blocking, but then puts forward the astonishing, and completely wrong, suggestion, that worldwide SPF records are going to be a cure all for this problem.
Here is my reply to him, which also contains an edited version of my thoughts about SPF, that I have, so far, posted only on a closed antispam list some months back.
I manage the antispam operations at Outblaze (we run mail for Lycos, mail.com and a bunch of other sites - ~ 40 million users)
Here are a few counterpoints to what you wrote:
> Spammers can and do bypass port 25 restrictions by using the zombie computer's legitimate SMTP servers.
Precisely. That's already happening. BUT coupled with SMTP authentication being enforced (you can use any email address you want in the from address - you just have to set your mail client to login to your SMTP server with your username and password) ...it make it much, much easier to locate and cut off zombied PCs. Think of it this way ...all the spam that normally leaks out of several thousand IP addresses (cable modems, dialups etc. running infected PCs) is funneled through a single set of servers, that are set up to watch for outbound spam and clamp down on it.
> Many legitimate users need outbound port 25 to send e-mail through an SMTP server that may not necessarily be hosted by their ISP of the...
Port 587 (the message submission port) is defined by RFC2476 — and that RFC is dated 1998. Since then, most if not all major mail servers do support both port 25 and port 587. So what people who want to use an offsite smarthost do is to get their ISP to open it up on port 587, with SMTP authentication enabled, if they haven't done so already and they're all set.
> Some low budget domains use their broadband accounts to host their own SMTP servers? They would also be harmed by port 25 blocking.
Static IP broadband - or anything else on a static IP - would not be subject to port 25 filtering. That is for dynamic IPs (dialup, residential broadband etc). Even if people do run servers on dynamic IPs, they can set their mailserver to route outbound mail through their ISP's servers, or through their dynamic DNS provider's SMTP auth mailserver - dynamic DNS providers do provide this service now.
> Getting most or all ISPs to block outbound TCP port 25 would be very controversial with their users. It would be very difficult to get universal compliance.
Agreed. But it would be even more difficult for them if they failed to clamp down on trojan/zombie originated spam and viruses from their network.
And speaking of controversial…
> If the top 50 domains in the world who are sick of the spam problem implemented the non-SPF ban, this would force every other domain in the world to comply with SPF - unless they don't care for their e-mails.
That is going to be far, far more ruinous, if only because SPF is badly thought out and fails horribly in several edge cases. Several spammers can, and do publish SPF records. And the implication of publishing SPF records absolutely forces people to rely only on their email provider's mailserver assuming the restrictive - all SPF record - more conservative ?all and ~all records are not going to be very useful, and -all is guaranteed to lose you mail, given the number of forwarding email providers who don't implement the other side of the SPF coin - ses/srs return path rewriting of forwarded mail.
You'll find that it is going to be far easier to ask for port 25 blocking than for SPF publication.
And, port 25 blocks are an expression of an ISP's intent to crack down on outbound spam. Checking on SPF records - a procedure that's guaranteed to lose you valid email as I mentioned above - is trying to solve an entirely different problem. Consider for example cableisp.example.com, which has an SPF record set. Trojans sending out emails as random cableisp.example.com addresses render your ideas of SPF checking quite useless.
> to be delivered to the top 50 domains? Contrast this with the port 25 ban, which requires every ISP and hotspot in the world to comply with outbound port 25 blocking. Which is the more practical solution?
Again - "if you want to deliver mail to the top 50 domains". You don't need to do it at "every hotspot", believe me - this is something that is done at the edge of the ISP's network. Most, if not all, hotspots get themselves a DSL or a T1 or whatever from a large ISP, and these filters are best applied at the ISP's end.
The other part - about requiring bonding of bulk senders? That works for the legitimate people. Spammers, on the other hand, work on the basis of other people's money - letting other people's bandwidth, CPU etc. subsidize the costs of their spam. Take the case of Jeremy Jaynes, who was recently sentenced to 9 years for spamming. He spent something like $50K a month in buying lots and lots of bandwidth, and setting up spam servers to run on them. He sent out 300 million emails a month and got maybe 10,000 orders a month for phony stock advisories etc. at $40 a pop. His revenues were on the order of $450K to $700K.
Finally, speaking of SPF, we recently decided to stop publishing SPF records for several of our domains, such as mail.com, that have published SPF records for over a year now.
Over the last several months, I've become less and less convinced that SPF is going to be of any long term use, especially for sites that publish ?all or ~all records, or for any domain at all that sends mail.
SPF records like "v=spf1 -all" do come in handy if you want to say a domain sends no email at all - but that's an edge case.
Speaking of edge cases, what triggered this removal of our SPF records is basically an expression of my strong disapproval of a white paper on authentication technologies that Meng Wong, the author of the SPF spec, has published.
My assessment of that whitepaper:
* 70% spf, classic spf, unified spf etc.
* 10% domainkeys / cisco identified internet mail
* One short paragraph (and mostly inaccurate) on BATV
Followed by this paragraph that appears in a list of ways SPF/Domainkeys can be worked around (such as hijacking a domain and its authentication credentials, buying accreditation using zombies etc.)
Quoted verbatim - it's the last paragraph on page 22 of that PDF.
Spread FUD about the edge cases
None of the approaches are perfect. A message could be forwarded through a site that does not perform SRS and does not prepend Resent: headers, that message could then pass through an MTA that munges the content for perfectly good reasons. This corner case is a favorite of technical perfectionists who use it to argue that one can never reliably reject a message based on sender authentication. If this point of view gains widespread public acceptance, you will be able to continue to spoof messages.
My take on it? Meng Wong is saying that when SPF is criticized for having a proposal that's got major issues that lead to a lot of email being lost (forwarded email, such as where a university account is set to autoforward to a webmail or other personal mailbox can hardly be described as an "edge case"), so this means they're aiding spammers by retarding the growth of SPF.
That's not just plain wrong, it is downright insulting to a whole lot of people who have valid and correct objections to SPF.
Edge cases? "v=spf1 -all" (meaning "this domain does not ever send mail") is an edge case - and one where SPF does work as advertised. Another way to express the same, without SPF, would be this draft by Mark Delany of Yahoo, that I contributed a few suggestions to, and codifies an already well known and widely used DNS factoid.
Corporate mail domains that have a corporate IT policy that stops their employees from setting up offsite email addresses that forward to their corporate mailbox could definitely use SPF, and not worry that mail autoforwarded to their mailboxes will bounce. But those are, again, edge cases.
SPF seems designed to work best in edge case situations, rather than as the multipurpose solution (stops forgery! stops phishing! etc.) that it is being promoted as.
So when people point out breakage of SPF in edge cases, it is completely wrong to call this FUD - and even more wrong to call this FUD in a whitepaper he has been commissioned to write.
Removing SPF records that we have deployed earlier (I think mail.com is listed on various sites as an early adopter of SPF) is the least that I could do to express my strong disapproval of this behavior.
By Suresh Ramasubramanian, Antispam Operations
|Data Center||Policy & Regulation|
|DNS Security||Regional Registries|
|Domain Names||Registry Services|
|Intellectual Property||Top-Level Domains|
|Internet of Things||Web|
|Internet Protocol||White Space|
Afilias - Mobile & Web Services