Re: [IETF] DMARC methods in mailman

[John C Klensin <[e-mail]>]

An observation on this one part of Ted's note...

--On Tuesday, December 27, 2016 11:10 AM -0500 Theodore Ts'o
<[e-mail]> wrote:

> All of the various solutions have downsides, or fit into the
> category of, "in the long term, it will allow for easier
> phishing, so the people who have inflicted DMARC on e-mail
> will have a some other non-standard change that will screw
> over mailing lists *again*" --- some of the MUA changes
> proposed fall into this latter category; if they are done on a
> wide scale, they *will* inspire the big mail providers to
> disallow List-ID: or Sender: headers.

I think this is one key issue the community keeps losing sight
of in this discussion.  When a technique is invented that we
know how to break or get around and then use it to attack a
problem in the hope that the bad guys are too dumb (or just
won't bother) to develop and apply the workarounds, we create a
few additional problems.  First, the "lazy and stupid bad guys"
assumption often turns out to be a matter of scale and
economics: as long as enough messages (or other attacks) get
through, they may not care but, if our technique has a real and
significant impact, then, in most cases, the workarounds will be
applied.  Such application will have at least two bad effects:
it will increase the economic and/or operational costs to the
good folks and/or victims and it will, in Paul Vixie's words,
make the bad guys smarter.  Second, even before that transition
occurs, it will have an effect that some of us find
objectionable on moral grounds -- shifting the risks and impacts
to those least able to defend themselves.

Both burden-shifting and creating obstacles that encourage more
sophisticated behavior by attackers are reasons we have given
against weak crypto an ineffective privacy protections, yet we
find ourselves embracing similarly-weak techniques in the hope
that they will help control spam, phishing, etc., for a while.
Sorry, but I don't get the latter as being any more reasonable.

   john