SPF redux
About a year ago I got excited by the prospects of the SPF anti-spam scheme. Of course this is before Microsoft negotiated to merge SPF with their own “Caller-ID” scheme and the dark cloud of IP licensing poisoned my support.
Anyway, to repeat the main problem with SPF: SPF validated using envelope sender addresses. This was good because it meant that validation an rejection could happen before accepting the email, but was bad because it meant that traditional mail forwarding (where the envelope sender is preserved) wouldn’t work. I wasn’t a fan of the proposed solution which involved sender rewriting.
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.
Well, that’s similar to the Draft for the SUBMITTER extension which was submitted to the IETF in August.
SenderID, unlike SFP (or “SPF-Classic”) doesn’t validate the envelope sender, but rather attempts to determine the “responsible address” by accepting the email and parsing the header. This means that rejection can’t happen until after the email has been accepted, which is non-optimal. (And given the number of broken mailers out there that refuse to regard post-data rejections as fatal, just asking for trouble.)
The ESMTP extension allows the responsible address to be specified up-front by the submitter during transaction time, allowing for instant rejection (and then a second chance if the approved sender is not listed in the headers). I don’t know if there are any specific IP claims on this proposal, but since it’s just about the simplest and obvious ESMTP extension, I’d be surprised if there were.
Regardless of the SenderID scheme being adopted as a whole, I’d like to see this extension supported by not only the software for receiving mail, but also the software used in sending mail, just so that when the dust of the current disputes finally settle, the bulk of the infrastructure will be there.
