Re: [dmarc-ietf] Weakening of enforcement concern

[Neil Anuskiewicz]

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 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
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

[Neil Anuskiewicz]

> 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

[Neil Anuskiewicz]

> 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

[John Levine]

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

[Douglas Foster]

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

[Neil Anuskiewicz]

> 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

[Mark Alley]

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

[Neil Anuskiewicz]

> 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

[Douglas Foster]

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

[Neil Anuskiewicz]

> 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

[Neil Anuskiewicz]

> 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

[Neil Anuskiewicz]

> 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

[Scott Kitterman]

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

[dmarc-ietf] Weakening of enforcement concern

[Neil Anuskiewicz]

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. 

Neil
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc