Hi Steve!
On Sun 04/Sep/2022 13:38:39 +0200 Stephen J. Turnbull wrote:
Alessandro Vesely writes:
There is a thread about ARC sealing in bind-users[*].
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.
They're applying ARC signatures, although they run Mailman 2.
It doesn't seem difficult to implement.
It's not. But
1. It's a bad idea to do it in Mailman.
2. It was implemented in Mailman 3 three or four years ago as a proof
of concept during the development of ARC.
3. There is a milter available for Postfix and Sendmail from the
Trusted Domain Project https://github.com/trusteddomainproject/OpenARC
as is the basic implementation which I presume is adaptable to
Exim, qmail, and other MTAs.
This is the preferred approach, as matter of conformance because
it should be implemented by the edge MTA(s), and as a practical
matter because Mailman *can't* do SPF since it is never an edge
MTA. There is also a pure Python implementation on PyPI, I
believe (this is the basis for the Mailman 3 plugin, or maybe it
was dkimpy).
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...
BTW, there is also a Perl implementation of ARC included in Mail::DKIM.
It requires trusting the users, though.
I don't think so, not any more than any other sign-and-send protocol.
I think you misunderstood my question here.
What it requires is implementation by recipient domains who trust your
host, because if they don't it's 2014 all over again for your
subscribers if you have any DMARC p=reject posters.
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.
The point is how does Mailman know whether a recipient's MX trusts this
particular list. 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.
An easy way would be to ask the subscriber whether to do From: munging or not.
I repeat a possible wording for that option, which would be enabled by default:
*From munging*:
Set this option to /Disabled/ to receive messages with the original From:
line intact. Keep in mind that disabling this option will fail DMARC, so
keep it enabled unless your MX either doesn't check DMARC or accepts
overrides trusting our ARC sets.
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.
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.
That assuming that someone is willing to do something to avoid munged From:'s,
which I'm beginning to doubt.
Best
Ale
--
_______________________________________________
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
