Sender Policy Framework, a specification designed to authenticate e-mail senders and therefore cut down on spam, has one significant flaw -- which a technologist presenting at the MIT Spam Conference 2007 in Cambridge, Massachusetts, last Friday aims to fix.
SPF attempts to eliminate spoofing -- or forging the "from" component of an e-mail -- by having senders specify which mail servers they use to send messages from their domain. The server receiving the mail then can check that the server the message came from matches published DNS information, according to the SPF Project.
However, this method presents a problem for "remailers" -- service providers that host or filter e-mail for their clients -- because remailers in essence forward mail on behalf of their customers and therefore the published DNS information won't match the information stored in the message.
"SPF is an ugly technology for those in the e-mail business who host MX records, because normal mail forwarding triggers an SPF failure," said Joseph McIsaac, CTO with Reflexion Network Solutions. "Right now a sender who uses SPF, their message goes to the remailer who forwards it to the recipient but that breaks SPF because the IP address of the remailer doesn't jive with that of the sender."
Recipients could white list remailers, McIsaac added, "but no one's doing that. It's a hassle and it costs money."
The fix, proposed by McIsaac in his presentation, is adding to the SPF specification a trusted remailer record for inbound mail that would complement the outbound record that exists in the spec. In this case, the recipient would be able to do a DNS lookup and discover the trusted remailer's record, because organizations that use remailers would enter the remailer's information in their own DNS record, he said.
"This restores the end-to-end design on which SPF was built ... and spurs SPF adoption," McIsaac said, adding that Reflexion is trying to find some "big industry players to get the ball rolling" on pushing for this addition to SPF.