Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
How Sender ID Works
Sender ID is the marriage of Meng Weng Wong's Sender Policy Framework (SPF)—forged from two prior standards (Gordon Fecyk's Designated Mailer Protocol (DMP) and Hadmut Danisch's Reverse MX (RMX)—and Microsoft's Caller ID for Email, published June 23, 2004.
SPF was originally designed to fight the kind of spam problems that show up most heinously in Joe jobs; attacks forged at the envelope-sender level—the return path. That scrap of the envelope gives angry mobs of hate mail directions to the innocent victim, so when "Joe" pours a bowl of Raisin Bran and fires up his flat panel, he learns some new strings of words that might include, "Reported you to the FBI for sending me that kiddie porn." With SPF, a message transfer agent (MTA), such as UNIX sendmail or Microsoft Exchange Server, uses SPF to verify the envelope sender during SMTP time. If the envelope domain doesn't match an IP (or range) registered as authorized to send from that domain, the domains participating in Sender ID will fail that piece of mail at some level and deal with it according to the local configuration.
Big picture: Everyone in a position to do so publishes SPF records for their domains or nags those who are. There's even an online template to make it easier to tell your DNS which servers in the world you want to allow to send mail under your domain name. Then switch to Simple Authentication and Security Layer (SASL) SMTP, in case your users decide to travel and want to send mail from another server. If you support SASL on ports 25 and 587 (587 is authenticated), your traveling garden gnome can email you from an elder hostel that blocks port 25, and tell you how many geek license plates he's seen on his trip. ("I got a picture of PGP!") Don't forget to write all your users about changing the way their mail clients log in; they're going to need a username and password now. It's a one-time change to stop billions of pieces of spam.
But as useful as that is, more needed to be done—hence the lovely bride from Redmond.
Back in May 2004, with the ink still wet on the agreement between SPF and Microsoft to merge SPF and Microsoft Caller ID for Email, SPF penned a document still on the SPF web site in late June, under the title "What SPF Is And Is Not." Besides being refreshingly honest in all directions, the document 'fessed up to this weak spot with SPF alone:
TIPSPF is designed to protect the envelope sender address, the return-path, where bounces go. It can also be used to protect the header "From:" address with some added complexity. If you are not confident of the difference, you will find RFC2821 and RFC2822 enlightening. Protecting the headers is inherently more challenging, because spammers are very good at forging headers, and you have to carefully choose between Sender, From, Resent-Sender, and Resent-From; it's a can of worms.
The merger with Microsoft's Caller ID for Email helped sort through that can of worms. First, it lets SPF handle what it handles best: the return path on the mail "envelope." Under "New SPF," or Sender ID, Microsoft Caller ID lets a message user agent (MUA), such as Eudora or Outlook, check inside the headers on the "letter" inside, identifying the type of forgeries used in phishing scams. You can find the entire Sender ID Draft Specification update of June 23, 2004 here.