[dmarc-ietf] Yet another mailing list solution thread

"Stephen J. Turnbull" <stephen@xemacs.org> Sat, 31 May 2014 13:07 UTC

Return-Path: <stephen@xemacs.org>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149C21A08B5 for <dmarc@ietfa.amsl.com>; Sat, 31 May 2014 06:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.509
X-Spam-Level: *
X-Spam-Status: No, score=1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_16=0.6, MANGLED_FROM=2.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGLVUyHbcxMu for <dmarc@ietfa.amsl.com>; Sat, 31 May 2014 06:07:12 -0700 (PDT)
Received: from mgmt2.sk.tsukuba.ac.jp (mgmt2.sk.tsukuba.ac.jp [130.158.97.224]) by ietfa.amsl.com (Postfix) with ESMTP id 105671A08B1 for <dmarc@ietf.org>; Sat, 31 May 2014 06:07:11 -0700 (PDT)
Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mgmt2.sk.tsukuba.ac.jp (Postfix) with ESMTP id E052B970B30; Sat, 31 May 2014 22:07:06 +0900 (JST)
Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id D25AB11F235; Sat, 31 May 2014 22:07:06 +0900 (JST)
From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Brandon Long <blong@google.com>
In-Reply-To: <CABa8R6ucgFfbkkH_BcQkyM7PmPPteWd-YCK_RX_MgnPdcMdesQ@mail.gmail.com>
References: <CABa8R6ucgFfbkkH_BcQkyM7PmPPteWd-YCK_RX_MgnPdcMdesQ@mail.gmail.com>
X-Mailer: VM undefined under 21.5 (beta34) "kale" 2a0f42961ed4 XEmacs Lucid (x86_64-unknown-linux)
Date: Sat, 31 May 2014 22:07:06 +0900
Message-ID: <87r43a5c79.fsf@uwakimon.sk.tsukuba.ac.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmarc/KvSFv66Mz8UipXQ0477UgO5WKio
Cc: "dmarc@ietf.org" <dmarc@ietf.org>
Subject: [dmarc-ietf] Yet another mailing list solution thread
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 31 May 2014 13:07:14 -0000

Brandon Long writes:

 > 1) Reject posting from p=REJECT users

+1 <0.2 wink>

 > It seems like [ignoring DMARC bounces when checking if the
 > recipient is able to receive] should be relatively uncontroversial,

Mailman is already working on this.  Unfortunately, some domains just
use a generic 5.7.x policy bounce, and other don't even give you that
much information.  (We are guessing, but backtracking to the sender --
you don't always even get that information -- and correlating with
other DMARC bounces, we're pretty sure that these are DMARC bounces.)

 > messages would be rejected... Perhaps we should agree on an
 > extended smtp status code that such rejections should use in order
 > to make this easier to implement.

This will take years to diffuse into the installed base, and some
sites have this boneheaded idea that giving any information about why
a message was rejected harms their security, so won't implement anyway.

 > [Rewriting From:] could potentially use some finessing or
 > standardization.  For example, several MLMs are moving the original
 > From header to X-Original-From, I could also imagine a
 > List-Original-From or List-Poster header.  Standardizing on that
 > would allow clients to do intelligent things about the display of
 > the two pieces of information, or handling reply-to better.

The *last* thing we want is clients doing anything intelligent with
any of those headers.  The problem that DMARC addresses has nothing to
do with the letters F-R-O-M.  It has to do with identity alignment.
It just happens that RFC5322 (and predecessors) standardized From: for
conveying originatory identity.  So as soon as MUAs start displaying
Use-This-Field-To-Bypass-DMARC: to users, DMARC will *need* to be
revised to sign that one, too -- with a signature authorized by the
Author Domain, *not* the ML domain.  This of course is impossible
without Doug Otis's TPA-labels or something like that.

 > What can DMARC enforcing domains do right now:

 > 1) Whitelist mailing lists from enforcement.  This is obviously a hole in
 > DMARC which lowers the overall utility.  Its basically saying "we don't
 > trust your p=REJECT, we'll sometimes downgrade it to p=QUARANTINE".

That horse already left the barn.  I don't know what GMail's criterion
is, but our testing demonstrates that some mailing list posts are
passed through to the spam folder rather than rejected.

I don't understand what you mean by "lowers overall utility".  In
fact, it's quite clear from the way Yahoo! is advocating various
mitigation strategies that they really do not mean DMARC reject, they
mean Do-What-I-Mean reject.  That's what GMail gives them.

For the others, I agree with John Levine's comments.