Re: Review process improvements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux