On 09. 05. 23 16:35, Mark Brown wrote:
On Tue, May 09, 2023 at 11:54:18AM +0200, Jaroslav Kysela wrote:
The signature is correct in the encapsulated original e-mail. The b4 should
be improved in my opinion.
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/docs/dmarc-mitigations.html
happening with attachments. For example for:
168198605952.26.13645408104113633580@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx>
| Date: Thu Apr 20 11:20:43 2023 +0100
|
| ASoC: cs35l56: Remove duplicate mbox log messages
|
| Received: by alsa1.perex.cz (Postfix, from userid 50401)
| id 7A47CF80155; Thu, 20 Apr 2023 12:20:56 +0200 (CEST)
| X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on alsa1.perex.cz
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.
mutt also represents this incredibly badly, it just shows the
"attachment" as the body of the message with all the headers dumped in
like they're just plain text in the body of the mail - I wouldn't have
thought this was an attachment if it hadn't been mentioned in this
thread, none of the atacment UI shows. To reverse the mangling you have
to view attachments then save the root of the message to a folder. AIUI
mutt assumes that whatever the root of the message is is intended to be
the message body and does the best it can to display it as such.
I think that you can configure the tool to process this attachment in mutt.
Lore *does* show the body of the message as an attachment.
Yes, the original message is in the attachment - no information is lost.
As you see, the header and all signatures are correct in the attachment:
None of our tooling or processes understand this, they're working with
the top level message.
Is it possible to take steps to improve the reptuation of the ALSA
servers so this isn't needed, or could we migrate the lists elsewhere (I
It is not possible to talk with gmail administrators. I tried that several
times. The outgoing ALSA server is not on any spam list.
I know there is a lot of discussion going round about which hoops to
jump through to play nice with gmail, I don't know if there's any new
stuff that's come up there recently.
know we set up linux-sound@vger at one point with the idea of
migrating).
I guess that the vger servers have similar issues, because servers with
DMARC enabled on the ingress side can reject e-mails. It's related to e-mail
standards.
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.
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 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]).
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.
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...
Jaroslav
[1]
https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/handlers/docs/dmarc-mitigations.html
--
Jaroslav Kysela <perex@xxxxxxxx>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.
