From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id E2A38385BF83; Tue, 7 Apr 2020 09:53:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org E2A38385BF83 Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jLkuz-0004T8-PW; Tue, 07 Apr 2020 09:53:17 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1jLkuz-0006TE-L2; Tue, 07 Apr 2020 11:53:17 +0200 From: Florian Weimer To: Jonathan Wakely Cc: "Maciej W. Rozycki" , "Frank Ch. Eigler" , overseers@gcc.gnu.org, "Frank Ch. Eigler via Gcc" , Overseers mailing list , Segher Boessenkool , Alexander Monakov , "Frank Ch. Eigler" Subject: Re: Not usable email content encoding References: <20200317194613.GH22482@gate.crashing.org> <20200317195158.GC112952@elastic.org> <874kumt0bh.fsf@mid.deneb.enyo.de> <20200318110109.GA5496@redhat.com> <20200318142239.GF112952@elastic.org> <3af9771e-e577-f2a1-843e-c2b078bfc4ea@t-online.de> <20200318162250.GG112952@elastic.org> <20200406210946.GY323051@elastic.org> Date: Tue, 07 Apr 2020 11:53:17 +0200 In-Reply-To: (Jonathan Wakely's message of "Tue, 7 Apr 2020 08:29:56 +0000") Message-ID: <87wo6rr59u.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-9.1 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: overseers@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Overseers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2020 09:53:31 -0000 * Jonathan Wakely: > On Mon, 6 Apr 2020 at 23:00, Maciej W. Rozycki via Gcc wrote: >> And can certainly score a positive though not a definite rating in spam >> qualification. I don't think we ought to encourage bad IT management >> practices by trying to adapt to them too hard and hurting ourselves (our >> workflow) in the process. > > What you call "bad IT management practices" includes how Gmail works, > which a HUGE number of people use. > > A number of lists I'm on switched to our current style of minging a > year or two ago, because gmail users were not receiving mail, because > gmail was rejecting the mail. Gmail can drop mail for any reason. It's totally opaque, so it's a poor benchmark for any mailing list configuration changes because it's very hard to tell if a particular change is effective or not. Many mailing lists have *not* made such changes and continue to work just fine in the face of restrictive DMARC sender policies and enforcement at the recipient. In general, mail drop rates due to DMARC seem to increase in these two cases if the original From: header is preserved: * The sender (i.e., the domain mentioned in the From: header) publishes a restrictive DMARC policy and the mailing list strips the DKIM signature. * The sender signs parts of the message that the mailing list alters, and the mailing list does not strip the DKIM signature. If neither scenario applies, it's safe to pass through the message without munging. The mailing list software can detect this and restricting the From: header munging to those cases. I doubt Mailman 2.x can do this, so it is simply a poor choice as mailing list software at this point. A possible workaround which works in almost all cases would be to make sure that Mailman performs as little message munging as possible: Do not strip MIME multiparts, do not rewrite the subject line to add prefixes, do not rewrite To: and Cc: lines, and so on. With such a configuration, the message would have to assert in a DKIM signature that it does not have a List-Id (or similar) header, but that this is really a fringe case. I believe the OpenJDK lists use such a workaround. Microsoft and Google participate there (as far as I know, both microsoft.com and google.com have restrictive sender policies), and their messages are only dropped if Mailman filters out a text/html multipart, therefore editing the MIME headers.