Mailing list questions (DMARC, ARC, more?)
Dan Mahoney
dmahoney at isc.org
Fri Oct 7 01:21:23 UTC 2022
> 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>
More information about the bind-users
mailing list