From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elastic.org (unknown [IPv6:2600:3c03::f03c:91ff:fe50:73f]) by sourceware.org (Postfix) with ESMTPS id B0CC7385BF83; Mon, 6 Apr 2020 21:09:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B0CC7385BF83 Received: from vpn-home.elastic.org ([10.0.0.2] helo=elastic.org) by elastic.org with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1jLZ07-00057Z-76; Mon, 06 Apr 2020 21:09:47 +0000 Received: from very.elastic.org ([192.168.1.1]) by elastic.org with esmtp (Exim 4.92.3) (envelope-from ) id 1jLZ06-000LuK-Px; Mon, 06 Apr 2020 17:09:46 -0400 Received: from fche by very.elastic.org with local (Exim 4.92.3) (envelope-from ) id 1jLZ06-004sIj-PD; Mon, 06 Apr 2020 17:09:46 -0400 Date: Mon, 6 Apr 2020 17:09:46 -0400 From: "Frank Ch. Eigler" To: "Maciej W. Rozycki" 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 Message-ID: <20200406210946.GY323051@elastic.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: X-Sender-Verification: "" X-Sender-Verification: "" X-Spam-Status: No, score=-105.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP, USER_IN_WHITELIST 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:09:54 -0000 Hi - > [...] > 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. > 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. > 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. - FChE