Thread (17 messages) 17 messages, 12 authors, 2022-01-09

Re: Review process improvements

flat view

From: Konstantin Ryabitsev <hidden>
Date: 2021-12-22 15:45:39
Also in: workflows

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: <redacted>
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@redhat.com, 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help