Mailing list questions (DMARC, ARC, more?)

[Dan Mahoney]

> On Aug 23, 2022, at 07:39, G.W. Haywood via bind-users <bind-users at lists.isc.org> wrote:
> 
> Hi there,
> 
> 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?
> 
> When it comes to email, I don't trust *anything*. :)
> 
> Generally speaking I think these technological fixes are very much
> over-engineered as compared with, say, inspecting the headers. :/
> 
> We check the ARC seal and I would be alerted to a failure.  That's all.
> There have been two failures since ISC implemented ARC - the first two
> ARC-signed messages we received, on 25th April - all after that passed:
> 
> Date: Mon, 22 Aug 2022 12:00:00 +0000
> X-ARCverify: pass (All ARC Seals and the most recent ARC Signature passed verification)
> 
> There were a few DKIM failures in the early days too, I don't remember
> if I investigated any of the failures.
> 
>> In that case, do they get non-munged messages?
> 
> Nope.  I'm on the digest list anyway.
> 
>> 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.  I've experienced no issues on the
> BIND list to which I've thought ARC might be relevant.  Unfortunately
> that's by no means the case for some of the other lists to which I am
> (or have in the past been) subscribed.
> 
>> 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 trying to elaborate a draft[*] to formalize such method.  Would this list be interested in experimenting that?
> 
> 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).  I apologize for this post in the top of the thread, but I've been traveling most of the summer and wanted to delurk and offer to answer questions directly.

I'm the person who implemented the arc-sealing on bind-users (and on everything inside isc.org many months ago), and I should demystify my logic here, with some use-cases that are special to ISC.

* lists.isc.org is a pretty old list.  bind-users predates the existence of gmail.  We've in the past hit delivery issues to gmail (often over v6 while v4 works, it's resulted in us having to block v6 delivery to gmail) and gmail's auth requirements are pretty strict.

* 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 :)

* 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).

* There is not feature parity between mailman 2.x and mailman 3.x, and my personal opinion is that it's not well-done.  I'm not the only person with this opinion.

* We also run a public-facing github server, we've also got a few servers in our netblocks that are outside our control (often, personal employee vms, but occasionally, research projects), we have a lot of peering email, etc, and we're largely self-hosted.   Deliverability is important to us.

* I have some responsibilities with the Trusted Domain Project.  Recent releases to opendmarc, and triaging of some of the bugs there are a side-project that ISC is happy to loan me to.  I'm not a BIND developer, and C is not my strong point -- I'm more of a sysadmin, but considering nobody is yet rejecting messages on arc-seals, setting up arc-sealing for a mailing list with no real SLA to speak of is not a bad thing.  So yes, some of this is attempting to have ISC eat the trusted domain project's own "dog food".

Here's the workflow (though it's, once again, woefully off-topic for bind-users):

DKIM Validation/Arc Sealing:

* Everything gets validated at our MXes.  It would have to be, because only the MX has access to the IP address info required to check SPF.  From there, the MX applies an arc-seal that should validate wherever in the world the mail goes, either on to our internal mail servers, or forwarded out to gmail from one of our users.  We don't validate our own internal arc-seals, because we trust our own internal networks.  (In openarc parlance, we're using mode "sv" but InternalHosts causes the validation to not be applied)

DKIM:

* We run internal DKIM signing on the boxes where the mail originates.  Most of the time, the "Selector" is a modification of the hostname for the signing machine.  I wanted something easy to read and look for in the headers, so in most cases rather than a GUID I used a different scheme that's easy to grep for.  Of lists.isc.org generates one of its dumb mailing list reminders, it will have a signature from *that box*.  It knows to only generate signatures for isc.org and lists.isc.org.  Our internal shell machine (where some of our users run "pine"), same deal.  Our main mail servers, same deal.  Our RT instances?  Same.  We *also* sign on our outbound MXes, in case there's a system that cannot do its own internal signatures (think like: a NAS that sends mails.  You're not going to install opendkim and configure signing on your NAS).

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.

* There will be at least two "received" headers in a mailing list message on lists.isc.org, one *before* it's fed to mailman, and another when mailman hands off to the MX after doing its own internal dance.  Both get arc seals that say, in effect "all other seals up to this point, in this ADMD were validated, or were added by a machine we trust"

* If, as above, lists.isc.org generates a subscription reminder, it can DKIM sign that.  It can also DKIM sign any mail that an ISC staffer sends through.  What it cannot do is generate a DKIM signature for any other mail sent through it.  The *only* assertion a listserv can do after modifying the body and headers is attach an arc seal that says, in effect, 'we looked at this every step of the way, and it looked good to us. '

===

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.

If people want to ask me questions directly, I'm here.  And on mailop.

-Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220923/14a63a3f/attachment-0001.sig>