Re: Mailing list questions (DMARC, ARC, more?)
> On Sep 27, 2022, at 02:50, Alessandro Vesely 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 >>> 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
Re: Mailing list questions (DMARC, ARC, more?)
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 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-develop...@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 -- -- 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
Re: Mailing list questions (DMARC, ARC, more?)
On Sat 24/Sep/2022 00:23:03 +0200 Matus UHLAR - fantomas wrote: another test done Thanks for reporting. This is slightly OT, as it concerns the list functioning rather than DNS. I hope it doesn't afflict... 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? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. On 25.08.22 18:10, Alessandro Vesely wrote: Please tell us. On Fri 02/Sep/2022 14:27:55 +0200 Matus UHLAR - fantomas wrote: so far, not ex - opendmarc only uses header that's inserted by openarc milter - openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org" On 04.09.22 12:56, Alessandro Vesely wrote: They produce an ARC set on each internal passage, all having d=isc.org. That's undoubtedly redundant, yet valid. I haven't studied the ARC standard, but this looks correct. However, I was repeatedly unable to make opendmarc to accept arc result: Authentication-Results: fantomas.fantomas.sk; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: fantomas.fantomas.sk; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=itqgpF3K; dkim-atps=neutral IMHO, it is correct to say dkim=fail, but DMARC should have been redeemed by ARC if trusted. Authentication-Results: [...] Authentication-Results: fantomas.fantomas.sk; arc=pass smtp.remote-ip=149.20.1.60 arc.chain="isc.org:isc.org:isc.org" That arc=pass doesn't say if it was trusted or not. As you say, trust doesn't seem to make any difference. Paradoxical. From: frank picabia Gmail has p=none. However, I tried to send to this list an unauthenticated message from a domain with p=reject and spf-all. It was rejected by: 550 5.7.1 Blocked by SpamAssassin That looks like accumulating a score, not a formal rejection after policy requirements. - opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put isc.org:isc.org:isc.org (will try) I have tried both, no result. There is a school of thought according to which receivers should blindly trust ARC headers, except spam or known bad actors. When enabled, arc=pass should override dmarc=fail p=reject. We never get this, because bind-users rewrite From: if author's domain has p=reject. This should not be a problem, since we should trust isc.org servers when they provide wortking ARC-Seal: Yes, but we still receive munged From:'s. The idea was that with ARC they could be avoided. The way to do it is the 1st method in my draft[*], but I cannot find a list willing to experiment. Trusting isc.org should suffice. Logically, when multiple domains applied message modifications, a receiver has to trust all of them. Not necessarily any disposition of them. do you mean, I should trust all domains in ARC-Seal, listed in Authentication-Results header? RFC8617 talks about "sealing domain" of a given ARC set, surmising that the d= tag should have the same value in ARC-Seal and ARC-Message-Signature. - openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always. - arc for bind-users seems to fail when mailman rewrites From: header (but DKIM is fine in this case) I tried the Perl ARC verifier included in Mail::DKIM. On your message it outputs: ale@pcale:~/tmp$ arc-verify.pl < arc1.eml this is not in debian distribution. when tried it, it shows correct: uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arc1.eml RESULT: pass uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arctest RESULT: pass however, I was unable to make my dkim/dmarc PASS on a mail from this list that was: - arc-signed by ISC - DKIM fail (not munged) The header is ok, but the body has an added footer. Using zdkimfilter (3rd method in that draft[*]) I get the following on your message: INFO: zfilter: zdkimfilter[13097]:ip=NULL: domain isc.org whitelisted by list.dnswl.org DEBUG: zfilter: zdkimfilter[13097]:ip=NULL: retrieved fantomas.sk->fantomas: rsa-sha256, 2048 bits INFO: zfilter: zdkimfilter[13097]:ip=NULL: enabling body parse (sigs pass: 1, could pass: 0) INFO: zfilter: zdkimfilter[13097]:ip=NULL: enabling retry (badsig, bh ok: 0; badsig, bh bad: 0; pass, bh bad: 1) INFO: zfilter: zdkimfilter[13097]:ip=NULL: transformation enabled for "Matus UHLAR - fantomas " retry body only INFO: zfilter: zdkimfilter[13097]:ip=NULL: transform message from base64 back to identity with footer. INFO: zfilter: zdkimfilter[13097]:ip=NULL: sig failure d=fantomas.sk, s=fantomas: body hash mismatch INFO: zfilter:
Re: Mailing list questions (DMARC, ARC, more?)
> On Aug 23, 2022, at 07:39, G.W. Haywood via bind-users > 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 + > 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
Re: Mailing list questions (DMARC, ARC, more?)
another test done 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? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. On 25.08.22 18:10, Alessandro Vesely wrote: Please tell us. On Fri 02/Sep/2022 14:27:55 +0200 Matus UHLAR - fantomas wrote: so far, not ex - opendmarc only uses header that's inserted by openarc milter - openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org" On 04.09.22 12:56, Alessandro Vesely wrote: They produce an ARC set on each internal passage, all having d=isc.org. That's undoubtedly redundant, yet valid. I haven't studied the ARC standard, but this looks correct. However, I was repeatedly unable to make opendmarc to accept arc result: Authentication-Results: fantomas.fantomas.sk; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: fantomas.fantomas.sk; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20210112 header.b=itqgpF3K; dkim-atps=neutral Authentication-Results: fantomas.fantomas.sk; spf=pass (sender SPF authorized) smtp.mailfrom=lists.isc.org (client-ip=149.20.1.60; helo=lists.isc.org; envelope-from=bind-users-bounces+uhlar=fantomas...@lists.isc.org; receiver=) Authentication-Results: fantomas.fantomas.sk; arc=pass smtp.remote-ip=149.20.1.60 arc.chain="isc.org:isc.org:isc.org" From: frank picabia - opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put isc.org:isc.org:isc.org (will try) I have tried both, no result. When enabled, arc=pass should override dmarc=fail p=reject. We never get this, because bind-users rewrite From: if author's domain has p=reject. This should not be a problem, since we should trust isc.org servers when they provide wortking ARC-Seal: Trusting isc.org should suffice. Logically, when multiple domains applied message modifications, a receiver has to trust all of them. Not necessarily any disposition of them. do you mean, I should trust all domains in ARC-Seal, listed in Authentication-Results header? - openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always. - arc for bind-users seems to fail when mailman rewrites From: header (but DKIM is fine in this case) I tried the Perl ARC verifier included in Mail::DKIM. On your message it outputs: ale@pcale:~/tmp$ arc-verify.pl < arc1.eml this is not in debian distribution. when tried it, it shows correct: uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arc1.eml RESULT: pass uhlar@fantomas% perl ./scripts/arcverify.pl < /tmp/arctest RESULT: pass however, I was unable to make my dkim/dmarc PASS on a mail from this list that was: - arc-signed by ISC - DKIM fail (not munged) - not from ISC ARC-Seal: v=3 pass ARC-Message-Signature: v=3 pass ARC-Seal: v=2 pass ARC-Message-Signature: v=2 fail (body has been altered) ARC-Seal: v=1 pass ARC-Message-Signature: v=1 fail (body has been altered) (arc-verify.pl is a copy of the module's synopsis[*].) Then I tried it on Ged's message, earlier in this thread, and got: ale@pcale:~/tmp$ arc-verify.pl < arc2.eml ARC-Seal: v=3 pass ARC-Message-Signature: v=3 pass ARC-Seal: v=2 pass ARC-Message-Signature: v=2 fail (message has been altered) ARC-Seal: v=1 pass ARC-Message-Signature: v=1 fail (message has been altered) So both messages seem to be valid, if you trust isc.org. The failure in the signature reflects that only the body was altered in your message, while also the header was altered in Ged's one. As ARC allows mediators to modify messages, only the last signature is significant. Mailman should know about your setting in order to skip From: munging in the copies sent to you. Currently, the copies sent to pipermail for archiving seem to be non-munged, so this functionality exists. do you mean I can turn off From: munging in mail sent to me? Mailman options[†] don't include something like *From munging*: Set this option to /Disabled/ to receive messages with the original From: line intact. Keep in mind that disabling this option will fail DMARC, so keep it enabled unless your MTA either doesn't check DMARC or accepts ARC overrides. It doesn't seem difficult to implement. It requires trusting the users, though. I'm going to ask Mailman developers. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I'm not interested in your website anymore. If
Re: Mailing list questions (DMARC, ARC, more?)
On Sun 04/Sep/2022 14:17:25 +0200 Benny Pedersen wrote: ARC-Authentication-Results: i=1; mx.pao1.isc.org; dmarc=pass (p=none dis=none) header.from=tana.it; spf=pass smtp.mailfrom=tana.it; dkim=permerror (0-bit key) header.d=tana.it header.i=@tana.it That stanza is faulty. The key at epsilon._domainkey.tana.it is 256 bits, like all ed25519 keys, not 0. Presumably ISC's DKIM filter doesn't support RFC8463. header.b=j8VJHYFh; dkim=pass (1152-bit key; unprotected) header.d=tana.it header.i=@tana.it header.b=DBspF3JP The second signature, rsa, succeeds. However, why unprotected? Presumably the library used by ISC's DKIM filter doesn't support DNSSEC. you have a invalid dkim signing, fix that Nothing to fix on my side. note you on top of that dkim double sign one is working, one is failing That's why I put two. Best Ale -- -- 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
Re: Mailing list questions (DMARC, ARC, more?)
Alessandro Vesely skrev den 2022-09-04 12:56: Mailman options[†] don't include something like *From munging*: Set this option to /Disabled/ to receive messages with the original From: line intact. Keep in mind that disabling this option will fail DMARC, so keep it enabled unless your MTA either doesn't check DMARC or accepts ARC overrides. It doesn't seem difficult to implement. It requires trusting the users, though. I'm going to ask Mailman developers. drop that ARC-Authentication-Results: i=1; mx.pao1.isc.org; dmarc=pass (p=none dis=none) header.from=tana.it; spf=pass smtp.mailfrom=tana.it; dkim=permerror (0-bit key) header.d=tana.it header.i=@tana.it header.b=j8VJHYFh; dkim=pass (1152-bit key; unprotected) header.d=tana.it header.i=@tana.it header.b=DBspF3JP you have a invalid dkim signing, fix that note you on top of that dkim double sign one is working, one is failing -- 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
Re: Mailing list questions (DMARC, ARC, more?)
On Fri 02/Sep/2022 14:27:55 +0200 Matus UHLAR - fantomas wrote: On 25.08.22 18:10, 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? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. Please tell us. so far, not ex - opendmarc only uses header that's inserted by openarc milter - openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org" They produce an ARC set on each internal passage, all having d=isc.org. That's undoubtedly redundant, yet valid. - opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put isc.org:isc.org:isc.org (will try) When enabled, arc=pass should override dmarc=fail p=reject. We never get this, because bind-users rewrite From: if author's domain has p=reject. Trusting isc.org should suffice. Logically, when multiple domains applied message modifications, a receiver has to trust all of them. Not necessarily any disposition of them. - openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always. - arc for bind-users seems to fail when mailman rewrites From: header (but DKIM is fine in this case) I tried the Perl ARC verifier included in Mail::DKIM. On your message it outputs: ale@pcale:~/tmp$ arc-verify.pl < arc1.eml ARC-Seal: v=3 pass ARC-Message-Signature: v=3 pass ARC-Seal: v=2 pass ARC-Message-Signature: v=2 fail (body has been altered) ARC-Seal: v=1 pass ARC-Message-Signature: v=1 fail (body has been altered) (arc-verify.pl is a copy of the module's synopsis[*].) Then I tried it on Ged's message, earlier in this thread, and got: ale@pcale:~/tmp$ arc-verify.pl < arc2.eml ARC-Seal: v=3 pass ARC-Message-Signature: v=3 pass ARC-Seal: v=2 pass ARC-Message-Signature: v=2 fail (message has been altered) ARC-Seal: v=1 pass ARC-Message-Signature: v=1 fail (message has been altered) So both messages seem to be valid, if you trust isc.org. The failure in the signature reflects that only the body was altered in your message, while also the header was altered in Ged's one. As ARC allows mediators to modify messages, only the last signature is significant. Mailman should know about your setting in order to skip From: munging in the copies sent to you. Currently, the copies sent to pipermail for archiving seem to be non-munged, so this functionality exists. do you mean I can turn off From: munging in mail sent to me? Mailman options[†] don't include something like *From munging*: Set this option to /Disabled/ to receive messages with the original From: line intact. Keep in mind that disabling this option will fail DMARC, so keep it enabled unless your MTA either doesn't check DMARC or accepts ARC overrides. It doesn't seem difficult to implement. It requires trusting the users, though. I'm going to ask Mailman developers. Best Ale -- [*] https://metacpan.org/pod/Mail::DKIM::ARC::Verifier [†] https://lists.isc.org/mailman/options/bind-users -- 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
Re: Mailing list questions (DMARC, ARC, more?)
On 25.08.22 18:10, Alessandro Vesely wrote: The lack of interest by others proves that From: munging is not so much of a nuisance as they say... On Mon 29/Aug/2022 12:09:10 +0200 Matus UHLAR - fantomas wrote: This will come sooner or later, however: earlier this year I've done small dmarc research for our client: - microsoft software (on-premise exchange and 365) does not DKIM-sign DSN e-mail (delivery and non-delivery notifications) although those have sending domain in From: (I guess domain is added after sig generated) On 01.09.22 12:07, Alessandro Vesely wrote: So do I, relying on SPF for DNSs. if DSN contains domain in From: address, they can be signed as well. microsoft messed this up. - only a few % of domains has other DMARC policy than none - mailman 2 (used here) only munges From: when domain DMARC policy for the sending domain is other than none. Which is insecure. yes, but due to the above, since DSNs aren't DKIM-signed, they could be easily dropped, I assume either nobody tried to set DMARC policy to other than none or they had problems. While I keep p=none, anyone can post a spoof using my email address as From: and pretend to be me. It never happens, but some people believe it /cannot/ happen. 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? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. Please tell us. so far, not ex - opendmarc only uses header that's inserted by openarc milter - openarc milter for bind-users inserts arc.chain="isc.org:isc.org:isc.org" - opendmarc seems to ignore "DomainWhitelist isc.org" perhaps I need to put isc.org:isc.org:isc.org (will try) - openarc (I have installed beta from debian experimental) seems to insert Authentication-Result: header when no ARC seal is present, though not always. - arc for bind-users seems to fail when mailman rewrites From: header (but DKIM is fine in this case) Mailman should know about your setting in order to skip From: munging in the copies sent to you. Currently, the copies sent to pipermail for archiving seem to be non-munged, so this functionality exists. do you mean I can turn off From: munging in mail sent to me? -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. I wonder how much deeper the ocean would be without sponges. -- 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
Re: Mailing list questions (DMARC, ARC, more?)
On Mon 29/Aug/2022 12:09:10 +0200 Matus UHLAR - fantomas wrote: On 25.08.22 18:10, Alessandro Vesely wrote: The lack of interest by others proves that From: munging is not so much of a nuisance as they say... This will come sooner or later, however: earlier this year I've done small dmarc research for our client: - microsoft software (on-premise exchange and 365) does not DKIM-sign DSN e-mail (delivery and non-delivery notifications) although those have sending domain in From: (I guess domain is added after sig generated) So do I, relying on SPF for DNSs. - only a few % of domains has other DMARC policy than none - mailman 2 (used here) only munges From: when domain DMARC policy for the sending domain is other than none. Which is insecure. While I keep p=none, anyone can post a spoof using my email address as From: and pretend to be me. It never happens, but some people believe it /cannot/ happen. 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? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. Please tell us. Mailman should know about your setting in order to skip From: munging in the copies sent to you. Currently, the copies sent to pipermail for archiving seem to be non-munged, so this functionality exists. Best Ale -- -- 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
Re: Mailing list questions (DMARC, ARC, more?)
On 25.08.22 18:10, Alessandro Vesely wrote: Thanks Ged for all the feedback. The lack of interest by others proves that From: munging is not so much of a nuisance as they say... This will come sooner or later, however: earlier this year I've done small dmarc research for our client: - microsoft software (on-premise exchange and 365) does not DKIM-sign DSN e-mail (delivery and non-delivery notifications) although those have sending domain in From: (I guess domain is added after sig generated) - only a few % of domains has other DMARC policy than none - mailman 2 (used here) only munges From: when domain DMARC policy for the sending domain is other than none. 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? I guess most of recipients use predefined configurations, e.g. no whitelisting. out of curiousity, I set my opendmarc.conf: DomainWhitelist lists.isc.org so we'll see next time mail comes. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. One OS to rule them all, One OS to find them, One OS to bring them all and into darkness bind them -- 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
Re: Mailing list questions (DMARC, ARC, more?)
Thanks Ged for all the feedback. The lack of interest by others proves that From: munging is not so much of a nuisance as they say... Best Ale On Tue 23/Aug/2022 16:39:33 +0200 Bind Users 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 + 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. :) PS: Please don't be offended if mail sent directly to me is rejected. We can get around it. PPS: [Page 18] s/Content-Tyep:/Content-Type:/; -- 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
Re: Mailing list questions (DMARC, ARC, more?)
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 + 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. :) PS: Please don't be offended if mail sent directly to me is rejected. We can get around it. PPS: [Page 18] s/Content-Tyep:/Content-Type:/; -- 73, Ged. -- 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
