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

["Tony Hain" <alh-ietf () tndh net>]

Dave Crocker wrote:
> 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.

The bad guys will know they are encapsulating. Joe-sixpack will just realize
that application xyz doesn't work unless he installs the 'Internet-fixer'(R)
tool that his buddy told him about. He has no idea what it does, and he
doesn't really care as long as the app works. 

> 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.)

The oversight is not recognizing the leap from technical space to political
space. All the engineering in the world will not solve fundamental political
trust issues. At one point in my past, the motto for my group was 'technical
solutions to political problems r us', knowing full well there are no
technical solutions to political problems. The best the technical side can
do is window dress so the politicians can claim victory. 

> 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.

I disagree that full authentication is a bad thing. What possible down side
is there to being able to track the source of every message? 

> 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.

So why not make it mandatory for all messages. Just to be clear I am of the
mindset that a new, parallel messaging system is needed. It does not have to
be a complete ground up redesign, but requiring a separate MUA & port for
transport would allow people to opt out of the legacy system at their own
pace. Assuming a completely separate system, why not make auth mandatory?

Tony

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