From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 41D9A385DC2E; Mon, 6 Apr 2020 23:21:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 41D9A385DC2E Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 036NHw6q016487; Mon, 6 Apr 2020 18:18:24 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 036NGFpe016369; Mon, 6 Apr 2020 18:16:15 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Mon, 6 Apr 2020 18:15:54 -0500 From: Segher Boessenkool To: "Maciej W. Rozycki" Cc: "Frank Ch. Eigler" , Bernd Schmidt , overseers@gcc.gnu.org, "Frank Ch. Eigler via Gcc" , Overseers mailing list , Alexander Monakov , "Frank Ch. Eigler" , Florian Weimer Subject: Re: Not usable email content encoding Message-ID: <20200406231554.GT26902@gate.crashing.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-41.6 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, TXREP, T_SPF_HELO_PERMERROR, T_SPF_PERMERROR autolearn=no 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: Mon, 06 Apr 2020 23:21:59 -0000 Hi! On Mon, Apr 06, 2020 at 09:58:27PM +0100, Maciej W. Rozycki wrote: > On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > Out of curiousity, is this rewriting you are talking about the cause for a > > > lot of mails showing up as "From: GCC List" rather than their real senders? > > > This has become very annoying recently. > > > > Yes, for emails from domains with declared interest in email > > cleanliness, via DMARC records in DNS. We have observed mail > > -blocked- at third parties, even just days ago, when we failed to > > sufficiently authenticate outgoing reflected emails. > > > > AIUI, all this effort is driven by wanting to defeat not just spammers > > but also real security problems like phishing enabled by forgery, > > including specifically the From: header. > > And it has actually broken GCC's patchwork: > , which I used to use to > track my patches. Yes, I noticed (I run that patchwork). > Now I cannot do that anymore as patches submitted from > my WDC address are marked as coming from , which > obviously means they are not attributed to me. Yup. > I am fairly sure it breaks `git am' too, requiring a `From' override in > the change description for author attribution in patch application to work > reliably (I tend to work on my outbox when applying my own patches, so I > avoid this issue, but I am sure the issue will hit someone sooner or > later). Yup. > And of course I cannot use the `macro@' pattern anymore to select mailing > list messages in my inbox that I sent myself. Frankly it's the least of > the annoyances, but still, and they all add up. It would break even the built-in mutt "you sent this yourself" detection. > This is all silly, requiring the SMTP envelope sender to match the `From' > header breaks even the most basic e-mail mechanisms like the use of a > `.forward' file. This even *never* is true for my mail setups, and never has been, and it all works fine. > Can we please do something about it? Is functional > regression the price we absolutely need to pay for progress? > > How come the Linux kernel people who do e-mail patch management on a > vastly larger scale than we do, both in terms of traffic and the number of > mailing list subscribers, can get away without all these odd quirks in > their list server management? Perhaps it would be good asking them how > they handle their stuff? If someone cannot connect to them because they have a broken mail setup, the kernel people say "your problem, get a working mail setup", and that works fine so far (99.999% of people *can* get working mail, just not always company mail). Segher