Got Sender ID?
Date: Aug 6, 2004
Will SPF/Microsoft Hybrid Stop SMTP Burn?
As an IT manager, you're more likely than an end user to recognize spam as a problem in the workplace, and to predict that spam will be a message-related problem you'll still be dealing with in 2007, according to InsightExpress, a Stamford, CT research firm. But not only do IT personnel bear the technical burden of spam; the department must also field the complaints when users get fed up. Now an initiative is underway that lets administrators take matters into their own hands, and reduce the amount of spam the servers download—without requiring blacklists, fee-based mail, challenge/response schemes, or content filters. Before I describe the Sender ID approach to the problem, though, let's look at the problem as Sender ID attacks it.
Placing Blame Where Blame Is Due
Simple Mail Transport Protocol (SMTP) has holes you could drive a gassed-up airliner through—and spammers do. The overall problem is the ease of forging the originator's identity. The result is the current explosion of spam (spammers almost never use their own addresses), and its concomitant black rain:
fraud
narcotics offered without prescriptions or regard for age
Joe jobs (spam calculated to elicit server-bending loads of hate mail to a forged return address)
virus and worm attacks
phishing scams (letters forged to appear to be from financial institutions such as credit card issuers or PayPal, offering links to phony login forms that capture financial identity data)
Legitimate sites are hemorrhaging resources on spam wounds, and the companies around them are bleeding productivity through these holes in SMTP. If the holes that allow forged mail to reach target servers were plugged, a terrific amount of today's spam would stop. What Sender ID can do is less direct (and so, at first sight, less grand), but it's still tremendous: Sender ID can eventually stop a high percentage of spam overall—and many message bodies of forged mail—for those domains set up to participate. The participating administrator can bounce the forged mail, pass it to the intended recipient with a warning, or do whatever he pleases with it. Spamming from addresses that don't belong to the spammer just won't work when enough domains register on Sender ID–participating sites (and when enough of the world turns its back on mailers who stay outside the system).
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.
Fear Factor, Hope Factory
A lot of people are excited about Sender ID, and what it might accomplish, not the least of whom is Meng Weng Wong himself. "I think we can solve the spam problem very soon," says Wong, though not with Sender ID alone. One objection to authenticating senders by domain is that spammers will just keep buying new domains. "The reason spammers won't be able to get away with spamming in the future is because we will require everyone to show ID in the future," says Wong. "In theory, everyone will be able to require a 'credit' check on you. A big company like AOL has good credit. If a spammer tries to mail (through someone else's server), he won't get through, because he doesn't have good credit... If he tries to get through by pretending to be someone new and pretending to have no credit, it will require a deposit," says Wong.
Scare you a little? The hope of quelling spam and fear of holding someone's mail guilty until proven innocent are two sides of just one topic Wong presents on both sides in "Behind The Curtain: An Apology for Sender ID," a document posted one day after the publication of the Sender ID draft. This is a most amazing document: Neither a regret of the mission to save the world from spam, nor a "My Dogma, 'Tis of Thee" apologetic, but a very mu, a very "This way or that way?" "Yes"—open-minded, "Choose your own adventure" that will take you through many two-sided issues, such as XML versus proprietary code (SPF records were plain text, but Microsoft brought in XML for extensibility, which doesn't make the open source community's socks go up and down), and others. In addition, there is a more standard objections-asked-and-refuted page at the web site.
Declude, Inc. are the proprietors of the Declude Junk Mail anti-spam software package, which uses SPF as part of its logic. Scott Perry, chief software architect for Declude, says that one concern people have is the ability of SPF participants to forward email. "It can be a problem for people, depending on whether it says it's the person who sent it, or the person who originally sent it," says Perry. "The main problem is web sites that send on behalf of other people, such as greeting card web sites. It's fairly simple for those sites to get it to work: Change one address that they use to send email. When the web site sends out email, it uses an envelope sender. That's what's used while mail is being sent to determine who the actual sender is. That's what they would need to change to one of their domains. That would get by SPF. For the recipient, it would still appear to be from the user who had gone to the web site," says Perry.
Sometimes admins are displeased with more basic things.
"Well, the idea is good; I'm not thrilled with the implementation," says Robert Dinse, president of Eskimo North, a national ISP. "[A] separate C library and a patch to sendmail, NOOOOO! This is something that can, and should, be implemented with sendmail rules with absolutely no need to modify the code," says Dinse. "Sendmail already has within it the ability to do DNS lookups (this uses a DNS TXT record) and the ability to do the requisite pattern-matching on various headers, so there is absolutely no need to write new code into sendmail to do this. I've added text records, but I'm not going to hack sendmail to do this. I'd be willing to bet in the next release or two they'll kick out new rules to handle it."
Perry believes that when SPF becomes a standard, the sendmail people will include what's needed in the base code, so no special rules will be required. Dinse says that the "hacks" rule set would be a better solution than bloating the code.
Then Wong hits the IT manager in the hardware: Spam is nearing 80% of all email. "At PO Box, we run ten machines, so eight machines are used for spam," says Wong. "If we could cut that down from ten to two, I could give everybody a raise."
That's not going to happen from Sender ID alone, as Wong mentioned in a letter:
"[P]ublishing records is just the first step. There will be other steps down the road, like cryptographic signing. The best way for IT managers to stay abreast of these changes will be to get involved in the SPF community. They can do this by signing up to the mailing lists where important announcements are made.
Industry leaders like Sendmail, AOL, and Microsoft are already on those lists. In the next few months we'll be setting directions and deadlines for the industry to change. Most people won't need to change but certain parts of the ecology will. I would like to give them lots of notice about what is going to happen, and have everyone prepared for change, than have them wake up one day and see his mail is being bounced."
You may be wondering whether the world should keep rolling this whole machine along, or if your organization should join or stay out, or if you should be freaked out by possible scenarios such as Voluntary Adoption; Refusal to Adopt; and this, from the web site:
"Guerilla Adoption. Benevolent third-parties may start publishing SPF lists for laggard domains who don't publish those lists themselves. Eventually domains will get tired of these lists being out-of-date. Or commercial services will evolve, to cater to domain owners who are too frazzled to set up SPF records."
Sender IDeology
It does make for vigorous politics, as well as economics, practicalities, and manners. There may be two ways of doing it, but Wong wants it done: "We're trying to change the world in twelve months, and we need basically every domain out there to publish SPF records ASAP."