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.
webtv.net. 300 IN MX 10 smtpinvite.mx.webtv.net.
webtv.net. 300 IN MX 20 smtpin.mx.webtv.net.
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
http://www.messagefire.com/ Next Generation Spam Defense
http://commons.somewhere.com/buzz/ 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
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg