Hi Dan,
On Sat 24/Sep/2022 01:10:12 +0200 Dan Mahoney wrote:
On Aug 23, 2022, at 07:39, G.W. Haywood via bind-users
<bind-users@lists.isc.org> wrote:
On Tue, 23 Aug 2022, Alessandro Vesely wrote:
I see the list operates both From: munging and ARC sealing. While I'm clear
about the former, I'm curious about how ARC works:
Do any subscribers trust the seal by isc.org?
We check the ARC seal and I would be alerted to a failure. That's all.
Are there other advantages that ARC brings about?
It's a comfort to know that it's all working as designed, but I can't
get excited about munged addresses.
Otherwise, RFC9057 introduced the Author: header field. Using it to save the
original From: would allow trusting receivers to de-munge the message at a
later stage.
I'm happy to use cut'n'paste for replies, but I can offer to help you
with your testing. The milters here can do more or less anything. :)
Hey there GW (and others).
[...]
* We're trying not to deal with the blowback that would occur if we *just
decided to* one day start munging everyone's mail addresses. Lots of people
would start posting about not-bind-things. Like this :)
I apologize again for wasting bandwidth on non-DNS issues.
While munging everyone would look more coherent, I propose to stop munging
everyone, at least as an option for those recipient who accept broken DMARC.
* Mailman 2.x (which we run) has some sender-munging features that have been
necessary in the past to ensure delivery, but they haven't been the only
problem. We're presently only doing those on domains with p=reject (or
p=quarantine, which is rare).
ARC was designed to avoid this.
[...]
DKIM Validation/Arc Sealing:
* Everything gets validated at our MXes.
However, the list doesn't seem to apply DMARC policies on entry.
It would have to be, because only the MX has access to the IP address info
required to check SPF.
That's the right way to do it. Let me quote Mailman developers about doing ARC
sealing:
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).
https://mail.python.org/archives/list/mailman-develop...@python.org/message/RLSANJHTFTYQPAQQIBAOK3VDM3U4E5EU/
[...]
ARC on lists:
* The logic I applied is: What if a message comes in from sender X, is modified
through listserv Y, and is sent out to subscribers Z[n]. We want to assert
that we received the message with headers A, B, and C, and validated them, and
even if they'd been re-written (as often happens on mailing lists) that they
were valid at each point in the step. Thus, yes, you need two arc-seals, one
in each point where there's a handoff and potential message modification.
Can internal handoff modify the message? (Except Mailman, I mean.)
[...]
To the best of my knowledge, we're the only folks doing this -- mailman 3 is
supposed to implement its own arc-sealing, but 2.x won't ever. Mailman 2.x is
largely EOL (but receiving security fixes -- XKCD 2347 applies) but there's
movements to port it to work on a more modern python.
As pointed out above, ARC should not be done by Mailman in any case.
For the record, dnswl-users also do ARC sealing. In 2016 they stopped
modifying messages, and hence they don't do From: munging.
If people want to ask me questions directly, I'm here. And on mailop.
What I want to ask is to experiment sending messages without From: munging.
That would entail setting up a twin mailing list, configured to not do From:
munging. Users would subscribe to the latter if their MX accepts broken DMARC,
possibly because of ARC, or some other authentication, or even no
authentication check at all; presumably users who can get their hands on their
MTA, not Gmail accounts. The idea is outlined as the first one of three
methods to get rid of From: munging, here:
https://datatracker.ietf.org/doc/html/draft-vesely-dmarc-mlm-transform
Best
Ale
--
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
