Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
Can you find a commercial product that can configure a rule which says, "Don't worry about DMARC if Mail from = bounceaddtess@listdomain and the MailFrom address produces SPF PASS"? Simple enough rule. If vendors understood what we want them to understand, they would allow creation of multipe-attribute rules like this, combining authentication results and identifier values, to provide local authentication overrides. But they don't, or at least I have not found one after diligently searching. On the other hand, finding products that block unconditionally on FAIL is pretty easy. We need to find words in our document that begin to fix this, to obtain the products and evaluator behavior that we both want and their users need. Doug On Wed, Jul 19, 2023, 8:07 PM Dotzero wrote: > > > On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Perhaps you can clarify what you think DMARC is. >> >> Apparently a significant number of evaluators think that "DMARC Fail with >> p=reject always means unwanted mail". Or to use Michael Hammer's >> language, "DMARC Fail with p=reject means the domain owner wants it >> rejected so I will reject it."These are exactly the attitudes that >> cause us so much trouble because (a) DMARC Fail with p=reject does not mean >> that rejection is always the correct response, and (b) DMARC Fail with >> p=none is an important piece of information. >> > > You are misrepresenting my position by ignoring local policy. A DMARC > policy of quarantine or reject is a request by the domain owner or > administrator. While consideration of a sending domain's request should be > given consideration, a receiving domain is free to do as it wishes. A > receiving domain may choose not to implement DMARC validation at all. A > sending domain may believe that the risk of some legitimate emails being > rejected or quarantined is an acceptable tradeoff in order to protect > itself and users/recipients. You appear to have a problem with these > choices being made by both the sending domain and the receiving domain. Why > do you presume to know better than they as to what they should do? > Certainly, if I publish a policy of p=reject and a receiver allows an email > that should have been rejected to reach their user/customer and that person > contacts me because that message caused them a problem, I'm going to tell > them they need to speak with their mail administrator, mailbox provider, > etc. I've done that in the past and I'll do it in the future. What others > choose to do is their choice. While I may have an opinion, I recognize that > it is their choice. > >> >> We have only two ways to block unwanted messages: Identify unwanted and >> malicious messages based on the sender, or based on the content. >> Impersonation interferes with the sender reputation assessment, so we know >> that attackers have an incentive to impersonate. Sender Authentication >> provides information about messages that MIGHT be impersonations >> because they are not authenticated. Fortunately, most messages can be >> authenticated. >> > > You are again misrepresenting what DMARC is and does. It is NOT a guessing > game about whether a recipient might want a given email. It is a simple > pass/fail that should be automated before a message ever (potentially) gets > to a recipient. It may be as simple as the message took an unintended or > unexpected path which potentially creates risks from the perspective of the > sending domain. DMARC knows nothing about whether email is wanted or > unwanted on the receiving side of the mailstream. It knows nothing about > reputation. DMARC is not a substitute for other filtering or reputation > systems. DMARC is not a Swiss Army knife, was never intended to be one, nor > is it appropriate to pretend you can contort it into one. > > I absolutely agree with John regarding his comments and agree with his > sentiment of " I am so tired of people imagining that DMARC is more than it > is." > > Michael Hammer > > >> >> Doug >> >> >> >> >> On Wed, Jul 19, 2023 at 5:32 PM John Levine wrote: >> >>> It appears that Barry Leiba said: >>> >> - An attacker sends 10 messages that maliciously impersonates a >>> >> big bank. With help from DMARC p=reject, the evaluator blocks >>> >> them all. The attacker follows up with 10 messages that >>> >> maliciously impersonate a major university. The stupid >>> >> evaluator says, "p=none means no problem here". The message is >>> >> accepted and the user is harmed because the evaluator learned >>> >> nothing from blocking the successful attack. >>> > >>> >This is a useful point, and I think we should do something with it. >>> >>> Sorry, but I completely disagree. >>> >>> The interesting filtering data is that a bunch of unauthenticated mail >>> arrived from some source. As we have learned over and over, someone's >>> DMARC policy tells you nothing about the threat level or whether the >>> failure is
Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
I don't take DMARC as a certain result to be used in isolation, but clearly a quorum evaluators do, and hence the mailing list problem that has caused such consternation. If we want to diminish their numbers, we have to communicate very differently than RFC 7489. My problem with your favorite line is that the domain owner's preference is of no interest to my filtering decision, but the DMARC result is. Doug On Wed, Jul 19, 2023, 8:07 PM Dotzero wrote: > > > On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> Perhaps you can clarify what you think DMARC is. >> >> Apparently a significant number of evaluators think that "DMARC Fail with >> p=reject always means unwanted mail". Or to use Michael Hammer's >> language, "DMARC Fail with p=reject means the domain owner wants it >> rejected so I will reject it."These are exactly the attitudes that >> cause us so much trouble because (a) DMARC Fail with p=reject does not mean >> that rejection is always the correct response, and (b) DMARC Fail with >> p=none is an important piece of information. >> > > You are misrepresenting my position by ignoring local policy. A DMARC > policy of quarantine or reject is a request by the domain owner or > administrator. While consideration of a sending domain's request should be > given consideration, a receiving domain is free to do as it wishes. A > receiving domain may choose not to implement DMARC validation at all. A > sending domain may believe that the risk of some legitimate emails being > rejected or quarantined is an acceptable tradeoff in order to protect > itself and users/recipients. You appear to have a problem with these > choices being made by both the sending domain and the receiving domain. Why > do you presume to know better than they as to what they should do? > Certainly, if I publish a policy of p=reject and a receiver allows an email > that should have been rejected to reach their user/customer and that person > contacts me because that message caused them a problem, I'm going to tell > them they need to speak with their mail administrator, mailbox provider, > etc. I've done that in the past and I'll do it in the future. What others > choose to do is their choice. While I may have an opinion, I recognize that > it is their choice. > >> >> We have only two ways to block unwanted messages: Identify unwanted and >> malicious messages based on the sender, or based on the content. >> Impersonation interferes with the sender reputation assessment, so we know >> that attackers have an incentive to impersonate. Sender Authentication >> provides information about messages that MIGHT be impersonations >> because they are not authenticated. Fortunately, most messages can be >> authenticated. >> > > You are again misrepresenting what DMARC is and does. It is NOT a guessing > game about whether a recipient might want a given email. It is a simple > pass/fail that should be automated before a message ever (potentially) gets > to a recipient. It may be as simple as the message took an unintended or > unexpected path which potentially creates risks from the perspective of the > sending domain. DMARC knows nothing about whether email is wanted or > unwanted on the receiving side of the mailstream. It knows nothing about > reputation. DMARC is not a substitute for other filtering or reputation > systems. DMARC is not a Swiss Army knife, was never intended to be one, nor > is it appropriate to pretend you can contort it into one. > > I absolutely agree with John regarding his comments and agree with his > sentiment of " I am so tired of people imagining that DMARC is more than it > is." > > Michael Hammer > > >> >> Doug >> >> >> >> >> On Wed, Jul 19, 2023 at 5:32 PM John Levine wrote: >> >>> It appears that Barry Leiba said: >>> >> - An attacker sends 10 messages that maliciously impersonates a >>> >> big bank. With help from DMARC p=reject, the evaluator blocks >>> >> them all. The attacker follows up with 10 messages that >>> >> maliciously impersonate a major university. The stupid >>> >> evaluator says, "p=none means no problem here". The message is >>> >> accepted and the user is harmed because the evaluator learned >>> >> nothing from blocking the successful attack. >>> > >>> >This is a useful point, and I think we should do something with it. >>> >>> Sorry, but I completely disagree. >>> >>> The interesting filtering data is that a bunch of unauthenticated mail >>> arrived from some source. As we have learned over and over, someone's >>> DMARC policy tells you nothing about the threat level or whether the >>> failure is an attack or a mailing list, only that someone decided for >>> whatever reason to publish p=reject. >>> >>> If a source sends a burst of unauthenticated mail, it could often be a >>> good idea to give that source a poor reputation. Or maybe you have a >>> reason to believe otherwise, e.g., it's been sending bursts of >>> unauthe
Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
On Wed, Jul 19, 2023 at 6:21 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > Perhaps you can clarify what you think DMARC is. > > Apparently a significant number of evaluators think that "DMARC Fail with > p=reject always means unwanted mail". Or to use Michael Hammer's > language, "DMARC Fail with p=reject means the domain owner wants it > rejected so I will reject it."These are exactly the attitudes that > cause us so much trouble because (a) DMARC Fail with p=reject does not mean > that rejection is always the correct response, and (b) DMARC Fail with > p=none is an important piece of information. > You are misrepresenting my position by ignoring local policy. A DMARC policy of quarantine or reject is a request by the domain owner or administrator. While consideration of a sending domain's request should be given consideration, a receiving domain is free to do as it wishes. A receiving domain may choose not to implement DMARC validation at all. A sending domain may believe that the risk of some legitimate emails being rejected or quarantined is an acceptable tradeoff in order to protect itself and users/recipients. You appear to have a problem with these choices being made by both the sending domain and the receiving domain. Why do you presume to know better than they as to what they should do? Certainly, if I publish a policy of p=reject and a receiver allows an email that should have been rejected to reach their user/customer and that person contacts me because that message caused them a problem, I'm going to tell them they need to speak with their mail administrator, mailbox provider, etc. I've done that in the past and I'll do it in the future. What others choose to do is their choice. While I may have an opinion, I recognize that it is their choice. > > We have only two ways to block unwanted messages: Identify unwanted and > malicious messages based on the sender, or based on the content. > Impersonation interferes with the sender reputation assessment, so we know > that attackers have an incentive to impersonate. Sender Authentication > provides information about messages that MIGHT be impersonations > because they are not authenticated. Fortunately, most messages can be > authenticated. > You are again misrepresenting what DMARC is and does. It is NOT a guessing game about whether a recipient might want a given email. It is a simple pass/fail that should be automated before a message ever (potentially) gets to a recipient. It may be as simple as the message took an unintended or unexpected path which potentially creates risks from the perspective of the sending domain. DMARC knows nothing about whether email is wanted or unwanted on the receiving side of the mailstream. It knows nothing about reputation. DMARC is not a substitute for other filtering or reputation systems. DMARC is not a Swiss Army knife, was never intended to be one, nor is it appropriate to pretend you can contort it into one. I absolutely agree with John regarding his comments and agree with his sentiment of " I am so tired of people imagining that DMARC is more than it is." Michael Hammer > > Doug > > > > > On Wed, Jul 19, 2023 at 5:32 PM John Levine wrote: > >> It appears that Barry Leiba said: >> >> - An attacker sends 10 messages that maliciously impersonates a >> >> big bank. With help from DMARC p=reject, the evaluator blocks >> >> them all. The attacker follows up with 10 messages that >> >> maliciously impersonate a major university. The stupid >> >> evaluator says, "p=none means no problem here". The message is >> >> accepted and the user is harmed because the evaluator learned >> >> nothing from blocking the successful attack. >> > >> >This is a useful point, and I think we should do something with it. >> >> Sorry, but I completely disagree. >> >> The interesting filtering data is that a bunch of unauthenticated mail >> arrived from some source. As we have learned over and over, someone's >> DMARC policy tells you nothing about the threat level or whether the >> failure is an attack or a mailing list, only that someone decided for >> whatever reason to publish p=reject. >> >> If a source sends a burst of unauthenticated mail, it could often be a >> good idea to give that source a poor reputation. Or maybe you have a >> reason to believe otherwise, e.g., it's been sending bursts of >> unauthenticated mail for years, nobody's ever marked it as spam, >> because it's some kind of courtesy forward. >> >> Note that you would do exactly the same thing if the burst of >> unauthenticated university mail preceded the burst of bank mail. It's >> the authentication failure that tells you that there may be a problem, >> not the DMARC policy. >> >> Mail filtering is complicated, so much so that handling the signals is >> more than a full time job at many mail systems. I expect that large >> mail systems have their own ideas abou who's a bank, who's a >> university, who's a public mai
Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
Perhaps you can clarify what you think DMARC is. Apparently a significant number of evaluators think that "DMARC Fail with p=reject always means unwanted mail". Or to use Michael Hammer's language, "DMARC Fail with p=reject means the domain owner wants it rejected so I will reject it."These are exactly the attitudes that cause us so much trouble because (a) DMARC Fail with p=reject does not mean that rejection is always the correct response, and (b) DMARC Fail with p=none is an important piece of information. We have only two ways to block unwanted messages: Identify unwanted and malicious messages based on the sender, or based on the content. Impersonation interferes with the sender reputation assessment, so we know that attackers have an incentive to impersonate. Sender Authentication provides information about messages that MIGHT be impersonations because they are not authenticated. Fortunately, most messages can be authenticated. Doug On Wed, Jul 19, 2023 at 5:32 PM John Levine wrote: > It appears that Barry Leiba said: > >> - An attacker sends 10 messages that maliciously impersonates a > >> big bank. With help from DMARC p=reject, the evaluator blocks > >> them all. The attacker follows up with 10 messages that > >> maliciously impersonate a major university. The stupid > >> evaluator says, "p=none means no problem here". The message is > >> accepted and the user is harmed because the evaluator learned > >> nothing from blocking the successful attack. > > > >This is a useful point, and I think we should do something with it. > > Sorry, but I completely disagree. > > The interesting filtering data is that a bunch of unauthenticated mail > arrived from some source. As we have learned over and over, someone's > DMARC policy tells you nothing about the threat level or whether the > failure is an attack or a mailing list, only that someone decided for > whatever reason to publish p=reject. > > If a source sends a burst of unauthenticated mail, it could often be a > good idea to give that source a poor reputation. Or maybe you have a > reason to believe otherwise, e.g., it's been sending bursts of > unauthenticated mail for years, nobody's ever marked it as spam, > because it's some kind of courtesy forward. > > Note that you would do exactly the same thing if the burst of > unauthenticated university mail preceded the burst of bank mail. It's > the authentication failure that tells you that there may be a problem, > not the DMARC policy. > > Mail filtering is complicated, so much so that handling the signals is > more than a full time job at many mail systems. I expect that large > mail systems have their own ideas abou who's a bank, who's a > university, who's a public mail system, and so forth. You get exactly > none of that from DMARC. After all, yahoo is p=reject, gmail and > hotmail/outlook are p=none. > > I am so tired of people imagining that DMARC is more than it is. > > R's, > John > > ___ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
Douglas Foster writes: > Baptiste's proposal is clearly the easiest to implement: Admins inform the > group that IETF is going to stop munging on a specific date. After that date, > subscribers are switched to digest mode if the MLM or the user detects > problems. Admins switch them back when the user reports that the list > traffic has an exception in place by the subscriber's evaluator. This > approach may also be sufficient for this list, as I suspect that most of our > evaluators will already have an exemption for IETF. I do not think there is any need for admins to switch users back. Users are already able to log in to list options page (https://www.ietf.org/mailman/options/dmarc for this list) and change Set Digest Mode option on or off. So if the mailing list receives bounce from specific user, and that user is not yet using digest mode, then mailing list would turn on digest mode. If it gets bounce from the digest email sent to the user, it would do whatever it now does when it receives bounces (I think they temporarely disable deliver, and after some time they will try again and after repeated failures they will remove user from the list or something like that). If user thinks his mail system is fixed so non digested emails works, he can log in to options page for the mailing list and turn of digest mode. If he was wrong and the non-digested emails do not work, then there will be bounce, and digest mode gets automatically turned on again. There is no point of asking admins to do anything for specific users, when users can do those operations themselves. -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Wei Chuang writes: > 2) The proposed language calls out "“alumni forwarders”, role-based email > aliases, and mailing lists" for consideration by receivers. How should > receivers be aware that traffic failing authentication should be reconsidered? > Mailing-lists sometimes uses RFC2919 List-id headers. Can Section 5.8 [1] > call out more strongly the application of those List-id headers? Can > something be done so that receivers can identify the other scenarios e.g. > role-based email aliases and alumni-forwarders? For alumni forwarders / role-based forwarders things are different, as users who set those up, actually knows who does the forwarding, and they themself recognize that emails coming to those addresses are important to them, and they also trust (university etc) the one doing forwarding. So if the alumni forwarder / role-based forwarder adds ARC signatures, then the final recipient can whitelist that ARC signer in their setup and say that the policy code that checks the SPF/DKIM/DMARC results can fully trust the signed ARC authentication results from that signer. This of course requires that the recipient SMTP server can't simply reject the incoming email after the MAIL FROM because SPF checks do not match, they actually need to receive the email so they can check ARC and DKIM headers... -- kivi...@iki.fi ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
It appears that Barry Leiba said: >> - An attacker sends 10 messages that maliciously impersonates a >> big bank. With help from DMARC p=reject, the evaluator blocks >> them all. The attacker follows up with 10 messages that >> maliciously impersonate a major university. The stupid >> evaluator says, "p=none means no problem here". The message is >> accepted and the user is harmed because the evaluator learned >> nothing from blocking the successful attack. > >This is a useful point, and I think we should do something with it. Sorry, but I completely disagree. The interesting filtering data is that a bunch of unauthenticated mail arrived from some source. As we have learned over and over, someone's DMARC policy tells you nothing about the threat level or whether the failure is an attack or a mailing list, only that someone decided for whatever reason to publish p=reject. If a source sends a burst of unauthenticated mail, it could often be a good idea to give that source a poor reputation. Or maybe you have a reason to believe otherwise, e.g., it's been sending bursts of unauthenticated mail for years, nobody's ever marked it as spam, because it's some kind of courtesy forward. Note that you would do exactly the same thing if the burst of unauthenticated university mail preceded the burst of bank mail. It's the authentication failure that tells you that there may be a problem, not the DMARC policy. Mail filtering is complicated, so much so that handling the signals is more than a full time job at many mail systems. I expect that large mail systems have their own ideas abou who's a bank, who's a university, who's a public mail system, and so forth. You get exactly none of that from DMARC. After all, yahoo is p=reject, gmail and hotmail/outlook are p=none. I am so tired of people imagining that DMARC is more than it is. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
Hi, Le 19/07/2023 à 19:38, Alessandro Vesely a écrit : > > Oops, I had in mind that lists modify messages. Some of them don't, > that way they don't need From: munging. It is quite common too. > > Let me reword the question: Are there lists that modify messages and > don't munge From:? What exactly is this question achieving? It looks to me, what you are trying to assess is the level of resignation, after 10 years of bullying, to a poor workaround that we know list users hate (because it breaks the semantics of the conversation). Cynical at best. We also know this workaround doesn't help DMARC in the long run, as it undermines the significance of the From header. Which is why this group never endorsed it. So where do we go from here? Cheers, Baptiste ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
On July 19, 2023 5:38:08 PM UTC, Alessandro Vesely wrote: >On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote: >> On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely wrote: >>> On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote: On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 1) For evaluators that enforce DMARC against lists, are they willing to > consider any concessions to list traffic? If so, do they favor an > exemption process where the list avoids munging, or an unmunging solution > implemented at their inbound gateway? How do you determine that an evaluator is enforcing DMARC "against lists"? >>> >>> That assumes there are lists that don't munge From:. Is that real today? >> >> Most of my list mail is from lists that don't. > > >Oops, I had in mind that lists modify messages. Some of them don't, that way >they don't need From: munging. It is quite common too. > >Let me reword the question: Are there lists that modify messages and don't >munge From:? > Yes, although those are fewer. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
It appears that Scott Kitterman said: >>That assumes there are lists that don't munge From:. Is that real today? > >Most of my list mail is from lists that don't. > >Scott K Even for lists that do change the From: they do it in a zillion different ways that depend on the goals of the list and the kind of infrastructure they have. Since message munging is out of scope for DMARC, it should would be nice if people interested in this topic could find some other place to argue about it. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
Alessandro Vesely skrev den 2023-07-19 19:38: Let me reword the question: Are there lists that modify messages and don't munge From:? Authentication-Results: mx.junc.eu (amavisd-new); dkim=pass (1024-bit key) header.d=ietf.org header.b="M78Nxm+h"; dkim=pass (1024-bit key) header.d=ietf.org header.b="KUhOcaZu"; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=tana.it header.b="sAKZ9jA7"; dkim=fail (1152-bit key) reason="fail (body has been altered)" header.d=tana.it header.b="Axzjfts6" i really don't know :) ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
On Wed 19/Jul/2023 15:25:17 +0200 Scott Kitterman wrote: On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely wrote: On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote: On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: 1) For evaluators that enforce DMARC against lists, are they willing to consider any concessions to list traffic? If so, do they favor an exemption process where the list avoids munging, or an unmunging solution implemented at their inbound gateway? How do you determine that an evaluator is enforcing DMARC "against lists"? That assumes there are lists that don't munge From:. Is that real today? Most of my list mail is from lists that don't. Oops, I had in mind that lists modify messages. Some of them don't, that way they don't need From: munging. It is quite common too. Let me reword the question: Are there lists that modify messages and don't munge From:? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
On 7/19/2023 8:10 AM, Murray S. Kucherawy wrote: On Wed, Jul 19, 2023 at 12:27 AM Alessandro Vesely wrote: > How do you determine that an evaluator is enforcing DMARC "against lists"? That assumes there are lists that don't munge From:. Is that real today? I wasn't aware that this munging had become a standard, or even common. It's a popular solution to DMARC specifically, to be sure. Anecdotal example, but most lists I've been a part of personally, or worked with domains that had users on various different lists, almost all of them used munging for domains with p=reject. Without data from all lists that exists in totality on the internet it's hard to really say how common statistically, but my experience has seemed that it is more common, than uncommon.___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
On July 19, 2023 7:27:00 AM UTC, Alessandro Vesely wrote: >On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote: >> On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < >> dougfoster.emailstanda...@gmail.com> wrote: >> >>> 1) For evaluators that enforce DMARC against lists, are they willing to >>> consider any concessions to list traffic? If so, do they favor an >>> exemption process where the list avoids munging, or an unmunging solution >>> implemented at their inbound gateway? >> >> How do you determine that an evaluator is enforcing DMARC "against lists"? > > >That assumes there are lists that don't munge From:. Is that real today? Most of my list mail is from lists that don't. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
On Wed, Jul 19, 2023 at 12:27 AM Alessandro Vesely wrote: > > How do you determine that an evaluator is enforcing DMARC "against > lists"? > > That assumes there are lists that don't munge From:. Is that real today? > I wasn't aware that this munging had become a standard, or even common. It's a popular solution to DMARC specifically, to be sure. > How can one definitively identify list traffic? > > Certainly not by List-* headers. In particular, List-Unsubscribe: seems > to be > required in most mail messages. > They may be common, but they are not required. > Also, I imagine that if munging is to be considered reversible, either the > > munging itself, or a way to describe it, needs to be standardized in some > > form. > > Hasn't that ship sailed already? > Can you please point me to the specification? -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
Trying to stay within Barry's guidelines, my original comment was about this list, but with an eye to how it can be generalized. In any specific case, the message stream from a list like our own should be identifiable by seeing expected values for: - MailFrom address = list bounce address - DKIM signature with DKIM PASS (to retain authentication after secondary forwarding) - List ID - To address = list's posting address - SPF PASS or SPF NONE at first hop after list forwarding - ARC data that identifies the forwarding point and affirms the author identity I do not suggest that a general mail stream can be parsed to detect a previously unknown list. Nor do not suggest that an automated detection process can be safely used to grant the privileged status needed by lists. I do think ARC will need additional tokens to describe tools other than SPF and DKIM which a list may use to authenticate a post's author. Options for our specific list: We have alternatives to the current munging behavior, and this group is highly motivated to see munging go away. So something should be done. Baptiste's proposal is clearly the easiest to implement: Admins inform the group that IETF is going to stop munging on a specific date. After that date, subscribers are switched to digest mode if the MLM or the user detects problems. Admins switch them back when the user reports that the list traffic has an exception in place by the subscriber's evaluator. This approach may also be sufficient for this list, as I suspect that most of our evaluators will already have an exemption for IETF. Emanuel's approach requires software development by every evaluator or their software providers. The Intranet has a decreasing number of software providers and hosting services,, but this scope seems problematic even for the limited scale of this list. The larger problem is that the software implementation still needs human guidance about which messages should be un-munged. Malicious actors will add un-munging signals if they think it will enhance their attacks and permit impersonation. So I keep coming back to the most difficult proposal, which is my own. An evaluator needs to be able to identify specific list traffic using information provided by the list, probably through a disclosure statement or service agreement document. To facilitate automation, the disclosure could eventually be standardized as an XML document, perhaps supplemented by free-form content for human consumption. We need an initial list, our own, to work out that standard. Ultimately, my approach still requires a transaction where a human decides to trust the list and restore it to "privileged" status, typically in response to a support ticket from a subscriber to his own email administration. I admit that my approach also has scaling problems, because each list must be considered individually. For the moment, the scope is one list, not all lists. Being a trustworthy list is also very important to me. Baptiste's approach does not require the list to make any promises, so it does not require the list to undertake any security improvements. I want to see this list implement 100% sender authentication even more badly than I want munging removed. I want that level of authentication to become the norm when the concept scales upward. Disclosure statements only work when they are not announcing vulnerabilities. Doug Foster On Wed, Jul 19, 2023 at 2:20 AM Murray S. Kucherawy wrote: > On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> 1) For evaluators that enforce DMARC against lists, are they willing to >> consider any concessions to list traffic? If so, do they favor an >> exemption process where the list avoids munging, or an unmunging solution >> implemented at their inbound gateway? >> > > How do you determine that an evaluator is enforcing DMARC "against > lists"? How can one definitively identify list traffic? > > Also, I imagine that if munging is to be considered reversible, either the > munging itself, or a way to describe it, needs to be standardized in some > form. > > -MSK > ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
On Wed 19/Jul/2023 08:20:14 +0200 Murray S. Kucherawy wrote: On Tue, Jul 18, 2023 at 4:27 AM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: 1) For evaluators that enforce DMARC against lists, are they willing to consider any concessions to list traffic? If so, do they favor an exemption process where the list avoids munging, or an unmunging solution implemented at their inbound gateway? How do you determine that an evaluator is enforcing DMARC "against lists"? That assumes there are lists that don't munge From:. Is that real today? How can one definitively identify list traffic? Certainly not by List-* headers. In particular, List-Unsubscribe: seems to be required in most mail messages. Also, I imagine that if munging is to be considered reversible, either the munging itself, or a way to describe it, needs to be standardized in some form. Hasn't that ship sailed already? Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
