Re: [dmarc-ietf] How did DMARC go wrong, and how does our document fix it?
Dne 21. 7. 2023 v 16:34 Murray S. Kucherawy napsal(a): On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: 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. Since even before SPF, people have been looking for a silver bullet to stop spam and phishing. I'm not surprised to hear that there are products out there that promise or implement such, despite the specifications not actually saying this is a good idea, or even (in DKIM's case, I believe) being rather explicit that it isn't. I don't think anyone is disputing that the DMARC result by itself is not a clear answer about what one should do upon receiving a message. The only time you really know something is when DMARC passes, but even that isn't a strong signal about the content of the message. All other answers are muddy, and should be treated that way. If DMARCbis needs to make this more explicit, I don't see a problem with doing so. I think a DMARC-aware product that's reject-on-fail by default has made a questionable choice, and not making that configurable is doubly so. However, I don't think an evaluator should be looking at the "p=" value and then trying to infer anything about the sending domain solely from that. This, to me, is crystal ball territory. We should omit it from our calculus. -MSK, participating Although SPF, DKIM, DMARC, and ARC are all intended to protect against SPAM, it is not possible, as a matter of principle, to protect against such kind of communications. They will only allow, to a certain extent, protection against fake emails. But SPAM is junk mail, which includes official, albeit unsolicited, communications from organizations that meet the requirements of the technology. It is unethical, but technically acceptable. Moreover, the assessment of junk mail is highly subjective, for the reason I prefer the term accepted censorship. Because censorship is an intervention that, as a rule, cannot be influenced by the user. For the reason given, it is not possible to protect against SPAM in its entirety. These technologies only allow protection against fake mail. This leads me to the next step, which you may not agree with. If this technology serves to protect against mail being counterfeited, it can be argued, with a degree of simplification, that it provides some form of brand protection. And the methods of brand protection, including the hardness of the methods used, should be decided by the owner. And the enforcement of those rules should be ensured by the administrator. Am I thinking correctly? Regards Jan ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Fri 21/Jul/2023 17:18:50 +0200 Scott Kitterman wrote: On July 21, 2023 3:14:58 PM UTC, Alessandro Vesely wrote: Maybe one day there will be a DMARC with batteries included, where implementers ship default configurations which are effective out of the box. While I don't know how to get there, I think it's counter-productive to exact perfect compliance during the transition. There have to be people who think they have good reasons to push, otherwise we won't move. It's not a transition until there's something to transition to. Currently it's a bridge to nowhere. As Doug said it's not at all clear what everybody's goal in this effort is, I'll state mine too. I run a tiny mail server for family and friends. I find it frustrating to rely on DNSBLs both as a receiver and as a sender, blocking and being blocked at random. I /believe/ there is a better, clean way that anyone could easily operate a small mail server. Email authentication seems to me to be on the path to make that belief come true. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On July 21, 2023 3:14:58 PM UTC, Alessandro Vesely wrote: >On Fri 21/Jul/2023 10:22:06 +0200 Matthäus Wander wrote: >> Murray S. Kucherawy wrote on 2023-07-08 02:44: >>> "SHOULD" leaves the implementer with a choice. You really ought to do what >>> it says in the general case, but there might be circumstances where you >>> could deviate from that advice, with some possible effect on >>> interoperability. If you do that, it is expected that you fully understand >>> the possible impact you're about to have on the Internet before proceeding. >>> To that end, we like the use of SHOULD [NOT] to be accompanied by some >>> prose explaining when one might deviate in this manner, such as an example >>> of when it might be okay to do so. >> >> The elaborated Interoperability Considerations in Barry's proposal gives the >> implementer guidance to understand the impact. In my understanding, SHOULD >> is ought to be followed, unless the implementer has good reasons not to. The >> burden of justification is on the implementer, not on the spec. > > >The implementer, in turn, passes the buck to the user. To quote Cisco's email >security appliance[*]: > >The default behavior of the ESA is to never drop any messages unless >explicitly instructed by the customer, so default DMARC verification >profile will have all actions set to “No Action”. > >It has to stay that way until we fix forwarding. > > >>> Does anyone have such an example in mind that could be included here? >>> Specifically: Can we describe a scenario where (a) a sender publishes >>> p=reject (b) with users that post to lists (c) that the community at large >>> would be willing to accept/tolerate? >> >> The scenario I have in mind is a business domain with a high demand for >> protection from exact domain spoofing and a low to no demand for list >> communication. Note the wording in Barry's proposal: "users who *might* post >> messages to mailing lists" (not: "users that post to lists"). > > >ADSP characterized them as domains /with no individual human users/. Yet that >helps only the sender side of the equation. Since human receivers /might/ >want to forward messages to another mailbox, we're back to a protocol with no >humans on either side. A rather disconcerting position. > >Maybe one day there will be a DMARC with batteries included, where >implementers ship default configurations which are effective out of the box. >While I don't know how to get there, I think it's counter-productive to exact >perfect compliance during the transition. There have to be people who think >they have good reasons to push, otherwise we won't move. > It's not a transition until there's something to transition to. Currently it's a bridge to nowhere. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Fri 21/Jul/2023 10:22:06 +0200 Matthäus Wander wrote: Murray S. Kucherawy wrote on 2023-07-08 02:44: "SHOULD" leaves the implementer with a choice. You really ought to do what it says in the general case, but there might be circumstances where you could deviate from that advice, with some possible effect on interoperability. If you do that, it is expected that you fully understand the possible impact you're about to have on the Internet before proceeding. To that end, we like the use of SHOULD [NOT] to be accompanied by some prose explaining when one might deviate in this manner, such as an example of when it might be okay to do so. The elaborated Interoperability Considerations in Barry's proposal gives the implementer guidance to understand the impact. In my understanding, SHOULD is ought to be followed, unless the implementer has good reasons not to. The burden of justification is on the implementer, not on the spec. The implementer, in turn, passes the buck to the user. To quote Cisco's email security appliance[*]: The default behavior of the ESA is to never drop any messages unless explicitly instructed by the customer, so default DMARC verification profile will have all actions set to “No Action”. It has to stay that way until we fix forwarding. Does anyone have such an example in mind that could be included here? Specifically: Can we describe a scenario where (a) a sender publishes p=reject (b) with users that post to lists (c) that the community at large would be willing to accept/tolerate? The scenario I have in mind is a business domain with a high demand for protection from exact domain spoofing and a low to no demand for list communication. Note the wording in Barry's proposal: "users who *might* post messages to mailing lists" (not: "users that post to lists"). ADSP characterized them as domains /with no individual human users/. Yet that helps only the sender side of the equation. Since human receivers /might/ want to forward messages to another mailbox, we're back to a protocol with no humans on either side. A rather disconcerting position. Maybe one day there will be a DMARC with batteries included, where implementers ship default configurations which are effective out of the box. While I don't know how to get there, I think it's counter-productive to exact perfect compliance during the transition. There have to be people who think they have good reasons to push, otherwise we won't move. Best Ale -- [*] https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/215360-best-practice-for-email-authentication.html#toc-hId-103046190 ___ 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?
On Wed, Jul 19, 2023 at 6:31 PM Douglas Foster < dougfoster.emailstanda...@gmail.com> wrote: > 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. > Since even before SPF, people have been looking for a silver bullet to stop spam and phishing. I'm not surprised to hear that there are products out there that promise or implement such, despite the specifications not actually saying this is a good idea, or even (in DKIM's case, I believe) being rather explicit that it isn't. I don't think anyone is disputing that the DMARC result by itself is not a clear answer about what one should do upon receiving a message. The only time you really know something is when DMARC passes, but even that isn't a strong signal about the content of the message. All other answers are muddy, and should be treated that way. If DMARCbis needs to make this more explicit, I don't see a problem with doing so. I think a DMARC-aware product that's reject-on-fail by default has made a questionable choice, and not making that configurable is doubly so. However, I don't think an evaluator should be looking at the "p=" value and then trying to infer anything about the sending domain solely from that. This, to me, is crystal ball territory. We should omit it from our calculus. -MSK, participating ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
On Fri, Jul 21, 2023 at 1:22 AM Matthäus Wander wrote: > > "SHOULD" leaves the implementer with a choice. You really ought to do > > what it says in the general case, but there might be circumstances where > > you could deviate from that advice, with some possible effect on > > interoperability. If you do that, it is expected that you fully > > understand the possible impact you're about to have on the Internet > > before proceeding. To that end, we like the use of SHOULD [NOT] to be > > accompanied by some prose explaining when one might deviate in this > > manner, such as an example of when it might be okay to do so. > > The elaborated Interoperability Considerations in Barry's proposal gives > the implementer guidance to understand the impact. In my understanding, > SHOULD is ought to be followed, unless the implementer has good reasons > not to. The burden of justification is on the implementer, not on the spec. > I would agree, but I also think the more information and guidance you put in the hands of the implementer -- especially around something potentially thorny, like this -- the better your document's quality, because the better the outcome will be. > > Does anyone have such an example in mind that could be included here? > > Specifically: Can we describe a scenario where (a) a sender publishes > > p=reject (b) with users that post to lists (c) that the community at > > large would be willing to accept/tolerate? > > The scenario I have in mind is a business domain with a high demand for > protection from exact domain spoofing and a low to no demand for list > communication. Note the wording in Barry's proposal: "users who *might* > post messages to mailing lists" (not: "users that post to lists"). > > I wouldn't include such an example in the RFC, because I don't see a > discussion to this extent for any of the other SHOULD requirements in > the document. > I think you just explained why including such guidance is a good idea. -MSK ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
On Fri 21/Jul/2023 09:35:32 +0200 OLIVIER HUREAU wrote: Instead, I see language that drives people to fixate on the 1% of traffic that has a DMARC policy with p=reject. Indeed: I caution everyone about making assumptions based on what we think we know, and extending those assumptions to the entire Internet. There are things we can study (by, for example, doing DNS queries and analyzing results), and there are things about which we just say, "I don't know anyone who does [or doesn't do] this, so that must be the case overall." The latter is hazardous. According to September 2020 scans (https://ieeexplore.ieee.org/abstract/document/9375477/ 41% of them have p=reject, 9.3% have p=quarantine, and 39.6% have p=none. To quote the whole paragraph: Regarding DMARC, only 310,185 out of 236 million do- mains have DMARC corresponding to approximately 0.13% of the population. For the domains with a DMARC rule, 41% of them have p=reject , 9.3% have p=quarantine , and 39.6% have p=none rule. These figures are also far different from the 5.1% of the domain names in the Alexa top 1M domains with DMARC rules [9], which again confirms that more popular domain names deploy email anti-spoofing schemes on a wider scale. Granted we don't (and cannot) know reality as a whole. Efforts to achieve some knowledge are welcome, though. Best Ale -- ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Another p=reject text proposal
Murray S. Kucherawy wrote on 2023-07-08 02:44: "SHOULD" leaves the implementer with a choice. You really ought to do what it says in the general case, but there might be circumstances where you could deviate from that advice, with some possible effect on interoperability. If you do that, it is expected that you fully understand the possible impact you're about to have on the Internet before proceeding. To that end, we like the use of SHOULD [NOT] to be accompanied by some prose explaining when one might deviate in this manner, such as an example of when it might be okay to do so. The elaborated Interoperability Considerations in Barry's proposal gives the implementer guidance to understand the impact. In my understanding, SHOULD is ought to be followed, unless the implementer has good reasons not to. The burden of justification is on the implementer, not on the spec. Does anyone have such an example in mind that could be included here? Specifically: Can we describe a scenario where (a) a sender publishes p=reject (b) with users that post to lists (c) that the community at large would be willing to accept/tolerate? The scenario I have in mind is a business domain with a high demand for protection from exact domain spoofing and a low to no demand for list communication. Note the wording in Barry's proposal: "users who *might* post messages to mailing lists" (not: "users that post to lists"). I wouldn't include such an example in the RFC, because I don't see a discussion to this extent for any of the other SHOULD requirements in the document. Regards, Matt ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Eliminating From Munging from this list
> Instead, I see language that drives people to fixate on the 1% of traffic > that has a DMARC policy with p=reject. > Indeed: I caution everyone about making assumptions based on what we think we know, and extending those assumptions to the entire Internet. There are things we can study (by, for example, doing DNS queries and analyzing results), and there are things about which we just say, "I don't know anyone who does [or doesn't do] this, so that must be the case overall." The latter is hazardous. According to September 2020 scans ( [ https://ieeexplore.ieee.org/abstract/document/9375477/ | https://ieeexplore.ieee.org/abstract/document/9375477/ ] ) 41% of them have p=reject, 9.3% have p=quarantine, and 39.6% have p=none. However, my September 2022 measurements (not published) shows that only 38.3% have p != none. Even though, September 2020 scans resulted in only 310,185 organizational domain names with DMARC and my measurements 11M8. > Then we are disappointed if they don't look for exceptions, including mailing > list messages, One of our latest discussions was about domain owners having p=none who might enhance their infrastructure. >From my measurements, ~40% of domain owners have p=none but nor rua/ruf. I extrapolate that 40% of domain owners do not plan to have more restrictive handling policies. Thus what are the expectations of newcomers in DMARC? In my opinion, the current state of DMARC does not meet the expectations. I think that the task force should take a closer look at this problem and work towards a more user-friendly reporting system, and different, more customizable handling policies. Best De: "Douglas Foster" À: "IETF DMARC WG" Envoyé: Vendredi 21 Juillet 2023 01:40:49 Objet: Re: [dmarc-ietf] Eliminating From Munging from this list It is not at all clear that my goals for this effort match with others, so I will state mine: My goal is to develop documents that help evaluators make better disposition decisions, to save civilization from as much malicious content as possible. An inference from my piece of reality is that this effort has a large upside potential. Sender authentication is the core of this effort because it is something that we can actually specify. Defining a standard for defenses against malicious content seems infeasible. For all its difficulties, sender authentication is relatively feasible. Verification of RFC5322.From is the linchpin to Sender Authentication because the RFC5322.From address links the user-visible content to the invisible document metadata and SMTP protocol parameters. DMARC defines a formula for declaring the RFC5322.From address verified, thereby separating a general mailstream into two sub-streams: the verified portion and the unverified portion. This group has taken the position that a message is only verified if the domain owner has published a DMARC policy and the message produces DMARC PASS. From my data, that works out to about 40% of the traffic, most of which is Gmail. My results seem roughly consistent with data from other sources. This means that 60% of the traffic has no defined method for detecting possible impersonation, so network safety depends entirely on the strength of your content filtering. However, it is easy to note that the DMARC concept of Aligned SPF PASS or Aligned DKIM PASS is applicable to any message, with or without a DMARC policy. There is a minor complication about choosing between relaxed and strict authentication, which is solvable by local policy. Applying the DMARC formula to a general mailstream, the DMARC-equivalent PASS percentage suddenly jumps into the vicinity of 85%. The remaining 15% of mail has uncertain impersonation risk, but is much more manageable than 60%. It has been a fertile field for investigation. When I ask, "Why is this message not impersonated?", the investigation produces one of three answers: * The message stream is acceptable, but needs a local policy to allow future messages to appear authenticated. * The message stream is unwanted even though it is not an impersonation, so this and future messages from this sender should be blocked. * The message stream is from a malicious impersonator, so this and future messages from this sender should be blocked. Whichever conclusion is reached, investigation is a one-time effort per message source. So a technical path exists for ensuring 100% authentication of all allowed messages, and quarantining the uncertain messages for investigation. In my experience, the middle result dominates. As my recurring and wanted traffic gets an authentication rule, and unwanted traffic gets blocked, the volume of investigations goes down while the percentage of block results goes up. When I examine the language of RFC 7489 and our proposed documents, I find no path toward 100% authentication. Instead, I see language that drives people to fixate on the 1%
