I was fortunate enough to be invited to dinner with Meng Weng Wong, Harry and Jim from Microsoft, and some others from Verisign, IBM, Spamhaus, etc. Over beers, we talked about the ideas that Meng/Harry/Jim had hammered out over the previous couple days. (This is part of the MARID working group meeting last week, though not the only part. Is anyone interested in the rest of the meeting? :)
I am a long-time supporter of SPF and I was skeptical of anything that would appear to be a compromise to MS. But, the two proposals had more things in common than they had differences.
Here’s a quick summary of what we talked about. (Disclaimer: I don’t represent either SPF or MS)
1. SPF and MS CID disagree on whether to operate on 2821.MAIL FROM or 2822.From:/Sender:/Other. 2821.MAIL FROM, if you can check it reliably, allows you to reject the mail before you get to DATA, and is also important for stopping bogus bounces. 2822.From:/Sender: is what the user sees and is important for phishing.
These two differ in how they deal with forwarders. If you check MAIL FROM, the forwarder needs to rewrite MAIL FROM using their own address (like mailing lists do) or something like SRS (if they want the bounces to still go to the original sender). If you check From:/Sender:, you will want to add a few other headers, like Resent-From, Resent-Sender, Delivered-To, etc.
As lovely and simple as SPF is, SRS is complicated and a bit ugly. If we are going to ask forwarders to do something, it would be great if we could require them to add a certain header and call it done. If you do this, the proposals start to look a bit closer. Of course, we lose the advantage of being able to reject mail before DATA (for now *)
This part of the marriage makes a bit of sense if you believe that the MAIL FROM (or at least the domain part) and the From:/Sender:/Some header are the same (or at least related). If you focus on 2822, it’s still possible for forgers to game the system and send bounces to someone else, but hopefully there won’t be much incentive for folks to do this.
It’s also possible to do something unilaterally about bogus bounces..
* Seth Goodman and others in the SES camp have pointed out that instead of requiring everyone in the world to implement SPF checking, you can stop joe-jobs more unilaterally simply by implementing SES, Signed Envelope Sender. Dave Crocker has independently invented this also.
SES is a variant of SRS used on all outgoing mail, so when your authentic message needs to be bounced, it will come back to the signed return address, and any bounce coming to a non-signed address is suspect. So, this goes some of the distance toward getting back some of the gains in rejecting based solely on MAIL FROM, plus it can be done by a site unilaterally without waiting for the rest of the world to adopt SPF/CID.
2. RFROM came along as a way to put the “Purported Responsible Domain” (PRD) back into a 2821-accessible place. This should be (in the combined proposal, MUST be) the same as the formula that CID uses: a blend of From, Sender, Resent-From, Resent-Sender, etc. It’s supposed to represent “who is responsible for injecting this into the mail stream, this time”.
As I understand, it’s not required for all mailers to implement RFROM in order to get the value of SPF/CID. That’s because you still get the data you need by looking at the DATA, and you can reject the message after DATA. Where it will be most important is for forwarders, who are agents for the receiver, and are therefore sending mail in the sender’s name outside the sender’s stated policy. But, they can get by with adding the appropriate header, which many already do. The RFROM is an optimization, not a requirement. My take on it is, SPF/CID is where we want to be tomorrow, and RFROM is where we want to be a year or two from now.
3. Finally there is the issue of XML versus SPF’s plain-ish syntax. I think we effectively side-stepped that question by saying, as a result of the merger, domain owners can publish policies in either XML or SPF, and receiver-implementations will have to check and understand both. More work for implementers, but more flexibility for domain owners.
XML is widely thought to be more extensible. In reality, it’s very extensible in terms of syntax, but doesn’t extend your installed base in terms of new features at all. So, we will need to be careful enough in the first version to define some “fallback” mechanisms, so that receivers who don’t understand the new feature will still know how to skip over it inteligently and still follow the domain owner’s policies as closely as possible. We’re working on that.
XML is also thought by some to be the way of the future. I’m not so sure about this… but I don’t feel strongly enough about the syntax to protest much, as long as the features are there. Besides, if we are honoring both protocols in parallel, it’s possible that two years from now, there will be 90% SPF and relatively little XML. If that happens, maybe XML will go away, but I think the important work of SPF/CID can be done regardless of which syntax method wins.
There are some other points we discussed, but that should be enough for right now.
Footnote: I am impressed with MS efforts to work with the larger community in this regard, both with SPF and MARID. Compare that to Yahoo, which published a draft of DomainKeys, but refused to send anyone to the MARID meeting, a 15-minute drive away.