Alessandro Vesely writes:
> On Sun 04/Sep/2022 13:38:39 +0200 Stephen J. Turnbull wrote:
> > Not sure what you mean by "sealing". Do you mean they're not
> > implementing the rest of the protocol?
>
> They add a complete ARC set. Actually, they add three ARC sets to each
> message, one at reception (with a full ARC-Authentication-Results), followed
> by
> intermediate and final sets.
? That's not how this works. You add (ARC-)Authentication-Results
immediately after the message is received from a remote, and the
ARC-Message-Signature and ARC-Seal immediately before transmitting it
to a remote. I guess if you do the full set including full
authentication at each stage, it doesn't harm the protocol, but it
does impose a fair amount of unnecessary work on each recipient.
> Thank you for that much needed clarification. I heard someone
> saying that the IETF was waiting to implement Mailman 3 to use ARC
> in mailing list...
That seems unlikely. Unless you're running a single-host system, it's
much preferable to do it on border MTAs, rather than in Mailman. I
suspect it's more that they plan to do a big revamp of infrastructure
including Mailman 3 and they would do it at that time.
> BTW, there is also a Perl implementation of ARC included in
> Mail::DKIM.
Thanks, I'll keep that in mind.
> Exactly. 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 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.
> 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.
> 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.
> 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
alignment. 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.
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!
> 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. The problem,
as always, is recipient domains that are unwilling to publish
consistent policies or respond to non-delivery issues.
_______________________________________________
Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
https://mail.python.org/mailman3/lists/mailman-developers.python.org/
Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
