From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.hgst.iphmx.com (esa3.hgst.iphmx.com [216.71.153.141]) by sourceware.org (Postfix) with ESMTPS id 99A80385BF83; Mon, 6 Apr 2020 20:58:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 99A80385BF83 IronPort-SDR: M6KYZoSpD3hYzKXNoabu+Z8t/4XrO5/xD/WbqSAt/NT/oiezEme9KOVHt4q9orB6u2LYA3tfX7 fQmuJUxs5AmXvNSn/O2okQoM47oLzHIhuXurP/yRTjMbP16ZW2VOfwTA3Ok1WyyVQ7Cl5+vtU0 aIr0bAMC4Czs+hMwt+OBzWHdkrDxwRvYBprU/Etq2J5Jt350ZuRfZ5KR+ivOuM7OkIeEGjGDmY DgKpUoV+WiGbEORo1GnJOKCjr3vuQfvDFwz7tLyQrVHZVsxN6g3H+7pZsEdov+pq1h+3OGtUsY xjg= X-IronPort-AV: E=Sophos;i="5.72,352,1580745600"; d="scan'208";a="139008800" Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 07 Apr 2020 04:58:34 +0800 IronPort-SDR: 4UTpLZ4e9mgg5MpH/srCZyvLj7uakMgkE8wk+xus4GIUsy2q09SK/H3q+HEhRleqKWOaS+NYTP w98waM6eFd5RSb2UTpy2fRdorwZJZ32ngXgB/HwTfD+53LPOTShMB/2itv5HpS3ughf6lV6HrG 7DuFpu/2ixx7WEQhYvW7GHCm6LPT8LGTPQ6bDBTZ0gFNdqxFgKqEgGTe6fVCJm6t5Z1hTfS3A+ JWx8JXzPKGNkysBZ0y2Ygf0O2S2GJbn9fRbmgrj4csrcZU/9Cdr3PGFzTY2dVfzOEl/inCbqzj AeI8G9ASg++obPTubqEdo7xO Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2020 13:49:16 -0700 IronPort-SDR: CGEso+E61km+zPB0mWva9ezgKvFRKAUhllZoZWkhD94L1kgTtb/WwbI0Kdqj19EyP73Z0O/cp4 lL5UGPQvgxMI/i+8N0K8xdd5rFk9FIbZN5K6sr1oTkdrQ0o5uk9upOUzvvKzfOwll1GDtlrr2+ H77U9bl1oO/nmDyzJJ/+EfN2sH/g7SWqSVHedb/IaAUTqdp4qK+i61SKqU5Zo1BiqySzAJ1HYx sHbksLWGSMwISDTrnC7hi/ezHJ3WUYessjNF97htRcHPKoGq73W/RNwxQe+vznTpxl70hXl4i6 D48= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2020 13:58:32 -0700 Date: Mon, 6 Apr 2020 21:58:27 +0100 (BST) From: "Maciej W. Rozycki" To: "Frank Ch. Eigler" cc: Bernd Schmidt , overseers@gcc.gnu.org, "Frank Ch. Eigler via Gcc" , Overseers mailing list , Segher Boessenkool , Alexander Monakov , "Frank Ch. Eigler" , Florian Weimer Subject: Re: Not usable email content encoding In-Reply-To: <20200318162250.GG112952@elastic.org> Message-ID: 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> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-8.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: Mon, 06 Apr 2020 20:58:36 -0000 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. 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. 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). 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. 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. 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? Maciej