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@xxxxxxx> 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@xxxxxxxxxxxx> 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/ > > >