From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa5.hgst.iphmx.com (esa5.hgst.iphmx.com [216.71.153.144]) by sourceware.org (Postfix) with ESMTPS id C67FA385BF83 for ; Mon, 6 Apr 2020 21:59:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C67FA385BF83 IronPort-SDR: sPKlQ44C6aA7kLrau7Ap8R1hmSweag3QP3EG7DW6d19UbxfFvjU6h3WRRLseXqDCqk7ezIvk6C C76wxh0/jffc7VWOZuJ8tOZIJgGaF7X10JMeu4n1AIfVHuhMNHak5fAb1Qb6Q4FloN9HA157hA FroyT9SnEssZLqh+v9mxMZjOf21OWpOlMwoya5/prvouz+qrSwxsnHrFdGZaonsB3uYUQum2ed 2g6vv7iuTywW4vc/dghEUqj7QWtEOnwlkl+JTwOZu8wVou3Q3nqnuNEehtGtx4yASrhvrRTd95 IqI= X-IronPort-AV: E=Sophos;i="5.72,352,1580745600"; d="scan'208";a="135035999" Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 07 Apr 2020 05:59:33 +0800 IronPort-SDR: IuPWR5ARdMzEJutGlSiVVz74FGL8q27S9RgNuqnuoP3WdMrVRQvz+oK4gtJFPGeTl0zvsJR60r +LCJYfpXk0IqUS9a7RjESaQjTf931qGWstsU5zpkLe2+4soGfui/YA2KUJJLmHfD6HrJYgGvNg rbU1oQky/PvZdsSeUdynJs0IjzcDQC8epl59RkFiIH+EeohnDLwfvnUm8fRGkdau/rZWFYQHZl K6yzUw+MNAZVDBZctKV464jwSsY8B9Gic0EouHHl5A+inbdfn7WkxH5T+KGTazpOF4TbYeGPb0 PbVXwUg/zEtFHiFAed7Ocb2X Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2020 14:50:50 -0700 IronPort-SDR: ZqW4LWHjWbVBznt5FsnbijL7TSnqMXPsJBNOlBe5qU9GzTDcm606bWRyvAmEjZt0w875zNcLEy TF9k6qmIUOM8bvFiehaaBrStIGUHiVDY3fZr72ZotRDQ7GbdGz9vF+R0IGdnelrJ36Z++q7oaU E1l4UkgL8xbR8UTzAko6fceYZ1uFN73AKDGt026Z9Pe9VHAyP3T26T1PzidoB+JvUBoxFtR3CY l6QBDpyUwMiafI3WSBH0DRV5RsVsd8dbiyWxyyNnPgAMJedLXYkTT7lW/T4T5lKRuQ53yL/+OS MAs= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Apr 2020 14:59:31 -0700 Date: Mon, 6 Apr 2020 22:59:26 +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: <20200406210946.GY323051@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> <20200406210946.GY323051@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=-7.8 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 21:59:35 -0000 Hi Frank, > > 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). > > That part is at least pretty easy: use > git format-patch --from "Real Name git " > which will then force a second fake From: header into the body of > the commit email, where git-am can find it. Sure, there are various ways to deal with that, both on the sender's and the receiver's side, however all require a manual intervention and are therefore prone to a human error. Which will obviously happen sooner or later. > > 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. [...] > > Unfortunately naive .forward based forwarding looks exactly like faked > or spam email to a third party MTAs. 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. > > 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? [...] > > I'm not sure, but their mails tend to be laden with a vast number of > Cc:'s, which bypass mailing list reflectors. Surely all the bots receive messages via a mailing list subscription though. Cc's are solely for maintainers, reviewers or other explicitly interested parties. Some maintainers actually require submissions to come via the relevant mailing list rather directly to them. Somehow it works. Thank you for your input regardless! Maciej