[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.
- [dmarc-ietf] Yet another mailing list solution th… Brandon Long
- [dmarc-ietf] Yet another mailing list solution th… Stephen J. Turnbull
- Re: [dmarc-ietf] Yet another mailing list solutio… J. Gomez
- Re: [dmarc-ietf] Yet another mailing list solutio… John Levine
- Re: [dmarc-ietf] Yet another mailing list solutio… Elizabeth Zwicky
- Re: [dmarc-ietf] Yet another mailing list solutio… Brandon Long
- Re: [dmarc-ietf] Yet another mailing list solutio… Brandon Long
- Re: [dmarc-ietf] Yet another mailing list solutio… Scott Kitterman
- Re: [dmarc-ietf] Yet another mailing list solutio… Brandon Long
- Re: [dmarc-ietf] Yet another mailing list solutio… Scott Kitterman
- Re: [dmarc-ietf] Yet another mailing list solutio… Scott Kitterman
- Re: [dmarc-ietf] Yet another mailing list solutio… Murray S. Kucherawy
- Re: [dmarc-ietf] Yet another mailing list solutio… Douglas Otis
- Re: [dmarc-ietf] Yet another mailing list solutio… John R Levine
- Re: [dmarc-ietf] Yet another mailing list solutio… Brandon Long
- Re: [dmarc-ietf] Yet another mailing list solutio… Brandon Long
- Re: [dmarc-ietf] Yet another mailing list solutio… John R Levine
- Re: [dmarc-ietf] Yet another mailing list solutio… Scott Kitterman
- Re: [dmarc-ietf] Yet another mailing list solutio… John Levine
- Re: [dmarc-ietf] Yet another mailing list solutio… Stephen J. Turnbull
- Re: [dmarc-ietf] list side validation, was Yet an… John Levine
- Re: [dmarc-ietf] Yet another mailing list solutio… John Levine
- Re: [dmarc-ietf] Yet another mailing list solutio… Stephen J. Turnbull
- Re: [dmarc-ietf] list side validation, was Yet an… Brandon Long