Mailing list questions (DMARC, ARC, more?)

[Alessandro Vesely]

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 at 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-developers@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
--