> On Sep 27, 2022, at 02:50, Alessandro Vesely <ves...@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@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
signature.asc
Description: Message signed with OpenPGP
-- 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
