On Wed, Dec 22, 2021 at 04:26:39AM +0100, Ævar Arnfjörð Bjarmason wrote: > That GGG does this is one reason I haven't considered using it. It > breaks all sorts of E-Mail workflow assumptions from polluting the > address book for every person who uses it, to any "from:<addr>" search > needing special consideration etc. > > Of course you'd need authentication etc, but is there a reason for why > such tooling can't work more like an SMTP relay and less like GGG which > (for some reason) insists on taking over the "From" header? This would require pretending that we're authorized to send mail from the domain name of the commit author, so this unfortunately won't work (and hence the reason why GGG does it this way). E.g. say you have: From: foo@xxxxxxxxxx Subject: [PATCH] Fix foo For DMARC policies to properly work, this message would need to have a DKIM signature from redhat.com, so we'd need to have access to Red Hat's private keys. If we don't use DKIM signatures, then the recipient SMTP gateways may mark the message as spam (and they would be right, since we are pretending to be foo@xxxxxxxxxx, i.e. acting just like phishers). The only way for this to work is to do the From / X-Original-From / Follow-up-to / Reply-To header dance. Git does support this very well, and most email clients do the right thing when encountering this situation, but it's not going to have the exact same visual flow as patches sent directly via SMTP. However, we will also write these messages to a public-inbox repository before making the From: substitutions, so if someone retrieves these patches with b4 or lei, as opposed to receiving them via their SMTP mailbox, they should be able to get proper From: in the headers. -K
