ietf
[Top] [All Lists]

Re: Incremental hacks and letting abusers control the agenda (was: Re: Google threatens to break Gmail)

2015-10-28 10:28:11
John, Dave, this is exactly the conversation I want to have.   Is this 
conversation happening somewhere in the IETF?   I confess that I haven’t put a 
ton of effort into figuring that out—I’ve been studying the current documents 
and have done some test implementations to eliminate some of my ignorance on 
this topic, but I haven’t quite gotten to the point where I know more of what 
to say than random ideas like "how do we close the loop between the browser and 
the MUA so that wanted notifications can be securely marked for reliable 
delivery" and that sort of thing.

On Oct 27, 2015, at 1:47 PM, John C Klensin <john-ietf(_at_)jck(_dot_)com> 
wrote:

For whatever it is worth (and the rarity in email protocol and
architecture discussions is, IMO, worth noting), I completely
agree with Dave's comments and analysis below.  

Let me add one observation about scope: to a considerable
extent, "solving" abuse by mechanisms close to the target
recipient also misses a lot what should be the point because the
damage -- measured in added hacks or additional processing and
bandwidth requirements-- is done almost as soon as the problem
message is sent.  By ignoring it and applying patches and
workarounds at the recipient end (whether those are to
accommodate badly-formatted messages or to mitigate deliberate
abuse) reduces or eliminates pressure on originating systems to
get things right, prevent the abusive behavior, or create legal
deterrents to that behavior that are enforced sufficiently to
act as a deterrent.  As Dave says, it has been that way for
40-plus years.  However, if we want fixes that keep the system
working, rather than more and more hacks that drive us toward a
small and homogeneous set of "acceptable" mail systems, we'd
better start looking at the whole system, figuring out what we
want, and making it work.

   john


--On Tuesday, October 27, 2015 07:56 -0700 Dave Crocker
<dhc(_at_)dcrocker(_dot_)net> wrote:


Web registration systems now tell users to whitelist mail
from their domains, which would be cool if it could be done
automatically rather than through manual intervention, and
users are now accustomed to searching for important mail that
hasn't arrived in their junk folders.  


Consider that example as a touchstone to the larger set of
issues, here:

  Anti-abuse mechanisms (and many other 'fixes') for email
tend to be added piecemeal and locally, rather than considered
as end-to-end systems issues.

  On the average, the focus of concern is local operations,
rather than user interaction and user experience.  It's
simpler and quicker to work that way, but it winds up turning
email into a technical and functional Tower of Babel. This
approach to dealing with email problems has been an issue for
at least 40 years.  Recipients complained to local operators
who put some local hack in place to deal with the symptoms.
Often the originator of the problem never hears about it.

  Email is by far the largest and most complex distributed
system on the Internet.  Having complex objects travel
multiple hops along many independent administrations is a
pain.  So let's minimize hops and administrations and
eliminate the cases that need to greater flexibility email
gave with the more highly distributed administrative and
functional design.

  We need to properly distinguish identities from identifiers
and we need to properly distinguish among the many independent
actors in the handling sequence and we need to distinguish
trust from mistrust.  Each of these distinctions can produce
very different approaches for proposals.  For example, trying
to look for bad actors is fundamentally different from looking
for good actors.  So is evaluating an operator versus an
author.

  What most folk have moved to is a model in which a user's
identity, identifier and operational support are all tightly
integrated and controlled by a single administration.  For
simple scenarios, that works well enough to cause people to
treat more varied scenarios as 'problems' rather than 'userful
requirements'.

  The current evolution of systems changes for anti-abuse are
largely reactive -- the abusers set the agenda -- and largely
turn email into a Procrustean bed:  Only usage scenarios that
are supported and protected cleanly are the easiest and most
restrictive on users.  Since that satisfies the vast majority
of current use, the disenfranchisement of the much smaller
minority of other, legitimate scenarios can be ignored,
independent of the problems caused to those who are
disenfranchised.

Producing general, end-to-end changes that afford necessary
protections and support the widest possible range of
functionality is much more work than doing localized,
incremental hacks.  (Not that the localized, incremental hacks
are cheap or quick either.)

We need to stop thinking we can eliminate abuse.  We need to
start thinking in terms of end-to-end trust models that scale
and support varied usage scenarios.  We need to focus on being
able to use trust of operators, more than on trust of authors.

And mostly, we need to stop creating one hack to fill in the
gaps for another hack.  Or rather -- since the hacks often are
the result of an emergency -- we need to stop thinking the
hacks actually 'solve' problems rather than merely creating
new ones.

d/