On Wed, May 10, 2023 at 10:08 AM Mark Brown broonie@kernel.org wrote:

On Tue, May 09, 2023 at 08:03:39PM +0200, Jaroslav Kysela wrote:

...

On 09. 05. 23 16:35, Mark Brown wrote:

...

...

It's not b4 that's the issue here except in that it causes me to fetch copies of the message that went to the list instead of my inbox which didn't get mangled by the list. git am just does not understand what's

...

b4 can detect, if the e-mail is wrapped and use only the wrapped message. The wrapping is the correct semantics per mailman 3 not mangling (see [1]).

...

https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/do...

As Konstantin pointed out this isn't entirely practical, especially with the message ID rewriting breaking things. I suspect any mitigation here would have to be on the archive side with it trying to unpack and archive the enclosed message but that doesn't deal with all the issues.

...

...

if I try to apply it the top of the commit message looks like:

...

...

| commit 8f0e0ee514b189cf7b4e7fa09581e3f1d246fa09 (HEAD -> tmp) | Author: Richard Fitzgerald via Alsa-devel alsa-devel@alsa-project.org | Date: Thu Apr 20 11:20:43 2023 +0100

...

...

with all the headers dumped in there which is just completely mangled. Note the rewritten author.

...

You should apply the wrapped message not the capsule.

That's just not how any of the tooling works here, it is *possible* to unpack things but it's really fighting against the tooling.

...

...

mutt also represents this incredibly badly, it just shows the "attachment" as the body of the message with all the headers dumped in

...

I think that you can configure the tool to process this attachment in mutt.

I don't know off hand what that configuration would be, and in any case it'd have knock on effects with reordering messages in the mailboxes plus the overhead of having to open the mailbox to figure out if there's any mangled messages in there.

...

...

The issue I'm seeing here is the rewriting which I'm not aware of any other lists having turned on, even infradead ones which are also mailman based. Either they're just tolerating people having issues with gmail (which seems reasonable TBH) or they're jumping through some additional hoops to avoid issues.

...

I checked infradead and they're using mailman 2. Mailman 2 does not support DMARC mitigation.

AFAICT that "mitigation" is actively harmful...

...

...

I believe vger does sometimes manage some backchannel which probably helps it somewhat.

...

Using a non-standard mechanism is not a big win.

...

DMARC is a internet standard - see RFC7489, RFC8616. It means that the mailing lists cannot send e-mails with From from other domains which have restricted policies set by *their* administrators. So basically, all mail

I'm perfectly aware of what DMARC is, though I've not run a list server since it became a thing. As far as I'm aware the backchannel stuff for vger is more on the policy front (eg, with stuff like rate limit based mitigations) and not anything to do with relaxing any standards based security.

...

servers violates this if they keep the From header. Mailman 3 implemented several types of mitigations and the message wrap is the best one in my eyes. The mangling of the From header or reject e-mails from those senders is even worse (see [1]).

AFAICT the only other option is munging the From without enclosing the message in a wrapper? That's potentially marginally less harmful but it's still going to break things badly enough that I'm not sure it's a worthwhile improvement.

...

When I turn off the mitigation in mailman, my ALSA server will have bad reputation for gmail users soon in an unpredictable manner. I also saw that ATT incoming mail servers had similar issues. We can expect that the list of the ingress SMTP servers not accepting e-mails based on the DMARC policy will grow. It's something that we don't have under control.

It's not quite that broken.

...

If we don't find that it's time to move forward and accept this policy, I can turn off the mitigation, but in a cost that gmail (and soon maybe other) users will bomb me (they already did last years) that the ALSA mail server does not deliver e-mails for them. Are we a community on internet or not?

...

Ideally, we should start upgrade and fix our tools...

...

Let me just know, if you (and Takashi) insist to turn the mitigation off after this discussion. I'll do so...

I'd really like to see it turned off, in conjunction with the suggestions from Konstantin for passing DMARC. As far as I can tell the standards are not so broken as to be unusable, though any list is going to have some issues with gmail due to things like people incorrectly reporting spam (eg, when they want to unsubscribe or didn't realise what sort of list they were signing up for),

For the signatures thing IIRC even before this change to wrap things the list server was mangling incoming siguatures, they'd typically not verify if they came through the list - I never checked into it fully since it was just something I had to be aware of but that's been there since b4 had signature verification. I *think* ideally existing signatures should be preserved, or a new one added if there is none. That may well be more of the issue than anything else.

Last time this topic was raised (on infradead), I talked to someone from Gmail. The ask was that originating servers implement DKIM signing, and intermediate servers, i.e. mailing lists, not mangle the signed fields. The latter includes not adding footers, and not re-emitting headers, which may alter the amount of whitespace, based on some of my experiments.

ChenYu