Re: [dmarc-ietf] Weakening of enforcement concern
On Apr 11, 2023, at 1:06 PM, Douglas Foster wrote:Yes, I am talking about inbound policies. Mailing list damage happens when inbound filters block a harmless message that the user wants. So the best fix is for the inbound filters to acknowledge that they live in an environment with imperfect information.The Sender can only ensure that all of his mail is signed. He cannot ensure that no other legitimate source will impersonate on behalf of a single user, or that no legitimate intermediary will alter content during forwarding. The recipient evaluator has the job of delivering what its users need and blocking what can harm them or don't want. Senders cannot fix evaluators that do that poorly. Google says they cannot do conditional processing of p=reject, but they don't block on DMARC fail at all. They make up for that limitation by having other spam filtering logic that is pretty impressive. My Gmail accounts have very few problems with either spam getting through or wanted messages getting blocked.I don't have the same content filtering sophistication, so I have ramped up my sender filtering.Doug FosterOn Tue, Apr 11, 2023, 11:15 AM Neil Anuskiewiczwrote: > On Apr 11, 2023, at 4:29 AM, Douglas Foster wrote: > > > Neil, I am slowly embracing the position of the Mailing List advocates. > > If mailing lists and all other exceptional situations could be eliminated, evaluators could mindlessly apply a rule to "block on fail when p=reject". Similarly, if all evaluators would implement reliable mechanisms for domain members to request and obtain exceptions for mailing lists and other exceptional traffic, then domain owners could publish p=reject as soon as all of their traffic had signatures. Unfortunately, we have a reality that some highly valued traffic arrives without authentication, and some evaluators do not provide an effective exception process. This conundrum is aggravated by filtering products that do not provide administrators with sufficient exception configuration options. I am content with language that documents this conundrum. > > The Internet will always be an environment of imperfect information, so the only viable filtering scheme is one which expects and allows for exceptions. Additionally, my defenses against impersonation should not be dependent on the domain owner's policy statement. Any allowed message is implicitly assumed to be free of impersonation, but assumptions are dangerous. It is my job to replace guesswork with certainty based on research. As indicated earlier, this can be done. Using DMARC, SPF, and local policy, I am at 100% verified for MailFrom, and 97% verified for From. Mailing lists have nothing to fear from my filtering and I have nothing to fear from p=none It’s perfectly acceptable to create bypasses and whatever else you want. The local is the sacrosanct domain of the admin. I don’t see how this relates the standard. It should be as robust as possible. I’m likely missing something.I’ve dealt with convoluted mailing lists that couldn’t hold a candle to mailman. There’s always a solution. The reality of workarounds shouldn’t touch the standard.___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
> On Apr 11, 2023, at 2:45 PM, Neil Anuskiewicz wrote: > > > >> On Apr 11, 2023, at 2:29 PM, John Levine wrote: >> >> It appears that Neil Anuskiewicz said: >>> Thanks. Even if it hasn’t always been the case, DMARC has evolved to be >>> thought of by most technical people as focused on security. >> >> I can believe that's the case for people you know, but none of us know "most >> technical people". >> >> It's more likely that most actual technical people don't understand >> what DMARC does and doubly don't understand the tradeoffs between >> blocking malicious mail and losing legit mail that DMARC can't >> describe. >> >>> On the marketing side, authentication’s priority benefit is deliverability, >>> ... >> >> I hope I don't have to explain how deeply the IETF does not care about >> deliverability. > John, what does the IETF care about? I thought I knew but clearly I don’t. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
> On Apr 11, 2023, at 2:29 PM, John Levine wrote: > > It appears that Neil Anuskiewicz said: >> Thanks. Even if it hasn’t always been the case, DMARC has evolved to be >> thought of by most technical people as focused on security. > > I can believe that's the case for people you know, but none of us know "most > technical people". > > It's more likely that most actual technical people don't understand > what DMARC does and doubly don't understand the tradeoffs between > blocking malicious mail and losing legit mail that DMARC can't > describe. > >> On the marketing side, authentication’s priority benefit is deliverability, >> ... > > I hope I don't have to explain how deeply the IETF does not care about > deliverability. I don’t work in deliverability but I do care about it. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
It appears that Neil Anuskiewicz said: >Thanks. Even if it hasn’t always been the case, DMARC has evolved to be >thought of by most technical people as focused on security. I can believe that's the case for people you know, but none of us know "most technical people". It's more likely that most actual technical people don't understand what DMARC does and doubly don't understand the tradeoffs between blocking malicious mail and losing legit mail that DMARC can't describe. >On the marketing side, authentication’s priority benefit is deliverability, ... I hope I don't have to explain how deeply the IETF does not care about deliverability. R's, John ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
Yes, I am talking about inbound policies. Mailing list damage happens when inbound filters block a harmless message that the user wants.So the best fix is for the inbound filters to acknowledge that they live in an environment with imperfect information. The Sender can only ensure that all of his mail is signed. He cannot ensure that no other legitimate source will impersonate on behalf of a single user, or that no legitimate intermediary will alter content during forwarding. The recipient evaluator has the job of delivering what its users need and blocking what can harm them or don't want. Senders cannot fix evaluators that do that poorly. Google says they cannot do conditional processing of p=reject, but they don't block on DMARC fail at all. They make up for that limitation by having other spam filtering logic that is pretty impressive. My Gmail accounts have very few problems with either spam getting through or wanted messages getting blocked. I don't have the same content filtering sophistication, so I have ramped up my sender filtering. Doug Foster On Tue, Apr 11, 2023, 11:15 AM Neil Anuskiewicz wrote: > > > > On Apr 11, 2023, at 4:29 AM, Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > > > > > > Neil, I am slowly embracing the position of the Mailing List advocates. > > > > If mailing lists and all other exceptional situations could be > eliminated, evaluators could mindlessly apply a rule to "block on fail when > p=reject". Similarly, if all evaluators would implement reliable > mechanisms for domain members to request and obtain exceptions for mailing > lists and other exceptional traffic, then domain owners could publish > p=reject as soon as all of their traffic had signatures. Unfortunately, we > have a reality that some highly valued traffic arrives without > authentication, and some evaluators do not provide an effective exception > process. This conundrum is aggravated by filtering products that do not > provide administrators with sufficient exception configuration options. > I am content with language that documents this conundrum. > > > > The Internet will always be an environment of imperfect information, so > the only viable filtering scheme is one which expects and allows for > exceptions. Additionally, my defenses against impersonation should not be > dependent on the domain owner's policy statement.Any allowed message is > implicitly assumed to be free of impersonation, but assumptions are > dangerous. It is my job to replace guesswork with certainty based on > research. As indicated earlier, this can be done. Using DMARC, SPF, and > local policy, I am at 100% verified for MailFrom, and 97% verified for > From. Mailing lists have nothing to fear from my filtering and I have > nothing to fear from p=none. > > > > In short, we need smarter filtering. > > > > Doug Foster > > Mr. Foster, you seem (though I could be wrong) to be talking about inbound > where you have complete control but for policies set in domains sending > outbound, how would filters resolve the problem? We have little control > over outbound. Threat actors will Phish wherever the phishing is good. > > I guess I was hoping that security could be the top priority but it’s > likely naïveté. I can see the I trade offs. You piss off too many people > and you end up with a standard nobody wants to use. > > Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
> On Apr 11, 2023, at 9:14 AM, Mark Alley > wrote: > > > I agree with where you're coming from, as these were my same concerns as > well. That's why I also tried to say a couple of times that I feel if we make > an effort to make clear the interoperability expectations, but also have > accompanying language that those specific expectations do not make a > statement about perceived security benefits of strict DMARC policies... - My > hope is that should be sufficient enough of a compromise to address > everyone's concerns. > Thanks. Even if it hasn’t always been the case, DMARC has evolved to be thought of by most technical people as focused on security. I bet a poll would reveal this to be the case. On the marketing side, authentication’s priority benefit is deliverability, though I realize that dmarc can’t make up for sins such as bad list hygiene. the motivation of almost all tech people, including security folks, for implementing DMARC is for security and to protect their brand reputation. I know I don’t have much influence here so I’ll just say it one more time: people are motivated by security and would not want to compromise that for mailing lists. I think we should focus on security. It’s what most people want from dmarc. Of course it only protects exact domain phishing but there are other services that address other threats. this is our chance to really be in synch with why people want dmarc, which will open up more opportunities to do interesting things than a standard with a sort of ambiguous purpose. Ambiguity doesn’t lead down a good road. Neil___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
I agree with where you're coming from, as these were my same concerns as well. That's why I also tried to say a couple of times that I feel if we make an effort to make clear the interoperability expectations, but also have accompanying language that those specific expectations do not make a statement about perceived security benefits of strict DMARC policies... - My hope is that should be sufficient enough of a compromise to address everyone's concerns. - Mark Alley On 4/11/2023 10:15 AM, Neil Anuskiewicz wrote: On Apr 11, 2023, at 4:29 AM, Douglas Foster wrote: Neil, I am slowly embracing the position of the Mailing List advocates. If mailing lists and all other exceptional situations could be eliminated, evaluators could mindlessly apply a rule to "block on fail when p=reject". Similarly, if all evaluators would implement reliable mechanisms for domain members to request and obtain exceptions for mailing lists and other exceptional traffic, then domain owners could publish p=reject as soon as all of their traffic had signatures. Unfortunately, we have a reality that some highly valued traffic arrives without authentication, and some evaluators do not provide an effective exception process. This conundrum is aggravated by filtering products that do not provide administrators with sufficient exception configuration options.I am content with language that documents this conundrum. The Internet will always be an environment of imperfect information, so the only viable filtering scheme is one which expects and allows for exceptions. Additionally, my defenses against impersonation should not be dependent on the domain owner's policy statement.Any allowed message is implicitly assumed to be free of impersonation, but assumptions are dangerous. It is my job to replace guesswork with certainty based on research. As indicated earlier, this can be done. Using DMARC, SPF, and local policy, I am at 100% verified for MailFrom, and 97% verified for From. Mailing lists have nothing to fear from my filtering and I have nothing to fear from p=none. In short, we need smarter filtering. Doug Foster Mr. Foster, you seem (though I could be wrong) to be talking about inbound where you have complete control but for policies set in domains sending outbound, how would filters resolve the problem? We have little control over outbound. Threat actors will Phish wherever the phishing is good. I guess I was hoping that security could be the top priority but it’s likely naïveté. I can see the I trade offs. You piss off too many people and you end up with a standard nobody wants to use. Neil ___ 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] Weakening of enforcement concern
> On Apr 11, 2023, at 4:29 AM, Douglas Foster > wrote: > > > Neil, I am slowly embracing the position of the Mailing List advocates. > > If mailing lists and all other exceptional situations could be eliminated, > evaluators could mindlessly apply a rule to "block on fail when p=reject". > Similarly, if all evaluators would implement reliable mechanisms for domain > members to request and obtain exceptions for mailing lists and other > exceptional traffic, then domain owners could publish p=reject as soon as all > of their traffic had signatures. Unfortunately, we have a reality that some > highly valued traffic arrives without authentication, and some evaluators do > not provide an effective exception process. This conundrum is aggravated by > filtering products that do not provide administrators with sufficient > exception configuration options.I am content with language that documents > this conundrum. > > The Internet will always be an environment of imperfect information, so the > only viable filtering scheme is one which expects and allows for exceptions. > Additionally, my defenses against impersonation should not be dependent on > the domain owner's policy statement.Any allowed message is implicitly > assumed to be free of impersonation, but assumptions are dangerous. It is > my job to replace guesswork with certainty based on research. As indicated > earlier, this can be done. Using DMARC, SPF, and local policy, I am at 100% > verified for MailFrom, and 97% verified for From. Mailing lists have > nothing to fear from my filtering and I have nothing to fear from p=none. > > In short, we need smarter filtering. > > Doug Foster Mr. Foster, you seem (though I could be wrong) to be talking about inbound where you have complete control but for policies set in domains sending outbound, how would filters resolve the problem? We have little control over outbound. Threat actors will Phish wherever the phishing is good. I guess I was hoping that security could be the top priority but it’s likely naïveté. I can see the I trade offs. You piss off too many people and you end up with a standard nobody wants to use. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
Neil, I am slowly embracing the position of the Mailing List advocates. If mailing lists and all other exceptional situations could be eliminated, evaluators could mindlessly apply a rule to "block on fail when p=reject". Similarly, if all evaluators would implement reliable mechanisms for domain members to request and obtain exceptions for mailing lists and other exceptional traffic, then domain owners could publish p=reject as soon as all of their traffic had signatures. Unfortunately, we have a reality that some highly valued traffic arrives without authentication, and some evaluators do not provide an effective exception process. This conundrum is aggravated by filtering products that do not provide administrators with sufficient exception configuration options.I am content with language that documents this conundrum. The Internet will always be an environment of imperfect information, so the only viable filtering scheme is one which expects and allows for exceptions. Additionally, my defenses against impersonation should not be dependent on the domain owner's policy statement.Any allowed message is implicitly assumed to be free of impersonation, but assumptions are dangerous. It is my job to replace guesswork with certainty based on research. As indicated earlier, this can be done. Using DMARC, SPF, and local policy, I am at 100% verified for MailFrom, and 97% verified for From. Mailing lists have nothing to fear from my filtering and I have nothing to fear from p=none. In short, we need smarter filtering. Doug Foster On Tue, Apr 11, 2023 at 1:34 AM Neil Anuskiewicz wrote: > > > > On Apr 10, 2023, at 9:38 PM, Neil Anuskiewicz > wrote: > > > > > > > >>> On Apr 10, 2023, at 9:24 PM, Scott Kitterman > wrote: > >>> > >>> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: > >>> I’m a bit concerned that the document will discourage domain owners > from > >>> working toward an enforcing policy. I’ve seen at least one person say > that > >>> most domains don’t need to go to p=reject. I’ve seen all sorts of > domains > >>> attacked? Granted, high profile domains or perceived lucrative targets > will > >>> receive the most attention but threat actors absolutely do attack all > sorts > >>> of organizations all the time. > >>> > >>> Maybe I’ve misunderstood but I hope that no langue that could be > construed > >>> as discouraging domain owners from moving toward an enforcing policy > would > >>> be a mistake. > >> > >> It all depends on the user base of the domain and the tradeoff between > the > >> benefits of having such a policy against the interoperability risks of > having > >> such a policy. > >> > >> We absolutely should be discouraging blind adoption of policies that > result in > >> reduced utility for email. For any domain that has non-transactional > users, > >> that takes work to assess the completeness of email authentication > deployment, > >> assess aggregate reporting to understand the likely effects of either > >> p=quarantine or p=reject., and then evaluate the cost/benefit > trade-offs > >> associated with such policies. That's a non-trivial set of work to do > and > >> it's not cost effective for all domains to do it. > >> > >> Early in the deployment of SPF there was a similar push to deploy SPF > records > >> with -all (the SPF rough equivalent of p=reject). A lot of people did > it > >> without thinking it through and there were significant side effects. > The > >> community concluded that SPF Fail (due to the -all in the record > matching) was > >> not a sufficiently reliable indicator that mail should be rejected and > largely > >> stopped doing it. > > Scott, I’m also aware of what happened to SPF’s run as a policy layer. > There’s a big difference between SPF and DMARC. People deploy DMARC with > the knowledge that it is the policy layer. Many soon learn that SPF hard > fail isn’t honored much. > > There were too many costs to enforcing with SPF. DMARC’s SPF OR DKIM makes > for a more robust system that you can get your legit mail passing DMARC > consistently. SPF does was it does well but it with things like forwarding > breaking it, the presence of DKIM made up for some of SPF’s shortcomings > and vice-a-versa. I think we can agree that SPF, in retrospect, wasn’t a > good place to set policy. > > DMARC is a much stronger policy layer so I hope you are thinking that the > policy setting aspect will go the way of SPF? It won’t. > > Neil > ___ > 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] Weakening of enforcement concern
> On Apr 10, 2023, at 9:38 PM, Neil Anuskiewicz wrote: > > > >>> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote: >>> >>> On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: >>> I’m a bit concerned that the document will discourage domain owners from >>> working toward an enforcing policy. I’ve seen at least one person say that >>> most domains don’t need to go to p=reject. I’ve seen all sorts of domains >>> attacked? Granted, high profile domains or perceived lucrative targets will >>> receive the most attention but threat actors absolutely do attack all sorts >>> of organizations all the time. >>> >>> Maybe I’ve misunderstood but I hope that no langue that could be construed >>> as discouraging domain owners from moving toward an enforcing policy would >>> be a mistake. >> >> It all depends on the user base of the domain and the tradeoff between the >> benefits of having such a policy against the interoperability risks of >> having >> such a policy. >> >> We absolutely should be discouraging blind adoption of policies that result >> in >> reduced utility for email. For any domain that has non-transactional users, >> that takes work to assess the completeness of email authentication >> deployment, >> assess aggregate reporting to understand the likely effects of either >> p=quarantine or p=reject., and then evaluate the cost/benefit trade-offs >> associated with such policies. That's a non-trivial set of work to do and >> it's not cost effective for all domains to do it. >> >> Early in the deployment of SPF there was a similar push to deploy SPF >> records >> with -all (the SPF rough equivalent of p=reject). A lot of people did it >> without thinking it through and there were significant side effects. The >> community concluded that SPF Fail (due to the -all in the record matching) >> was >> not a sufficiently reliable indicator that mail should be rejected and >> largely >> stopped doing it. Scott, I’m also aware of what happened to SPF’s run as a policy layer. There’s a big difference between SPF and DMARC. People deploy DMARC with the knowledge that it is the policy layer. Many soon learn that SPF hard fail isn’t honored much. There were too many costs to enforcing with SPF. DMARC’s SPF OR DKIM makes for a more robust system that you can get your legit mail passing DMARC consistently. SPF does was it does well but it with things like forwarding breaking it, the presence of DKIM made up for some of SPF’s shortcomings and vice-a-versa. I think we can agree that SPF, in retrospect, wasn’t a good place to set policy. DMARC is a much stronger policy layer so I hope you are thinking that the policy setting aspect will go the way of SPF? It won’t. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
> On Apr 10, 2023, at 9:24 PM, Scott Kitterman wrote: > > On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: >> I’m a bit concerned that the document will discourage domain owners from >> working toward an enforcing policy. I’ve seen at least one person say that >> most domains don’t need to go to p=reject. I’ve seen all sorts of domains >> attacked? Granted, high profile domains or perceived lucrative targets will >> receive the most attention but threat actors absolutely do attack all sorts >> of organizations all the time. >> >> Maybe I’ve misunderstood but I hope that no langue that could be construed >> as discouraging domain owners from moving toward an enforcing policy would >> be a mistake. > > It all depends on the user base of the domain and the tradeoff between the > benefits of having such a policy against the interoperability risks of having > such a policy. > > We absolutely should be discouraging blind adoption of policies that result > in > reduced utility for email. For any domain that has non-transactional users, > that takes work to assess the completeness of email authentication > deployment, > assess aggregate reporting to understand the likely effects of either > p=quarantine or p=reject., and then evaluate the cost/benefit trade-offs > associated with such policies. That's a non-trivial set of work to do and > it's not cost effective for all domains to do it. > > Early in the deployment of SPF there was a similar push to deploy SPF records > with -all (the SPF rough equivalent of p=reject). A lot of people did it > without thinking it through and there were significant side effects. The > community concluded that SPF Fail (due to the -all in the record matching) > was > not a sufficiently reliable indicator that mail should be rejected and > largely > stopped doing it. > > Aggressively pushing DMARC p=reject on domains that aren't ready for it may > well lead to a similar result. Let’s not. I’m not for aggressively advocation for p=reject. Before my current job I worked as a one person business with mostly small businesses. My contracts weren’t just about authentication but when it became clear that a company didn’t have the bandwidth to get to and maintain an enforcing policy, I didn’t push it. It likely would have done more harm than good. The document should make it clear that you have to know what you’re doing to get to an enforcing policy. So I’m not advocating boosterism for enforcing policies for everyone. But medium to large businesses I think should move toward an enforcing policy. We shouldn’t make it sound easy because it is not! Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
> On Apr 10, 2023, at 9:13 PM, Neil Anuskiewicz wrote: > > I’m a bit concerned that the document will discourage domain owners from > working toward an enforcing policy. I’ve seen at least one person say that > most domains don’t need to go to p=reject. I’ve seen all sorts of domains > attacked? Granted, high profile domains or perceived lucrative targets will > receive the most attention but threat actors absolutely do attack all sorts > of organizations all the time. > > Maybe I’ve misunderstood but I hope that no language that could be construed > as discouraging domain owners from moving toward an enforcing policy would be > added to the document. I meant to say that I’ve seen all sorts of domains attacked. The goal should be to get to an enforcing policy. It makes sense for very small businesses to be very reluctant to enforce unless they have the access to the expertise. But any domain owner that can should protect their domains. Neil ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] Weakening of enforcement concern
On Tuesday, April 11, 2023 12:13:33 AM EDT Neil Anuskiewicz wrote: > I’m a bit concerned that the document will discourage domain owners from > working toward an enforcing policy. I’ve seen at least one person say that > most domains don’t need to go to p=reject. I’ve seen all sorts of domains > attacked? Granted, high profile domains or perceived lucrative targets will > receive the most attention but threat actors absolutely do attack all sorts > of organizations all the time. > > Maybe I’ve misunderstood but I hope that no langue that could be construed > as discouraging domain owners from moving toward an enforcing policy would > be a mistake. It all depends on the user base of the domain and the tradeoff between the benefits of having such a policy against the interoperability risks of having such a policy. We absolutely should be discouraging blind adoption of policies that result in reduced utility for email. For any domain that has non-transactional users, that takes work to assess the completeness of email authentication deployment, assess aggregate reporting to understand the likely effects of either p=quarantine or p=reject., and then evaluate the cost/benefit trade-offs associated with such policies. That's a non-trivial set of work to do and it's not cost effective for all domains to do it. Early in the deployment of SPF there was a similar push to deploy SPF records with -all (the SPF rough equivalent of p=reject). A lot of people did it without thinking it through and there were significant side effects. The community concluded that SPF Fail (due to the -all in the record matching) was not a sufficiently reliable indicator that mail should be rejected and largely stopped doing it. Aggressively pushing DMARC p=reject on domains that aren't ready for it may well lead to a similar result. Let's not. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc