Sounds Pretty Feasible
I was a bit sceptical. But since reading the current draft for the proposed Sender Permitted From anti-spoofing (and, by extension, anti-spam) scheme, I’m still a little sceptical, but find myself thinking ”blimey, this one might actually stand a chance”. It’s still early days yet, but it almost feels like ghost of a lost RFC – fragments of an early submission that was somehow dropped behind Jon Postal’s desk, never to be recovered.
It’s flexible to a fault: Almost all of my technical queries have been answered with a brain boggling mixture of network ACL, mail and RBL-like syntax. The bread and butter of the renaissance sysadmin.
It’s not trying to overreach: It’s not trying to provide of authentication individual addresses or ”users” – that’s the job of crypto in the utopian techno-future. This just provides information to allow a mailserver to determine if mail should be coming from a particular IP address based on its “Envelope From” (if you’re not familiar with SMTP, note: this is not necessarily the address in the From: line).
It doesn’t require a global atomic change: Users don’t have to do anything. In fact nobody has to do anything. The magic pixies who run the Internet will start rolling it out for their own use, no existing standards need to be messed with. Others can join in when they feel like it. The idea, essentially, is to build a big distributed database of which sending servers are used by which domains. And for the hostmasters don’t join in, alternative records can be made available elsewhere. (Hopefully a unique DNS RR will eventually be granted, and the world’s nameservers and resolvers will be updated to recognise it, falling back to the TXT records if not.)
It doesn’t require precise, public, information disclosure: Domains who, for whatever reason, can’t (or won’t) provide precise information can still provide better-than-nothing information to begin with. Even an odd rule such as “!ptr:kr” might be useful for spotting spoofing. (It means mail from addresses in this domain will never come from a server whose validated “reverse DNS” PTR is in the domain hierarchy of South Korea.).
Even if it’s not fully adopted it still has significant value: Even if mail servers aren’t going to act based on SPF information, the fact that there’s a DNS-based database out there that can be used by client-side filters is a big win on its own. This would be the DNS whitelist to balance out all of those blacklists. It may be this proposal’s saving grace.
Now obviously some knowledge gathering about how addresses are used is going to be necessary for rules to be published. But prime candidates for early listings would be the domains exclusively used by mailing lists.
To give you an example – the NTK mailouts, and associated list admin mails, are the only mails that should be seen with an Envelope From with the domain “ntk.net”. And in fact these mails are only ever sent out from a server that is alsoa listed MX for it. Therefore the relevant record added to the zone might be:
ntk.net. IN TXT "v=spf1 mx default=deny"
In fact that’ll probably be the case for the majority of domains/subdomains that are dedicated to mailing lists. (As it is, this record might require a second query for the MX records. Now a more network efficient way would have been to specify the IP addresses, but the example serves to illustrate the potential for simplicity.)
The SPF draft suggests a ludicrously optimistic “global sunrise period” ending on April 12th 2004 (as being the 10 year anniversary of Usenet spam). I’m sceptical it’ll be that much further than a draft RFC by that point but, since publishing just involves the inclusion of a standard DNS record type I can easily see rapid adoption when the standard has stabilised. By mid-2004 it might be common to see “Received-SPF:” headers appearing atop mails, and utilised as client-side heuristic tests. And not long after, the inclusion of fake Received-SPF: headers in spam (although lower in the headers than they should be). SPF, for a while, will be known as “that spamassassin thing” and by the time support is folded into the likes of Mail.app and Firebird, it may have already have built up a critical mass of record publishers.
New iterations of mailserver software will be “SPF aware”, but aside from some smaller servers, most of big sites will hesitate to “pull the switch” and use it for transaction time rejection, instread leaving it as a client-side tool. The reason will is the “.forward” problem, a close cousin of the mailing-list problem.
Essentially the problems mailing-lists pose to anti-spam schemes are (with some generalisations):
- Mailing-lists are not “personally” addressed to the receiver. They have the properties of any bulk mailing.
- The “From:” addresses may have no direct connection to the machine that is passing them on.
- Any “charge” applied to the sending of one mail must be multiplied
by the size of the list (which may be tens of thousands). - A mailing-list might not be a commercial tool, there may be no opportunity for solutions that involve a greater expenditure of
money or resources. - Any machine that sends mail is potentially a legitimate list server.
- The receiving mailserver doesn’t keep records of which lists each client is subscribed to. Ultimately, only the client can separate the solicited from the unsolicited
- Spam sometimes infiltrates legitimate mailing lists – so applying
measures against “the source” may do more harm than good.
The mailing-list problem is the sanity check I use when reading anti-spam proposals. Often the authors of schemes that don’t have room for them will tack on a hand-waving addendum about how some unspecified ”special arrangements” will need to be made. Others will even lament that that the idea of free mailing lists will have to end. ”I think it’s a small price to pay for a spam-free inbox”. Well, I don’t.
SPF side-steps the mailing list problem by concentrating on the ”envelope sender” not the “From:” header, which for most modern mailing-lists
is an address used by some automatic management process (e.g. majordomo@, list-admin@, or a VERP address) which is tied to the list’s domain.
The problem is how mail forwarding works. When an email is automatically forwarded (e.g. via a .forward or aliases rewrite) the envelope sender (the address error reports are to be sent to) is preserved and used for the subsequent transaction (although some broken software will use the From: address). In the eyes of SPF checkers this makes them likely forgeries.
While the bulk of the SPF proposal is a neutral, optional specification that doesn’t conflict with the existing mail infrastructure, this problem actually may require actual (although relatively minor) changes in how mailservers work in order to work properly.
As far as I can see, the only satisfactory way around this in the short term is to use distributed whitelists for the well known mail forwarding servers, and local whitelists controlled by clients. This probably means that only servers with a small number of users (i.e. where whitelist information, if needed, can be feasibly managed) will feel confident enough to use SPF (independent of other tests) for transaction time rejection.
The current SPF proposed system for dealing with this issue, SRS, not only appears to be a horrible kludge, it also introduces new problems into the existing infrastructure. Most mailservers would need to be updated just in order to understand how to process bounce messages. I’m sceptical that this approach as it stands now will ever find favour.
So, while I can see SPF TXT records being adopted in the short term, I think it’s going to take a little longer to implement the full system, and fulfil its promise. I imagine, if this proposal goes through the IETF wringer, we’ll eventually end up with a standard SPF ESMTP extension being advertised and recognised by “SPF2″ compliant mailservers. This will be the hook to communicate the additional information for dealing with forwards and bounces. Servers that do not advertise or recognise the extension would work as normal, and be candidates for a local whitelist.
Which is not to say that the “bang path“-like chain of addresses for error reporting is necessarily a bad thing. The concept of chained bounces sounds like an anathema to postmasters in the age of spam. But, if address forgery was a (mostly) solved problem, it might be a preferable design.
I consider it a potential weakness of SMTP that when mail forwarding fails, the sender gets back more information about where the mail went than necessary. It’s been the case in the past that I’ve sent a mail to some Important.Person@respectable-company.ltd.uk and just gotten back a bounce message from a free webmail service telling me that ”user spunkymunky69 is over quota”. It’s potentially confusing for the sender and in some cases undesirable for the (non) receiver. The opportunity to massage bounce messages may prove to be beneficial.
So, if SPF were to be deployed there are things I hope to happen (a drastic reduction in spam, wider knowledge of the difference between header and envelope “from”, greater support of SMTP AUTH and port 587) and some things I hope won’t (the overloading of PTR records, undelivered bounce message, service provider “lock-in”). I’ve often thought that the schemes more likely to succeed would be the ones that ask for the least in sacrifice. SPF seems to be asking us to make hardly any sacrifice at all.
