Pan-Am Internet Services

This Is About Accountability, Not Trust.

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.

Accountability is the key, not trust

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.

Accountability does not exclude privacy

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.

Let me worry about The Untrustworthy in My Domain.

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.

Continue to be Critical. This is Important.

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.


Return to Rant Archive
Return to ESM Home Page

Pan-Am Home Page