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 alignment.

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 particular list.

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 multiple levels.

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 
do it.

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 
regular subscriber?

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 
signer/ sealer.

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 -- mailman-developers@python.org
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

Reply via email to