- Will SPF/Microsoft Hybrid Stop SMTP Burn?
- Placing Blame Where Blame Is Due
- How Sender ID Works
- Fear Factor, Hope Factory
- Sender IDeology
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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."