On Tue 06/Sep/2022 06:41:36 +0200 Stephen J. Turnbull wrote:
Alessandro Vesely writes:
On Sun 04/Sep/2022 13:38:39 +0200 Stephen J. Turnbull wrote:
I asked bind-users if anyone verifying ARC saw any difference after
trusting isc.org. Besides adding ARC sets, bind-users do From: munging,
obviously. Nobody saw any difference.>
As far as I know ARC adds nothing if you're also doing From munging.
The point of ARC is entirely to get rid of From munging. Once you've
munged From, your DKIM will be valid and you have DMARC from
The tale goes that large mailbox providers want ARC as a tool to filter mail
streams from lists that don't do a good filtering themselves. ARC, they say,
allows to attribute reputation correctly. However, I don't think they can tell
who a message is from, after it has been munged. In that respect, From:
munging hampers ARC.
The point is how does Mailman know whether a recipient's MX trusts this
It doesn't. Recipients can do any damned thing they want. In the
case of AT&T and Verizon, pretty much everything they do is damned.
They frequently block all traffic from well-behaved lists because
there's a spammer in the same netblock, or just randomly.
Heck, that sounds similar to a blog I just read:
And what does it do when it knows. Some people babble something
about DNS records, which looks difficult. Another possibility
could be an SMTP extension, difficult to implement as it involves
I really don't see the bad actors in this space (by which I mean the
ISP-based freemail providers) doing either, since they don't even send
"we hate you spammer!" DSNs, they just black hole your list traffic
and any attempt to complain about it. If services sent honest DSNs,
we could discount bogus 550s and not count them as bounces.
A MLM would continue From: munging unless a receiver is able to tell it to not
An easy way would be to ask the subscriber whether to do From:
munging or not. Then, a user can disable From: munging for the
messages destined to her. That's easy for those who run their own
MTA. People using Gmail, say, would have to figure out, presumably
by trial and error.
I'm dubious. People are going to get their subscriptions disabled by
experimenting. I don't know how many people still want
non-personalized lists, but implementing that would require a bit of
effort since two messages would need to be prepared depending on
whether don't-munge-for-me was set.
I see that archived messages are not munged. How come? Isn't the archive a
At worst, one could set up two lists, fed by the same stream, one with munging
enabled and the other not, letting users subscribe to the one they prefer.
If such an option is not given, a mailing list could add the
Author: header field defined by RFC9057. Receivers could restore
From: after DMARC filtering.
This can't work. DMARC v2 will quickly be forced to check Author
A list can set the Author: header field by copying From:. In the rare case when Author:
is already set and differs from From:, it has to be checked. I guess that case is so
rare that the list can handle it by sending such messages to the moderator queue.
Alternatively, apply DMARC to the Author: domain. That's the "simple"
de-munging method in my draft:
From the RFC:
In that regard, it would be reasonable for an MUA that would
normally organize, filter, or display information based on the
From: field to give the Author: header field preference.
MUAs won't notice Author: fields any time soon.
Translated into Scum-of-the-Earth-Spammer:
You can use this header to send "referred by someone in victim's
contact list" (that you stole from Yahoo) spam and it will bypass
DMARC v1 because you can use an aligned From. All-Hail-Author!
They're doing that with From:, and it works fine. It is very hard for MUAs to
tell spoofed From:'s, and munging doesn't help. Then, some people hold that
even writing THIS IS PHISHING loud and clear won't prevent users from opening
and clicking that link. Darwin will tell...
That assuming that someone is willing to do something to avoid
munged From:'s, which I'm beginning to doubt.
If ISPs cared at all about their customers, they'd implement ARC and
be fine. It completely solves the problem by putting it on mailing
lists and other mediators to filter spam before sealing.
Implementing and deploying ARC is not enough, you also need to trust the ARC
ARC won't be effective until it has been deployed at more than 60% of SMTP
servers and that's not a problem. :-)
Mailman-Developers mailing list -- email@example.com
To unsubscribe send an email to mailman-developers-le...@python.org
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9