Clueless service restrictions (was RE: Anti-spam System Idea)

Dave Crocker dhc at dcrocker.net
Wed Feb 18 23:07:51 UTC 2004


Folks,


TH>  If you insist on restricting the service to a small set of 'approved'
TH> applications, people will simply encapsulate what they really want to do in
TH> the approved service and you will lose visibility.

A small elaboration:

You will make life intolerable for the average user -- ie, the folks not
likely to have the skills are working around artificial barriers -- but
the non-average user -- ie, including the bad guys -- will encapsulate.


DG> The RFC for mail was very well designed.  If people simply stuck to the
DG> orginal RFC (~800 something) and managed more of their own small systems
DG> then this spam thing just wouldn't be the problem that it has become...
DG> would it?

Well, yes, but no.

(I'm finding that a popular response today, because email and spam are
so messy.)

Email does what it was intended to do pretty well. As with
multiaddressing (multihoming and mobility) there is a basic question
about the architectural choice for making major changes. I keep wanting
the enhancements to stay out of the core. For both areas of work.

So, the original Internet mail service does nothing to prevent spoofing
or spamming.  I think most folks thought that content signing (eg, pgp
or s/mime) would be a sufficient solution for authentication and I'd
guess we just plain missed the likelihood of spamming.  However I still
tend to believe that having seen the problem earlier should not
necessarily have made the core mail facilities different.

In all likelihood, some for of "message" authentication is needed,
possibly along the lines of DomainKeys or Teos. My sense is that the
technology for this is quite tractable and requires no changes to the
email infrastructure. (On the other hand, we need to pay very close
attention to the failure to cross the chasm, for pgp and s/mime.)

I think that the "registration" oriented authentication mechanisms (spf,
rmx, lmap, etc.) can be useful only when the authenticator is the
hosting network provider, rather than a message author.


SMB> In almost all circumstances, authentication is useful for one of two
SMB> things: authorization or retribution.  But who says you need 
SMB> "authorization" to send email?  Authorized by whom?  On what criteria? ,

This certainly goes to a core set of issues.  The fact that something is
authenticated does not mean it is not spam.  On the other hand,
authentication is a good thing unto itself.  On the other hand, making
it a pre-requisite for _all_ email activity is very much a _bad_ thing.

Authenticating mail will help deal with two problems: forgery and
accountability. Forgery of the From field is now a major problem. It has
always been a major threat. So, finding a tractable way of prevent or
detecting forgery is a worthy goal unto itself. It does not "solve"
spam. Rather I think of joe-jobbing and phishing as doing a really
spectacular job of market segment development. It has made clear to
target customers why they need a solution.

Accountability just means that there is a good basis for tracking down
problematic sources.  That, too, is a good thing.

d/)


--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>




More information about the NANOG mailing list