[Top] [All Lists]

Re: [Asrg] 6. Proposals - AMTP (rev 01) - MPC

2003-10-06 18:10:40
At 5:42 PM -0400 10/6/03, Ken Hirsch wrote:
I have proposed a specific anti-spam certificate which would only be issued
when the subscriber states what anti-spam policy will be followed and
contractually agrees to it.

AOL currently blocks 2 billion spam messages a day. Over 5% of the internet is in their blacklist. All the major ISPs use trust-based systems based on IP address. Doing triage at that level is the only way they can decide who will get through without heavy filtering, who needs to be filtered, and who needs to be blocked outright. The major "good" bulk senders all know this, and split their mailings onto different IP addresses, depending on whether it's a known good customer, or one about whom they know less. Big customers get a dedicated IP address for their outbound mail.

Consider the following DNS entries and think about what they mean.              300     IN      MX      10              300     IN      MX      20

This triage isn't just done because they want to avoid false positives, it's done because they want to avoid the cost of filtering so many messages.

All those decisions are made *before* the HELO prompt. Trusted email already exists, but the token isn't a cryptographic code--it's an IP address.

Where in that environment do you put the code to check a certificate on a particular sender, and what is the performance penalty? Do you think the ISP is actually going to accept the email and begin the transaction before they make a decision? Let alone do a per-domain lookup? The number of IP addresses may be large--but the number of legit mail servers is far smaller than the number of domains.

I would assert that the only place that a certificate, or any trust-based system, will be adopted is at the DNS level. As such it will provide an initial level of trust for the given IP address, negating the need for negotiations between ISPs and senders (which is how it's currently done for the big senders). And of course the result will be cached--they certainly won't be decoding certs on every connection. Such a trust system doesn't replace the current system used by the major ISPs, but it makes it more available to smaller companies who can't build their own trust database, and it augments those databases that exist.

Yes, this approach has nasty side-effects. Your IP is trusted only as well as the average quality of your users. If you're on a floating IP address you will never be trusted, and often not even allowed to send mail directly. If you don't control your reverse DNS you're in the same boat. But the fact of the matter is that in those cases the major ISPs *already* treat you as a second-class citizen. Your email is never going to be accepted by that smtpinvite MX entry, and it's always going to get maximum filtering--if indeed it's accepted at all.

Domain-based or sender-based certificates are nice for techies and cool end-user software that doesn't exist yet, but they provide no value at all to the major ISPs. They don't scale; ISPs are iffy about doing one more DNS lookup on a connection, let alone validating certs. And never mind the infrastructure changes. If you want to provide an authentication system that will get adopted, design one that solves the problem for AOL, MSN, RoadRunner, Earthlink and the other big ISPs.
Kee Hinckley         Next Generation Spam Defense  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

Asrg mailing list