Sender ID was not killed off in recent standardization talks, but it looks set to become a less rigid standard, making it more fragmented and debatably more flexible. However, this may slow down the aggressive adoption targets its supporters have set it…
Andrew Newton, co-chair of the Internet Engineering Task Force working group that is looking at Sender ID, said yesterday that licensing concerns mean the spec is being rewritten to use two ways of identifying email senders, rather than just one.
One of the methods will be purported responsible sender or PRA, designed by Microsoft. The other will be the method used in the Sender Policy Framework, or SPF, created by Meng Wong of Pobox.com.
The emerging email sender authentication specification has had a shaky couple of weeks, with attention focused on concerns about Microsoft’s intellectual property rights assertions, but it still looks set to become an internet standard.
Identifying authentic origins
AOL said yesterday that while it will support both the PRA and SPF methods on outbound email, it will only support SPF on inbound. Email administrators everywhere will also have choose what to implement, but they can choose both or neither.
It would have been better to have one standard, a Microsoft spokesperson said. We have two now, but that’s better than five or 10.
Sender ID, formed from the merger of SPF and Microsoft’s Caller ID For Email, set out to give email users a way to verify that email they receive actually comes from the entity it claims to. Proponents say this will help reduce phishing, worms and spam.
The framework requires users to publish in the domain name system the IP addresses of mail transfer agents that are authorized to send mail on their behalf. Recipient MTAs can look these addresses up to check the mail came from where it claims to.
Still a topic of intense discussion among IETF participants is how to do these lookups. SPF looks at an SMTP field called Mail From and compares it to what it sees in the DNS records for the sending domain.
But because email can hop between several machines before arriving, and Mail From identifies only the most recent machine, this approach has limitations. Mail forwarders, for example, could encounter problems.
The PRA algorithm
Microsoft contributed the PRA algorithm to address this limitation. PRA extracts the purported sender from the email data headers, as opposed to the SMTP headers. Some say that this approach creates its own set of limitations.
PRA was expected to be the only way Sender ID would determine senders, but Microsoft is attempting to patent the technology, and will seek licenses from software makers that implement PRA. Some IETF participants did not like this.
The Microsoft license is royalty-free and theoretically non-discriminatory, but open source advocates say that its terms are fundamentally incompatible with open-source licenses, because each user of the code has to take out a license.
Microsoft spokesperson Sean Sundwall said that a very vocal minority, mainly the GPL [General Public License] crowd were opposed to it and seemed to get the attention of the co-chairs of the IETF working group.
The Apache Software Foundation said two weeks ago that it could not support PRA, saying it was generally incompatible with open source, contrary to the practice of open internet standards, and specifically incompatible with the Apache License 2.0.
Dave Anderson, CEO of Sendmail, which develops open-source MTA software, said: We happen to think that this particular patent encumbrance is not an issue. They [Microsoft] have publicly stated many times that they will never charge for this.
Microsoft’s Hotmail service will begin to do PRA checks on incoming email next month. Sundwall said the company will not do SPF checks. The company will, however, publish records compatible with SPF and PRA for outgoing mail.
The IETF’s Newton said that currently the Sender ID spec is being rewritten based on the changes that came from the consensus of the working group’s last call last week. The spec will then be submitted to another last call.
In practical terms, the changes could give administrators a choice of checks to implement on the receive-side, and could create some extra implementation work for email administrators on the send-side.
Senders would need to publish two sets of references in their DNS records, because their systems will want to send email to companies like Microsoft, which will check just using PRA, and companies like AOL, which will just check SPF.
The point of Sender ID is to give email recipients a way to say with a fair degree of confidence that an email came from where it said it did. This knowledge can then be used as one factor in a filtering decision.
So-called legitimate bulk emailers are early adopters of SPF and Sender ID because they believe it will give them a way to get their emails to end users without being mistaken for spam. Spammers are also early adopters.