Mailing list questions (DMARC, ARC, more?)

[Dan Mahoney]

> On Sep 27, 2022, at 02:50, Alessandro Vesely <vesely at tana.it> wrote:
> 
> 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.

Yes, and we're arc-sealing in the event that it catches on, but right now nobody seems to be paying attention to it.  We're a "there's an RFC for it, we should do it" kind of company, so...why not.  As a list admin, I'm most in favor of deliverability.

>> [...]
>> DKIM Validation/Arc Sealing:
>> * Everything gets validated at our MXes.
> 
> 
> However, the list doesn't seem to apply DMARC policies on entry.

Yes, because we're still ISC, and we still have a bunch of users on a bunch of non-isc mailing lists, which may themselves be breaking DMARC for those administrative domains.  Chicken, meet egg.

OpenDMARC's failure rejection policy is not configurable per receiving domain.

> Can internal handoff modify the message?  (Except Mailman, I mean.)

It can.  For example, a canonical rewrite map can modify the original to: header.

> 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

I'm loathe to do more mailman tweaking, but I'll have a read.  No promises.  The problem is that some places might see things that are unmunged and don't respect arc yet and say "gee, lists.isc.org is sending us a lot of spam, let's block them."  Ask me how I know.

Best,

-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/20221006/771b8374/attachment.sig>