Re: [IETF] DMARC methods in mailman

John C Klensin <> Tue, 27 December 2016 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AF8B12948C for <>; Tue, 27 Dec 2016 10:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MnTPyEfPj68w for <>; Tue, 27 Dec 2016 10:13:01 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C43A41293F4 for <>; Tue, 27 Dec 2016 10:13:01 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1cLwF8-000MNB-3n; Tue, 27 Dec 2016 13:12:58 -0500
Date: Tue, 27 Dec 2016 13:12:53 -0500
From: John C Klensin <>
To: Theodore Ts'o <>
Subject: Re: [IETF] DMARC methods in mailman
Message-ID: <>
In-Reply-To: <>
References: <20161227013401.11378.qmail@ary.lan> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <>
Cc: IETF general list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Dec 2016 18:13:03 -0000

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

--On Tuesday, December 27, 2016 11:10 AM -0500 Theodore Ts'o
<> 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.