![]() |
31 JAN 2004 by Gordon Fecyk, Pan-Am Internet Services
The problem I see with most of the plans proposed is that they assume no trust initially, but there has been limited "how will someone untrustworthy break this" troubleshooting done. So they assume you're untrustworthy, but then assume you're trustworthy.
-- Attributed to Laura Atkins, November 2003
If you find a fundamental problem with the concept of accountability, then continue accepting spam by default. |
Prominent members of the Anti-spam community routinely misinterpret the objectives that sender verification proposals are trying to achieve. Postings like Ms Atkins' are very common and they assume the authors are trying to establish trust or mistrust, or we are promoting a universal solution to junk e-mail.
The authors of these proposals are not specifically trying to establish trust for a domain itself, but they are trying to establish trusted senders for a domain. There's a difference; a domain could have trusted senders but not be trusted itself, or could have untrustworthy entities as Ms Atkins correctly pointed out.
I've always explained that these proposals are trying to establish accountability, not trust, in a domain. An enterprise cannot be held accountable for junk e-mail if the junk e-mail did not originate from within the enterprise. That is like asking Exxon to be accountable for the polluting habits of S.U.V. owners. It is like asking Microsoft to be accountable for the network cable snaking out from behind your computer. These enterprises can be held accountable for abuse originating from within their ranks, and this is what a sender verification mechanism tries to achieve.
If we can force spammers, virus writers, script kiddies and politicians to use their own resources, they have little choice but to stop spamming or risk being held accountable. |
Junk e-mailers do what they do because we let them. They take over insecure mail servers and we accept mail from them. They send spam from dial-up and residential broadband Internet connections and we accept it. They abuse insecure proxy servers to hide their tracks - and even sell lists of them! - and we still accept their e-mail. They've hired virus writers to convert millions of unwilling users' computers into spam engines. And we still accept mail from them. By default.
How else could they hide their tracks so we accept their spam? We don't know. Personally, I don't want to know and I'd rather catch the next great spam exploit before the fact.
If we can force spammers, virus writers, script kiddies and politicians to use their own resources to abuse e-mail, they have little choice but to stop spamming or risk being held accountable. None of these people want to be held accountable, so they'll stop.
Accountability is only the start of a true anti-spam solution. But it is a start. Once held accountable, the Internet community will deal with spammers successfully. DMP and proposals like it provide accountability, that is all.
Understand this once and for all time: Accountability does not exclude privacy!
If I wanted to create a perfectly anonymous mail system for pan-am.ca, I will do it and succeed, and still no spammer would be able to spoof me and claim the e-mail came from my anonymous network. You could hold Pan-Am accountable for letting a user send abusive, vulgar, lewd or otherwise bad e-mail, as long as it actually came from Pan-Am, and I would probably eject them from my system. But they'd remain anonymous.
You can let me worry about how to ensure that they don't come back or make sure my system isn't abused, or you can block my domain's mail. It's up to you. Hold me accountable and I will change my practices. But they'd still be anonymous.
Ms Atkins asks why I would want you to assume I am untrustworthy, then to assume I'm trustworthy, when someone untrustworthy will break my system and send spam in my domain's name. I am not asking you to trust me. In fact, I want you to assume that I am untrustworthy, and then I want you to continue to assume I'm untrustworthy. But then I want you to assume I'm accountable. You'll refuse my domain's mail entirely if I let someone untrustworthy break my system, so I'm going to do everything I can to make sure no one does that, including my using a sender verification system.
I'm not perfect, and some idiot user is going to find a way to break my mail system. But at least you can show that my system was the cause of the breakage. And then I'll fix it. Or you'll keep blocking my mail.
Or maybe some idiot will try to send you mail with "luser@aol.com" in the from line from my network. AOL isn't going to ask you to accept it, so don't. That's what sender verification is for.
Don't be discouraged from criticizing these proposals. This is new ground we're working on. We've become so used to accepting everything by default that there are important e-mail features that require it. Supporting these features in an accountable e-mail system is difficult, but not impossible.
Every problem found with these proposals represents a new challenge to overcome. How to deploy the system without overloading DNS, how to protect subdomains, how to ensure mail forwarding still works, all of these are important. Each flaw corrected now is one less flaw to correct after the fact; after a spammer exploits it or after an innocent user is affected.
Don't ever stop finding things wrong with these proposals. As the authors of them, we'll do our best to fix them. Your contributions will ensure we produce the best solution to the sender verification problem possible. At least until SMTP is finally replaced with something we can use to hold senders accountable.
If you find a fundamental problem with the concept, however, then continue accepting spam by default.