Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-18 Thread Hector Santos
I have been “militantly” against Authorship destruction.  But fast forward to 
today, I am willing to support it IFF it can be officially sanctioned by the 
IETF using a well-defined Rewrite protocol for List Systems.

Overall, I believe if the middle ware performs a rewrite due to an author’s 
restrictive policy, we should consider these technical concepts:

1) Applicable to p=reject or p=quarantine only,
2) A domain rewrite SHOULD match the original domain security.

For example,  for this list,  the IETF list manager rewrites my address:

hsantos@isdg,net

to

hsantos=40isdg@dmarc.ietf.org 

I believe any domain transformation should retain the p=reject isdg.net 
 policy security level.  In this case, p=reject was weaken to 
p=none with the domain change.

So I can support rewrites iff the domain security can be retained.

All the best,
Hector Santos



> On Sep 14, 2023, at 5:27 PM, Wei Chuang  
> wrote:
> 
> 
> 
> On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman  > wrote:
>> On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
>> > We had an opportunity to further review the DMARCbis changes more broadly
>> > within Gmail.  While we don't see any blockers in the language in DMARCbis
>> > version 28
>> >  and
>> > can live with what is there, we wanted to briefly raise some concerns
>> > around some of the changes.  Two points.
>> > 
>> > Regarding the languages in section 8.6 "It is therefore critical that
>> > domains that host users who might post messages to mailing lists SHOULD NOT
>> > publish p=reject.  Domains that choose to publish p=reject SHOULD implement
>> > policies that their users not post to Internet mailing lists", we wanted to
>> > point out that this is impossible to implement.  Many enterprises already
>> > have "p=reject" policies.  Presumably those domains were subject to some
>> > sort of spoofing which is why they went to such a strict policy.  It would
>> > be unreasonable to tell them to stop posting to mailing lists as many
>> > likely already use mailing list services and will want to continue to use
>> > them.  The one thing that makes this tractable is the SHOULD language as we
>> > may choose not to not follow this aspect of the specification.  Our
>> > suggestion is that there is not a lot of value in including this language
>> > in the bis document if the likely outcome is that it will be ignored, and
>> > rather more effort should be placed with a technical solution for interop
>> > with mailing lists.
>> 
>> It might be helpful if you could describe this technical solution from your 
>> perspective.
>> 
>> If there were a reasonable technical solution available, I think this would 
>> be 
>> a much easier change to support (in my opinion, and a believe a substantial 
>> number of others, rewriting From is not a reasonable technical solution).
>> 
>> Scott K
> 
> Apologies for the delay in getting back to this. 
> 
> So yes I believe there are two possible technical approaches broadly speaking 
> 1) Support rewriting From and being able to reverse it along with message 
> modifications to recover the original DKIM message hash to validate the 
> original DKIM signature.  2) Create a new message authentication method that 
> is tolerant of message modifications and message forwarding, and supported by 
> DMARC.  From header rewriting would not be necessary in this scenario.  
> Beyond the complexity of supporting either method, another tricky thing in 
> both cases is supporting an ecosystem with diverse adoption of said 
> technique.  More concrete proposals for 1) and 2) are 1) 
> draft-chuang-mailing-list-modifications 
>  
> and 2) draft-chuang-replay-resistant-arc 
> .  And there are other I-Ds out 
> there particularly for the first approach.
> 
> -Wei
> 
> ___
> 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] Some Gmail comments on DMARCbis version 28

2023-09-18 Thread Hector Santos

Hello esteemed colleagues,

I'm sure we're on the cusp of a future where only "Authenticated Mail of the 
Fifth Kind" will reign supreme—much like the exclusive club of Submission 
Protocol requiring ESMTP AUTH on the ultra-special port 587. And surely, the 
ever-trusted port 25 will forever stand as a beacon of hope, right? Because how 
could we possibly survive without unsolicited, unauthenticated messages? 

Perhaps, just perhaps, in this utopian future, every sender will be upstanding 
citizens with impeccable SPF and DKIM policies. But of course, if any domain 
dares to relax these stringent policies, the noble and always compliant 
receivers will swoop in to defend the realm. And heaven forbid the receivers 
falter, for the all-seeing MAEA "Mail Authentication Enforcement Agency" is 
ever watchful, ready to unleash a fine.

And maybe, just maybe, we'll live in a world where the almighty MAEA gets to 
play tax collector, ensuring every sender pays their dues. Ah, but not the 
Fidonet and QWK loyalists! They'll be cruising without a care, exempt from the 
MAEA's grasp.

All in jest, of course, but it's food for thought!

Best regards,
Hector Santos


> On Sep 16, 2023, at 11:18 PM, Barry Leiba  wrote:
> 
> I believe, with you, that there's likely to be a time when
> unauthenticated mail simply will not be delivered by most receiving
> domains.  I similarly believe (as the owner of a Tesla) that there
> will be a time when cars will be self-driving in the vast majority,
> and that that will make the roads both safer and more efficient.
> 
> Neither of those situations is here yet, though, and neither is likely
> to arrive very soon.  Some day, yes.  Not yet, and not soon.
> 
> While we can certainly discuss the former -- particularly with a focus
> on what needs to happen before that situation can be realised -- we
> need to first make sure that we resolve the few remaining issues in
> the DMARCbis and reporting documents and get them published.
> 
> Barry
> 
> On Sat, Sep 16, 2023 at 6:56 AM Douglas Foster
>  wrote:
>> 
>> Yes, I suspected awhile back that I was the only one in the world 
>> implementing mandatory authentication.   This group has confirmed it.
>> 
>> But I hold out hope thst others will see the opportunity that it provides.  
>> Perhaps someone will read my Best Practices draft and sponsor it as an 
>> individual contribution or experimental draft.
>> 
>> Doug
>> 
>> 
>> On Fri, Sep 15, 2023, 9:26 AM Barry Leiba  wrote:
>>> 
 Content filtering creates a need for whitelisting
 Any domain may require whitelisting, regardless of sender policy.
 Whitelisting is only safe if it is coupled with an authentication 
 mechanism which prevents impersonation.
 Therefore, sender authentication, by a combination of local policy and 
 sender policy, needs to be defined for all possible messages.
>>> 
>>> The last statement there is where things go off the rails.  No,
>>> nothing has to work perfectly here, and mechanisms are useful and can
>>> well be standardized even when they don't work in "all possible"
>>> situations.
>>> 
>>> It's really important that we stop insisting on perfection or nothing,
>>> as that's a false dichotomy.  What we have now is demonstrably useful
>>> as *part of* an overall system.  We need to move forward with
>>> finishing the document.
>>> 
>>> Barry
>> 
>> ___
>> 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



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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-17 Thread Douglas Foster
I am not claiming any particular knowledge of the universe of all
implementations.  All I know is that if my user's want a mailing list
exempted from DMARC enforcement, all they have to do is ask, and that is
the way it should be most everywhere.   If the mailing list problem was
unique to AOL alone, then lists could do special processing specific for
AOL recipients.   But the problem is discussed in this forum as if it is
pervasive.  At least one previous post chastised me that any DMARC
specification MUST be fully automatic.  I couple those clues with my own
difficulty finding a product that anticipates and implements my need for
exceptions.  Finally, I note that RFC 7489 and DMARCbis are both silent
about what an exception mechanism would involve, so I cannot be surprised
that developers who follow the specification do not implement adequate
exception mechanisms, if at all.   So forgive me for feeling like I am the
only one on the planet who thinks a proper implementation needs specific
exception management features, especially since I believe the requirements
for those features can be easily discerned with a little effort.

When I configure my defenses, I care very little about the opinions of a
domain owner, because I don't work for them.I am very interested in
knowing whether a message is authenticated or not, because an
authenticated message is judged to be free of identifier impersonation
risk.  If the message is authenticated, why do I need the domain owner's
opinion about whether the message MUST be authenticated?If the message
is not authenticated, I still don't care very much about the domain
owner's opinion, I care about whether the message should be delivered to
the user or not.   Since I expect authentication failure to include false
positives, the only way to settle the matter is to get more information, by
investigating why it failed authentication and whether that particular
message is acceptable to my organization or not.  This works because I
don't think that every message is unique.   I think attackers are
identifiable but their attack methods will vary, so the faster that I get
them block-listed, the easier my life will be.   And it works.

If you follow the spec, you get DMARC results on maybe 40% of your
messages, and you only consider a failure result as definitive on the 10%
or less that request enforcement.  Then a subset of that 10% is bad
advice.  If you instead look at the messages which produce DMARC PASS, you
have results on at least 80% of all messages.   Then you can start asking
the right question:   How can I do better triage on the 20%?   The answers
are pretty straightforward once you start seeing the data.   It does not
require the magic of content filtering, it just requires the right
framework and human judgement.  The framework is easily defined.

But since I am the only one who thinks the RFC 7489 and DMARCbis scope is
wrong, we should move this off-line.   I had already promised to go away,
but then I felt Barry misrepresented my perspective, and then you responded
to the group twice.

Doug Foster

On Sun, Sep 17, 2023 at 6:20 PM Murray S. Kucherawy 
wrote:

> On Sun, Sep 17, 2023 at 2:47 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> We have established that the normative implementation of DMARC is
>> (unfortunately) a fully-automated solution which implements RFC 7489
>> exactly and nothing more.
>>
>
> Sure, but why would you do that, especially in the presence of all of the
> context that's come to light since March 2015?
>
> Given the language in Section 6.7 of RFC 7489, I find your statement
> confusing.  That section goes to some lengths to lead the reader to the
> conclusion that there are going to be false positives and false negatives,
> and that DMARC should be one input to a larger policy decision.  How, then,
> could an operator that implements DMARC and nothing else claim to be fully
> compliant?
>
> DMARC's brilliance was the use of an authenticated identifier to provide
>> proxy verification of another identifier.   It is the identifiers that
>> provide the authentication, not the policy.   The policy influences only
>> the strictness of the alignment rule.  This means that any message with
>> strict alignment on SPF PASS or DKIM PASS is DMARC authenticated, with or
>> without a policy.   "No result" in this situation is the result of a
>> choice, but not a necessary one, and not one that is easily justified.
>>
>
> I'm not following here either.  The fourth sentence contradicts RFC 7489.
> The absence of a policy is all the justification you need to say it's "no
> result" rather than "authenticated"; you're otherwise willingly discarding
> the fact that the RFC5322.From domain's owner has either neglected or
> deliberately omitted to publish a policy, which may itself be a useful
> signal (and Section 6 talks about this).
>
> For those who have implemented to the specification, "No Result" means
>> "Content 

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-17 Thread Murray S. Kucherawy
On Sun, Sep 17, 2023 at 2:47 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> We have established that the normative implementation of DMARC is
> (unfortunately) a fully-automated solution which implements RFC 7489
> exactly and nothing more.
>

Sure, but why would you do that, especially in the presence of all of the
context that's come to light since March 2015?

Given the language in Section 6.7 of RFC 7489, I find your statement
confusing.  That section goes to some lengths to lead the reader to the
conclusion that there are going to be false positives and false negatives,
and that DMARC should be one input to a larger policy decision.  How, then,
could an operator that implements DMARC and nothing else claim to be fully
compliant?

DMARC's brilliance was the use of an authenticated identifier to provide
> proxy verification of another identifier.   It is the identifiers that
> provide the authentication, not the policy.   The policy influences only
> the strictness of the alignment rule.  This means that any message with
> strict alignment on SPF PASS or DKIM PASS is DMARC authenticated, with or
> without a policy.   "No result" in this situation is the result of a
> choice, but not a necessary one, and not one that is easily justified.
>

I'm not following here either.  The fourth sentence contradicts RFC 7489.
The absence of a policy is all the justification you need to say it's "no
result" rather than "authenticated"; you're otherwise willingly discarding
the fact that the RFC5322.From domain's owner has either neglected or
deliberately omitted to publish a policy, which may itself be a useful
signal (and Section 6 talks about this).

For those who have implemented to the specification, "No Result" means
> "Content Filtering must carry the whole load," which it cannot do.   So I
> reject the notion that "No Result" is harmless.
>

This appears to be an assertion that everyone should be advertising a
policy.  That's different from asserting that all receivers should infer a
policy where none is advertised.  The outcomes are very different.

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-17 Thread Douglas Foster
We have established that the normative implementation of DMARC is
(unfortunately) a fully-automated solution which implements RFC 7489
exactly and nothing more.   These implementations block unconditionally on
Fail with Reject, and have minimal effect on disposition otherwise.   With
any level of intelligent disposition auditing, we would not have the
mailing list problem.

DMARC's brilliance was the use of an authenticated identifier to provide
proxy verification of another identifier.   It is the identifiers that
provide the authentication, not the policy.   The policy influences only
the strictness of the alignment rule.  This means that any message with
strict alignment on SPF PASS or DKIM PASS is DMARC authenticated, with or
without a policy.   "No result" in this situation is the result of a
choice, but not a necessary one, and not one that is easily justified.

For those who have implemented to the specification, "No Result" means
"Content Filtering must carry the whole load," which it cannot do.   So I
reject the notion that "No Result" is harmless.

Doug Foster



On Sun, Sep 17, 2023 at 5:29 PM Murray S. Kucherawy 
wrote:

> On Sun, Sep 17, 2023 at 11:04 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> You misunderstsnd my position.  I don't expect a world where perfect
>> information is dropped in my lap without any effort on my part.  Not now,
>> not ever.
>>
>> I have determined, by measurement, that unauthenticated mail is a much
>> smaller percentage of all mail than one might expect.  This makes
>> inspection of unauthenticated mail both feasible and productive.
>>
>> But DMARC hinders this discovery by pretending that mail can only be
>> authenticated if a policy is found.
>>
>
> There's no assertion by DMARC of the nature you're describing.
> Specifically, when no policy is found, there is no DMARC outcome to be
> considered; a receiver must rely on other metrics or heuristics to make its
> handling decisions.
>
> I don't see that as a hindrance; I see it as merely outside of the scope
> of what DMARC intends (or is able) to solve.
>
>
>> Investigation wil prevent unwanted blocks while exposing a lot of
>> unwanted traffic.  Evaluators who are unwilling to make the effort to
>> investigate are taking unnecesary risks which are likely to hurt them,
>> sooner or later.
>>
>
> This sounds like it might be sage advice, but it exceeds the scope of
> DMARC (or DKIM, or SPF, or ARC).
>
> -MSK, p11g
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-17 Thread Murray S. Kucherawy
On Sun, Sep 17, 2023 at 11:04 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> You misunderstsnd my position.  I don't expect a world where perfect
> information is dropped in my lap without any effort on my part.  Not now,
> not ever.
>
> I have determined, by measurement, that unauthenticated mail is a much
> smaller percentage of all mail than one might expect.  This makes
> inspection of unauthenticated mail both feasible and productive.
>
> But DMARC hinders this discovery by pretending that mail can only be
> authenticated if a policy is found.
>

There's no assertion by DMARC of the nature you're describing.
Specifically, when no policy is found, there is no DMARC outcome to be
considered; a receiver must rely on other metrics or heuristics to make its
handling decisions.

I don't see that as a hindrance; I see it as merely outside of the scope of
what DMARC intends (or is able) to solve.


> Investigation wil prevent unwanted blocks while exposing a lot of unwanted
> traffic.  Evaluators who are unwilling to make the effort to investigate
> are taking unnecesary risks which are likely to hurt them, sooner or later.
>

This sounds like it might be sage advice, but it exceeds the scope of DMARC
(or DKIM, or SPF, or ARC).

-MSK, p11g
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-17 Thread Douglas Foster
You misunderstsnd my position.  I don't expect a world where perfect
information is dropped in my lap without any effort on my part.  Not now,
not ever.

I have determined, by measurement, that unauthenticated mail is a much
smaller percentage of all mail than one might expect.  This makes
inspection of unauthenticated mail both feasible and productive.

But DMARC hinders this discovery by pretending that mail can only be
authenticated if a policy is found.

 Investigation wil prevent unwanted blocks while exposing a lot of unwanted
traffic.  Evaluators who are unwilling to make the effort to investigate
are taking unnecesary risks which are likely to hurt them, sooner or later.

Doug


On Sat, Sep 16, 2023, 11:18 PM Barry Leiba  wrote:

> I believe, with you, that there's likely to be a time when
> unauthenticated mail simply will not be delivered by most receiving
> domains.  I similarly believe (as the owner of a Tesla) that there
> will be a time when cars will be self-driving in the vast majority,
> and that that will make the roads both safer and more efficient.
>
> Neither of those situations is here yet, though, and neither is likely
> to arrive very soon.  Some day, yes.  Not yet, and not soon.
>
> While we can certainly discuss the former -- particularly with a focus
> on what needs to happen before that situation can be realised -- we
> need to first make sure that we resolve the few remaining issues in
> the DMARCbis and reporting documents and get them published.
>
> Barry
>
> On Sat, Sep 16, 2023 at 6:56 AM Douglas Foster
>  wrote:
> >
> > Yes, I suspected awhile back that I was the only one in the world
> implementing mandatory authentication.   This group has confirmed it.
> >
> > But I hold out hope thst others will see the opportunity that it
> provides.  Perhaps someone will read my Best Practices draft and sponsor it
> as an individual contribution or experimental draft.
> >
> > Doug
> >
> >
> > On Fri, Sep 15, 2023, 9:26 AM Barry Leiba 
> wrote:
> >>
> >> > Content filtering creates a need for whitelisting
> >> > Any domain may require whitelisting, regardless of sender policy.
> >> > Whitelisting is only safe if it is coupled with an authentication
> mechanism which prevents impersonation.
> >> > Therefore, sender authentication, by a combination of local policy
> and sender policy, needs to be defined for all possible messages.
> >>
> >> The last statement there is where things go off the rails.  No,
> >> nothing has to work perfectly here, and mechanisms are useful and can
> >> well be standardized even when they don't work in "all possible"
> >> situations.
> >>
> >> It's really important that we stop insisting on perfection or nothing,
> >> as that's a false dichotomy.  What we have now is demonstrably useful
> >> as *part of* an overall system.  We need to move forward with
> >> finishing the document.
> >>
> >> Barry
> >
> > ___
> > 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] Some Gmail comments on DMARCbis version 28

2023-09-16 Thread Barry Leiba
I believe, with you, that there's likely to be a time when
unauthenticated mail simply will not be delivered by most receiving
domains.  I similarly believe (as the owner of a Tesla) that there
will be a time when cars will be self-driving in the vast majority,
and that that will make the roads both safer and more efficient.

Neither of those situations is here yet, though, and neither is likely
to arrive very soon.  Some day, yes.  Not yet, and not soon.

While we can certainly discuss the former -- particularly with a focus
on what needs to happen before that situation can be realised -- we
need to first make sure that we resolve the few remaining issues in
the DMARCbis and reporting documents and get them published.

Barry

On Sat, Sep 16, 2023 at 6:56 AM Douglas Foster
 wrote:
>
> Yes, I suspected awhile back that I was the only one in the world 
> implementing mandatory authentication.   This group has confirmed it.
>
> But I hold out hope thst others will see the opportunity that it provides.  
> Perhaps someone will read my Best Practices draft and sponsor it as an 
> individual contribution or experimental draft.
>
> Doug
>
>
> On Fri, Sep 15, 2023, 9:26 AM Barry Leiba  wrote:
>>
>> > Content filtering creates a need for whitelisting
>> > Any domain may require whitelisting, regardless of sender policy.
>> > Whitelisting is only safe if it is coupled with an authentication 
>> > mechanism which prevents impersonation.
>> > Therefore, sender authentication, by a combination of local policy and 
>> > sender policy, needs to be defined for all possible messages.
>>
>> The last statement there is where things go off the rails.  No,
>> nothing has to work perfectly here, and mechanisms are useful and can
>> well be standardized even when they don't work in "all possible"
>> situations.
>>
>> It's really important that we stop insisting on perfection or nothing,
>> as that's a false dichotomy.  What we have now is demonstrably useful
>> as *part of* an overall system.  We need to move forward with
>> finishing the document.
>>
>> Barry
>
> ___
> 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] Some Gmail comments on DMARCbis version 28

2023-09-16 Thread Douglas Foster
Yes, I suspected awhile back that I was the only one in the world
implementing mandatory authentication.   This group has confirmed it.

But I hold out hope thst others will see the opportunity that it provides.
Perhaps someone will read my Best Practices draft and sponsor it as an
individual contribution or experimental draft.

Doug


On Fri, Sep 15, 2023, 9:26 AM Barry Leiba  wrote:

> > Content filtering creates a need for whitelisting
> > Any domain may require whitelisting, regardless of sender policy.
> > Whitelisting is only safe if it is coupled with an authentication
> mechanism which prevents impersonation.
> > Therefore, sender authentication, by a combination of local policy and
> sender policy, needs to be defined for all possible messages.
>
> The last statement there is where things go off the rails.  No,
> nothing has to work perfectly here, and mechanisms are useful and can
> well be standardized even when they don't work in "all possible"
> situations.
>
> It's really important that we stop insisting on perfection or nothing,
> as that's a false dichotomy.  What we have now is demonstrably useful
> as *part of* an overall system.  We need to move forward with
> finishing the document.
>
> Barry
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-15 Thread Barry Leiba
> Content filtering creates a need for whitelisting
> Any domain may require whitelisting, regardless of sender policy.
> Whitelisting is only safe if it is coupled with an authentication mechanism 
> which prevents impersonation.
> Therefore, sender authentication, by a combination of local policy and sender 
> policy, needs to be defined for all possible messages.

The last statement there is where things go off the rails.  No,
nothing has to work perfectly here, and mechanisms are useful and can
well be standardized even when they don't work in "all possible"
situations.

It's really important that we stop insisting on perfection or nothing,
as that's a false dichotomy.  What we have now is demonstrably useful
as *part of* an overall system.  We need to move forward with
finishing the document.

Barry

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-15 Thread Douglas Foster
Glad you are seeing DMARC benefits.  I suggest a full set of management
statistics should be based on 100 of messages, and include:

% blocked by reputation
% blocked by DMARC Fail+Reject
% Authenticated by DMARC
% Authenticated by local policy
% Not authenticated

"Not Authenticated" is an interim result that begs for review.  As you work
the Not Authenticated pool, senders will migrate to "blocked by reputation"
or "authenticated by local policy"   The review process will expose both
unwanted impersonators and unwanted non-impersonators, with both moving
into the "blocked by reputation" bucket.  The Not Authenticated number
should decrease steadily and can move into the high 90% range pretty
quickly.

"Blocked by DMARC Fail+Reject" is also an interim result that should
converge toward zeros.   Malicious senders should move to "blocked by
reputation" and acceptable sources such as mailing lists should move to
"Authenticated by Local Policy".

Similarly, reviews of content filtering should move malicious senders into
the "blocked by reputation" bucket, and may move some senders into a
whitelist.   Over time, the percentage of messages blocked by content
filtering should decrease, because both sender authentication and content
filtering are converting blocked messages into blocked senders.  The
statistic will reverse direction when new content filtering strategies
expose previously-undetected malicious senders.

Doug Foster


On Wed, Sep 13, 2023, 9:32 PM Richard Clayton 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> In message  czy...@mail.gmail.com>, Douglas Foster  com> writes
>
> >The coverage problem is aggravated if we assume rational attackers.
> >  With a plethora of domains available for impersonation, attackers
> >are least likely to use domains that are protected with p=reject.
>
> you have grasped it ... the rational attackers do not impersonate the
> protected domains, and the irrational attackers are blocked when they
> do; hence the domain is protected and users are not misled
>
> >Therefore the reference model implementation protects an evaluator
> >where attacks are least likely, and fails to protect an evaluator
> >where attacks are most likely.
>
> however DMARC protects end users who might act on emails that were
> spoofed to be from the domain that has been protected
>
> Ian Levy (then of NCSC here in the UK) in "Active Cyber Defence - One
> Year On" reported
>
>  We have seen the number of messages spoofed from an @gov.uk address
>  (for example, taxref...@gov.uk) fall consistently over 2017,
>  suggesting that criminals are moving away from using them as fewer
>  and fewer of them are delivered to end users.
>
>  Across the 555 public sector email domains reporting to Mail Check,
>  we are seeing an average of 44.1 million messages a month which
>  fail verification, with a peak of 78.8 million in June. Of those,
>  an average of 4.5 million are not delivered to the end users. The
>  peak in June saw 30.3 million spoofed messages not delivered to end
>  users.
>
> from which you will see that there are were a number of irrational
> attackers, but that the rational ones now found their task harder
>
> - --
> richard   Richard Clayton
>
> Those who would give up essential Liberty, to purchase a little temporary
> Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755
>
> -BEGIN PGP SIGNATURE-
> Version: PGPsdk version 1.7.1
>
> iQA/AwUBZQJiO92nQQHFxEViEQIQ/wCg3bMOOkwzlALOCiqSeyYat37sLPsAoMmY
> PQmhq6x7U/NYsa9/qa0geqQO
> =cwUs
> -END PGP SIGNATURE-
>
> ___
> 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] Some Gmail comments on DMARCbis version 28

2023-09-15 Thread Douglas Foster
No. Realistically, this is the last document likely to come out of this
group on this subject.   So I am no sure to publish it unless it fixes the
coverage problem.

To state the coverage problem another way:

   - Content filtering creates a need for whitelisting
   - Any domain may require whitelisting, regardless of sender policy.
   - Whitelisting is only safe if it is coupled with an authentication
   mechanism which prevents impersonation.
   - Therefore, sender authentication, by a combination of local policy and
   sender policy, needs to be defined for all possible messages.


Doug Foster

On Fri, Sep 15, 2023 at 7:23 AM Alessandro Vesely  wrote:

> On Thu 14/Sep/2023 16:39:49 +0200 Murray S. Kucherawy wrote:
> > On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster wrote:
> >
> >> Our assumed reference model is a fully automated, by-the-spec
> >> implementation of RFC 7489.   In particular, this means that:
> >> - when p=none, unauthenticated messages are never obstructed, for fear
> of hindering a wanted message
> >> - when p=reject, unauthenticated messages are never allowed, in the
> blind faith that such messages are always unwanted
> >> - when p=quarantine, automation will break down, so the policy is
> recategorized as either none or reject.
> >>
> >> This raises a coverage problem.   A huge volume of traffic will not be
> >> protected by Sender Authentication, so the evaluator becomes entirely
> >> dependent upon content filtering to protect himself from attacks that
> >> impersonate unprotected domains.  In the unlikely case that a content
> >> filtering implementation is sufficient for non-DMARC domains, it is
> likely
> >> to be sufficient for DMARC domains also, making DMARC unnecessary.
> >
> > I don't follow the logic here.  Both the DMARC verdict about a message
> and
> > the result of content filtering are, as I understand it, typically
> weighted
> > inputs to a final disposition decision, even when that DMARC result is
> > effectively a shrug.
> >
> > If the underlying theme here is a need for ultimate determinism, I think
> by
> > now we've learned that's a fool's errand.  The decision machine is far
> too
> > complex, and making it comprehensive requires enormous investment that
> not
> > many operators can afford to make.
>
>
> I strongly object to that position.  The magic spell that content
> filtering
> provides is such a nuisance that many operators gave up and turned their
> service to giant providers, who are large enough to maintain a worldwide
> reputation system.  Domain based authentication was devised to provide an
> alternative, deterministic approach.
>
>
> >> [...]
> >>
> >> The problem is the reference model.  DMARC is not amenable or
> appropriate
> >> using a fully-automated implementation.
> >
> > I don't believe it has ever been claimed to be such, nor do I believe
> there
> > is an illusion that this is even possible.
>
>
> There is.  The much discussed Interoperability Considerations section
> clearly
> establishes that the "only" problems are mailing lists and forwarding.
> So, as
> we have an ARC protocol ready, and because it is the goal of both sides
> —ML and
> forwarders on one side, receivers on the other— to reliably deliver
> legitimate
> messages, it is enough to devise how to make them meet in order to make
> ARC
> work as intended.  I do believe it's possible.  Is it an illusion?  For
> sure,
> it is way easier than making content filtering reliable.
>
>
> > If the issue is that the document under development claims otherwise,
> > that's something that deserves attention.
>
>
> DMARCbis doesn't make that claim.  It quietly surmises it when it talks
> about
> authentication ecosystem becoming more mature, but it doesn't arrogate it.
>
> DMARC is just the reference model Doug described.  Its full payoff is
> p=reject,
> but it cannot be universally deployed for the time being.  This limitation
> has
> been made explicit.  The sooner we finalize the documents under
> development,
> the sooner we can turn to fix forwarding.  Trying to stuff extra problems
> into
> DMARCbis is counter-productive, as it actually delays tackling those
> problems.
>
>
> Best
> Ale
> --
>
>
>
>
>
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-15 Thread Alessandro Vesely

On Thu 14/Sep/2023 16:39:49 +0200 Murray S. Kucherawy wrote:

On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster wrote:

Our assumed reference model is a fully automated, by-the-spec 
implementation of RFC 7489.   In particular, this means that:

- when p=none, unauthenticated messages are never obstructed, for fear of 
hindering a wanted message
- when p=reject, unauthenticated messages are never allowed, in the blind faith 
that such messages are always unwanted
- when p=quarantine, automation will break down, so the policy is recategorized 
as either none or reject.

This raises a coverage problem.   A huge volume of traffic will not be 
protected by Sender Authentication, so the evaluator becomes entirely 
dependent upon content filtering to protect himself from attacks that 
impersonate unprotected domains.  In the unlikely case that a content 
filtering implementation is sufficient for non-DMARC domains, it is likely 
to be sufficient for DMARC domains also, making DMARC unnecessary.


I don't follow the logic here.  Both the DMARC verdict about a message and 
the result of content filtering are, as I understand it, typically weighted 
inputs to a final disposition decision, even when that DMARC result is 
effectively a shrug.


If the underlying theme here is a need for ultimate determinism, I think by 
now we've learned that's a fool's errand.  The decision machine is far too 
complex, and making it comprehensive requires enormous investment that not 
many operators can afford to make.



I strongly object to that position.  The magic spell that content filtering 
provides is such a nuisance that many operators gave up and turned their 
service to giant providers, who are large enough to maintain a worldwide 
reputation system.  Domain based authentication was devised to provide an 
alternative, deterministic approach.




[...]

The problem is the reference model.  DMARC is not amenable or appropriate 
using a fully-automated implementation.


I don't believe it has ever been claimed to be such, nor do I believe there 
is an illusion that this is even possible.



There is.  The much discussed Interoperability Considerations section clearly 
establishes that the "only" problems are mailing lists and forwarding.  So, as 
we have an ARC protocol ready, and because it is the goal of both sides —ML and 
forwarders on one side, receivers on the other— to reliably deliver legitimate 
messages, it is enough to devise how to make them meet in order to make ARC 
work as intended.  I do believe it's possible.  Is it an illusion?  For sure, 
it is way easier than making content filtering reliable.



If the issue is that the document under development claims otherwise, 
that's something that deserves attention.



DMARCbis doesn't make that claim.  It quietly surmises it when it talks about 
authentication ecosystem becoming more mature, but it doesn't arrogate it.


DMARC is just the reference model Doug described.  Its full payoff is p=reject, 
but it cannot be universally deployed for the time being.  This limitation has 
been made explicit.  The sooner we finalize the documents under development, 
the sooner we can turn to fix forwarding.  Trying to stuff extra problems into 
DMARCbis is counter-productive, as it actually delays tackling those problems.



Best
Ale
--





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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-14 Thread Scott Kitterman
On Thursday, September 14, 2023 5:27:08 PM EDT Wei Chuang wrote:
> On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman 
> 
> wrote:
> > On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
> > > We had an opportunity to further review the DMARCbis changes more
> > > broadly
> > > within Gmail.  While we don't see any blockers in the language in
> > 
> > DMARCbis
> > 
> > > version 28
> > >  and
> > > can live with what is there, we wanted to briefly raise some concerns
> > > around some of the changes.  Two points.
> > > 
> > > Regarding the languages in section 8.6 "It is therefore critical that
> > > domains that host users who might post messages to mailing lists SHOULD
> > 
> > NOT
> > 
> > > publish p=reject.  Domains that choose to publish p=reject SHOULD
> > 
> > implement
> > 
> > > policies that their users not post to Internet mailing lists", we wanted
> > 
> > to
> > 
> > > point out that this is impossible to implement.  Many enterprises
> > > already
> > > have "p=reject" policies.  Presumably those domains were subject to some
> > > sort of spoofing which is why they went to such a strict policy.  It
> > 
> > would
> > 
> > > be unreasonable to tell them to stop posting to mailing lists as many
> > > likely already use mailing list services and will want to continue to
> > > use
> > > them.  The one thing that makes this tractable is the SHOULD language as
> > 
> > we
> > 
> > > may choose not to not follow this aspect of the specification.  Our
> > > suggestion is that there is not a lot of value in including this
> > > language
> > > in the bis document if the likely outcome is that it will be ignored,
> > > and
> > > rather more effort should be placed with a technical solution for
> > > interop
> > > with mailing lists.
> > 
> > It might be helpful if you could describe this technical solution from
> > your
> > perspective.
> > 
> > If there were a reasonable technical solution available, I think this
> > would be
> > a much easier change to support (in my opinion, and a believe a
> > substantial
> > number of others, rewriting From is not a reasonable technical solution).
> > 
> > Scott K
> 
> Apologies for the delay in getting back to this.
> 
> So yes I believe there are two possible technical approaches broadly
> speaking 1) Support rewriting From and being able to reverse it along with
> message modifications to recover the original DKIM message hash to validate
> the original DKIM signature.  2) Create a new message authentication method
> that is tolerant of message modifications and message forwarding, and
> supported by DMARC.  From header rewriting would not be necessary in this
> scenario.  Beyond the complexity of supporting either method, another
> tricky thing in both cases is supporting an ecosystem with diverse adoption
> of said technique.  More concrete proposals for 1) and 2) are 1)
> draft-chuang-mailing-list-modifications
> 
> and 2) draft-chuang-replay-resistant-arc.  And there are other I-Ds out
> there particularly for the first approach.
> 
> -Wei

Thanks.  That's helpful.

I interpret that as confirming my view that there is not currently a reasonable 
technical solution available.  While these may be promising for the future, 
it's not like any of those solutions are things that are currently available 
to email list administrators.

I don't think any of those things are going to mature quickly, so I would find 
it concerning to delay publication of DMARCbis until they are ready.  If we 
aren't going to put DMARCbis on ice for a few years (please, let's not), then 
I think we're left with something like the language that's there now or some 
variation of NOT RECOMMENDED unless [unobtainium] which amounts to the same 
thing, but is in my view less clear.

I think in a couple of years we could do some kind of an update that relaxes 
the current language based on one of these techniques if they become 
deployable, but I don't think we can do it now.

Scott K



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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-14 Thread Wei Chuang
On Sun, Sep 10, 2023 at 11:34 AM Scott Kitterman 
wrote:

> On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
> > We had an opportunity to further review the DMARCbis changes more broadly
> > within Gmail.  While we don't see any blockers in the language in
> DMARCbis
> > version 28
> >  and
> > can live with what is there, we wanted to briefly raise some concerns
> > around some of the changes.  Two points.
> >
> > Regarding the languages in section 8.6 "It is therefore critical that
> > domains that host users who might post messages to mailing lists SHOULD
> NOT
> > publish p=reject.  Domains that choose to publish p=reject SHOULD
> implement
> > policies that their users not post to Internet mailing lists", we wanted
> to
> > point out that this is impossible to implement.  Many enterprises already
> > have "p=reject" policies.  Presumably those domains were subject to some
> > sort of spoofing which is why they went to such a strict policy.  It
> would
> > be unreasonable to tell them to stop posting to mailing lists as many
> > likely already use mailing list services and will want to continue to use
> > them.  The one thing that makes this tractable is the SHOULD language as
> we
> > may choose not to not follow this aspect of the specification.  Our
> > suggestion is that there is not a lot of value in including this language
> > in the bis document if the likely outcome is that it will be ignored, and
> > rather more effort should be placed with a technical solution for interop
> > with mailing lists.
>
> It might be helpful if you could describe this technical solution from
> your
> perspective.
>
> If there were a reasonable technical solution available, I think this
> would be
> a much easier change to support (in my opinion, and a believe a
> substantial
> number of others, rewriting From is not a reasonable technical solution).
>
> Scott K
>

Apologies for the delay in getting back to this.

So yes I believe there are two possible technical approaches broadly
speaking 1) Support rewriting From and being able to reverse it along with
message modifications to recover the original DKIM message hash to validate
the original DKIM signature.  2) Create a new message authentication method
that is tolerant of message modifications and message forwarding, and
supported by DMARC.  From header rewriting would not be necessary in this
scenario.  Beyond the complexity of supporting either method, another
tricky thing in both cases is supporting an ecosystem with diverse adoption
of said technique.  More concrete proposals for 1) and 2) are 1)
draft-chuang-mailing-list-modifications
 and
2) draft-chuang-replay-resistant-arc.  And there are other I-Ds out there
particularly for the first approach.

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-14 Thread Hector Santos
> On Sep 14, 2023, at 10:39 AM, Murray S. Kucherawy  wrote:
> 
> On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster 
>  > wrote:
>> 
>> The coverage problem is aggravated if we assume rational attackers.   With a 
>> plethora of domains available for impersonation, attackers are least likely 
>> to use domains that are protected with p=reject.  Therefore the reference 
>> model implementation protects an evaluator where attacks are least likely, 
>> and fails to protect an evaluator where attacks are most likely.
> 
> So you're saying DMARC fails to protect domains that don't set "p=reject"?  
> That claim has the appearance of a tautology.
> 


Firs, I agree with your thoughts here.

I always considered these new DNS-based Apps that offered policies, their 
highest payoff is the most restrictive policy, the partials policies like SPF 
soft fail or unknown policies or DMARD p=none policies is technically overhead 
and redundancy if every query is always a “well I don’t know” do what you wish. 
 DNS and processing overhead.

The highest payoff for SPF is -ALL and then highest payoff for DMARC is 
p=reject despite its faulty authorization or restrictive algorithm,

All the best,
Hector Santos

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-14 Thread Hector Santos
> On Sep 14, 2023, at 7:36 AM, Dotzero  wrote:
> 
> On Wed, Sep 13, 2023 at 9:21 PM Hector Santos  > wrote:
>> 
>>> On Sep 13, 2023, at 8:51 PM, Dotzero >> > wrote:
>>> 
>>> DMARC does one thing and one thing only. It mitigates against direct domain 
>>> abuse in a deterministic manner, nothing else. It doesn't stop spam and it 
>>> doesn't depend on or involve reputation. It is but one tool among a number 
>>> of tools that various parties can choose from. A message passing DMARC 
>>> validation does not mean the message is "good". There is no question of 
>>> fault. Perhaps you should recommend changes to incorporate a blame game if 
>>> your goal is to determine fault. 
>> 
>> Deterministic means there is no question -  you follow the protocol. Your 
>> (speaking in general) opinions don’t matter. 
> 
> It means that the output of the algorithm is deterministic. It does not mean 
> that the receiver blindly act on that output. As has been stated many times 
> by many people, a policy assertion is a request by the sending domain 
> administrator/owner, not a mandate. That is why local policy on the part of 
> the receiver overrides a sender policy assertion.
> 


Over the years, as a supporter of SPF and DKIM Policy, and being the DSAP's 
author, I've witnessed how deterministic protocols like SSP, DSAP, ADSP, and 
DMARC pave the way for policy-driven rejections. They operate without 
subjectivity. But the inclusion of local policies can lead to diverse behaviors 
among platforms. While Site A might conform strictly to a policy, Site B might 
diverge.

The introduction of RFC 5016, Section 5.3, Item 10 underlines the primacy of 
local policies. This was especially pertinent for Mailing List systems, which 
often tampered with the original DKIM author's signature integrity. These 
systems then re-signed the altered message for list distribution as a 3rd 
party. At that time, a gap existed as we lacked a deterministic policy catering 
to these 3rd parties, which could work alongside SSP,  ADSP and now DMARC's 1st 
party only signer algorithm.

DMARC has amplified the significance of local policies, given the high 
likelihood of false positives. The introduction of local policies has somewhat 
diluted the effectiveness of deterministic protocols. We're still navigating 
these nuances, even after 15+ years.

All the best,
Hector Santos



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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-14 Thread Murray S. Kucherawy
On Wed, Sep 13, 2023 at 6:01 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Let's analyze the problem Jim raises, using it to answer Hector's question
> about where responsibility lies.
>
> Our assumed reference model is a fully automated, by-the-spec
> implementation of RFC 7489.   In particular, this means that:
> - when p=none, unauthenticated messages are never obstructed, for fear of
> hindering a wanted message
> - when p=reject, unauthenticated messages are never allowed, in the blind
> faith that such messages are always unwanted
> - when p=quarantine, automation will break down, so the policy is
> recategorized as either none or reject.
>
> This raises a coverage problem.   A huge volume of traffic will not be
> protected by Sender Authentication, so the evaluator becomes entierly
> dependent upon content filtering to protect himself from attacks that
> impersonate unprotected domains.  In the unlikely case that a content
> filtering implementation is sufficient for non-DMARC domains, it is likely
> to be sufficient for DMARC domains also, making DMARC unnecessary.
>

I don't follow the logic here.  Both the DMARC verdict about a message and
the result of content filtering are, as I understand it, typically weighted
inputs to a final disposition decision, even when that DMARC result is
effectively a shrug.

If the underlying theme here is a need for ultimate determinism, I think by
now we've learned that's a fool's errand.  The decision machine is far too
complex, and making it comprehensive requires enormous investment that not
many operators can afford to make.

The coverage problem is aggravated if we assume rational attackers.   With
> a plethora of domains available for impersonation, attackers are least
> likely to use domains that are protected with p=reject.  Therefore the
> reference model implementation protects an evaluator where attacks are
> least likely, and fails to protect an evaluator where attacks are most
> likely.
>

So you're saying DMARC fails to protect domains that don't set "p=reject"?
That claim has the appearance of a tautology.

The problem is the reference model.  DMARC is not amenable or appropriate
> using a fully-automated implementation.
>

I don't believe it has ever been claimed to be such, nor do I believe there
is an illusion that this is even possible.

If the issue is that the document under development claims otherwise,
that's something that deserves attention.


> Domain owner policies of "p=none" or "no policy" SHOULD NOT cause the
> evaluator to ignore Sender Authentication considerations.
>

Does any document, published or under development, assert otherwise?


> Since any unauthenticated message carries risk of an impersonation attack,
> regardless of DMARC policy, every unauthenticated message should be
> assessed for impersonation risk.
>

Certainly, but haven't we already established this?

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-14 Thread Dotzero
On Wed, Sep 13, 2023 at 9:01 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> Let's analyze the problem Jim raises, using it to answer Hector's question
> about where responsibility lies.
>
> Our assumed reference model is a fully automated, by-the-spec
> implementation of RFC 7489.   In particular, this means that:
> - when p=none, unauthenticated messages are never obstructed, for fear of
> hindering a wanted message
>

I do not see the word "fear" anywhere in the specification.  When p=none,
the sending domain is not asking the receiving domain to do anything but
report the observed results of validation, assuming that a report receiving
address(s) is provided.

- when p=reject, unauthenticated messages are never allowed, in the blind
> faith that such messages are always unwanted
> - when p=quarantine, automation will break down, so the policy is
> recategorized as either none or reject.
>
> This raises a coverage problem.
>

Not really.


> A huge volume of traffic will not be protected by Sender Authentication,
> so the evaluator becomes entierly dependent upon content filtering to
> protect himself from attacks that impersonate unprotected domains.
>

By your logic, all sending domains should be forced to implement DMARC
p=reject. Nothing is further from the truth. A domain may choose to only
publish only an SPF record. A domain may choose to only use DKIM. A domain
may choose to implement DMARC. A domain may choose to implement none of
these. A domain may choose to only emit PGP signed messages. A domain may
choose to use S/MIME signing. Note that NONE OF THESE approaches offers
universal or even majority coverage of the global messaging corpus.

In the unlikely case that a content filtering implementation is sufficient
> for non-DMARC domains, it is likely to be sufficient for DMARC domains
> also, making DMARC unnecessary.
>

One need only look at spam folders to see that content filtering to see
that it does not provide a comprehensive solution. By your logic above,
perhaps we should jettison content filtering as a tool.

>
> The coverage problem is aggravated if we assume rational attackers.   With
> a plethora of domains available for impersonation, attackers are least
> likely to use domains that are protected with p=reject.  Therefore the
> reference model implementation protects an evaluator where attacks are
> least likely, and fails to protect an evaluator where attacks are most
> likely.
>

Again, you are asserting a "coverage problem" when none exists. If a
sending domain chooses not to participate in DMARC, that is a choice on
their part, not a problem. If a receiving domain chooses not to validate,
that is a choice, not a problem. Again, applying your logic as expressed
above, should we discard SMTP based messaging because organizations choose
to use other forms of messaging for their communications?


>
> Now consider the mailing list problem.
>
> The mailing list owner should assume that all evaluators will enforce
> DMARC according to the reference model, regardless of the receiving
> domain's published DMARC policy.   This means that every subscribing domain
> SHOULD create a DMARC exception for traffic coming from the list's MAILFROM
> address.
>

This does NOT mean that every subscribing domain should create an exception
for traffic coming from the list's MAILFROM address.


> However, we assume that this does not happen for one of these reasons:
> (a) the list owner does not ask for the exception,
> (b) the subscriber fails to forward the exception request,
> (c) the email system administrator refuses the request, or
> (d) the email filtering system provides no mechanism to implement the
> request.
>
> Then subscribers join from one or more domains with p=reject policy, and
> the problems start.   When a subscriber gets disenrolled because his domain
> enforces DMARC without exceptions, he screams at the mailing list operator,
> who then points his finger at the p=reject domain.  Alternatively, the
> domain gets munged and the subscribers fuss for that reason instead.  Faced
> with this peer pressure, the p=reject subscriber complains loudly to his
> mail system administrator.   In the hoped-for-case, the domain owner caves
> under this internal pressure and changes his DMARC policy to p=none.  One
> of the odd things about this result is that the characteristics of the
> incoming messages remain unchanged.  Instead, it is the risk tolerance that
> has been increased.
>

A list owner may choose not to accept subscriptions/messages from a domain
participating in DMARC and publishing p=reject.

>
> In the simpler solution, subscribers would accept impersonation from one
> account in one domain, so that both subscriber and non-subscriber domains
> are protected from impersonation attacks using the p=reject domain from any
> other source.   In the hoped-for solution, all Internet participants become
> vulnerable to impersonation attacks using the no-longer-reject 

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-14 Thread Dotzero
On Wed, Sep 13, 2023 at 9:21 PM Hector Santos  wrote:

>
> All the best,
> Hector Santos
>
>
>
> On Sep 13, 2023, at 8:51 PM, Dotzero  wrote:
>
>
>
> On Wed, Sep 13, 2023 at 5:28 PM Hector Santos  wrote:
>
>> On Sep 11, 2023, at 9:24 AM, Dotzero  chastised
>> Douglas Foster
>>
>> Absolutely incorrect. DMARC is a deterministic pass|fail approach based
>> on validation through DKIM or SPF pass (or if both pass). It says nothing
>> about the acceptability/goodness/badness of a source.
>>
>>
>> So why are we here?
>>
>
> Because you care?
>
>
> I do.
>
>
>> Correct or incorrect, a published p=reject has to mean something to the
>> verifier who is doing the domain a favor by a) implementing the protocol
>> and b) the goal of eliminating junk.   If there are false negatives, whose
>> fault is that?  The Domain, The Verifier or the Protocol?
>>
>
> DMARC does one thing and one thing only. It mitigates against direct
> domain abuse in a deterministic manner, nothing else. It doesn't stop spam
> and it doesn't depend on or involve reputation. It is but one tool among a
> number of tools that various parties can choose from. A message passing
> DMARC validation does not mean the message is "good". There is no question
> of fault. Perhaps you should recommend changes to incorporate a blame game
> if your goal is to determine fault.
>
>
> Deterministic means there is no question -  you follow the protocol. Your
> (speaking in general) opinions don’t matter.
>

It means that the output of the algorithm is deterministic. It does not
mean that the receiver blindly act on that output. As has been stated many
times by many people, a policy assertion is a request by the sending domain
administrator/owner, not a mandate. That is why local policy on the part of
the receiver overrides a sender policy assertion.

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-14 Thread Alessandro Vesely

On Sat 09/Sep/2023 20:16:04 +0200 Douglas Foster wrote:
Thus, if I get N messages from example.com , and the "pct" 
value is X, then the DMARC test is applied only to X% of that N; the simplest 
way to do this per-message would be to pick a random number between 0 and 1 and 
if it's greater than X%, the message simply bypasses DMARC altogether.



Drop "simplest":  /the way/ to do this is to pick up a random number between 0 
and 100 and if it's greater than X%, the message simply bypasses DMARC altogether.


My implementation:
if (vh.dmarc.pct != 100 && random() % 100 >= vh.dmarc.pct)
{
dispo = dispo_deliver;
if (parm->dyn.stats)
parm->dyn.stats->dmarc_reason = dmarc_reason_sampled_out;
...

See also:
https://en.wikipedia.org/wiki/Bernoulli_sampling

Best
Ale
--






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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-13 Thread Richard Clayton
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

In message , Douglas Foster  writes

>The coverage problem is aggravated if we assume rational attackers. 
>  With a plethora of domains available for impersonation, attackers 
>are least likely to use domains that are protected with p=reject.

you have grasped it ... the rational attackers do not impersonate the
protected domains, and the irrational attackers are blocked when they
do; hence the domain is protected and users are not misled

>Therefore the reference model implementation protects an evaluator 
>where attacks are least likely, and fails to protect an evaluator 
>where attacks are most likely.

however DMARC protects end users who might act on emails that were
spoofed to be from the domain that has been protected

Ian Levy (then of NCSC here in the UK) in "Active Cyber Defence - One
Year On" reported

 We have seen the number of messages spoofed from an @gov.uk address
 (for example, taxref...@gov.uk) fall consistently over 2017,
 suggesting that criminals are moving away from using them as fewer
 and fewer of them are delivered to end users.

 Across the 555 public sector email domains reporting to Mail Check,
 we are seeing an average of 44.1 million messages a month which
 fail verification, with a peak of 78.8 million in June. Of those,
 an average of 4.5 million are not delivered to the end users. The
 peak in June saw 30.3 million spoofed messages not delivered to end
 users.

from which you will see that there are were a number of irrational
attackers, but that the rational ones now found their task harder

- -- 
richard   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

-BEGIN PGP SIGNATURE-
Version: PGPsdk version 1.7.1

iQA/AwUBZQJiO92nQQHFxEViEQIQ/wCg3bMOOkwzlALOCiqSeyYat37sLPsAoMmY
PQmhq6x7U/NYsa9/qa0geqQO
=cwUs
-END PGP SIGNATURE-

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-13 Thread Hector Santos

All the best,
Hector Santos



> On Sep 13, 2023, at 8:51 PM, Dotzero  wrote:
> 
> 
> 
> On Wed, Sep 13, 2023 at 5:28 PM Hector Santos  > wrote:
>>> On Sep 11, 2023, at 9:24 AM, Dotzero >> > chastised Douglas Foster
>>> 
>>> Absolutely incorrect. DMARC is a deterministic pass|fail approach based on 
>>> validation through DKIM or SPF pass (or if both pass). It says nothing 
>>> about the acceptability/goodness/badness of a source. 
>> 
>> So why are we here?
> 
> Because you care? 

I do. 

>> 
>> Correct or incorrect, a published p=reject has to mean something to the 
>> verifier who is doing the domain a favor by a) implementing the protocol and 
>> b) the goal of eliminating junk.   If there are false negatives, whose fault 
>> is that?  The Domain, The Verifier or the Protocol?
> 
> DMARC does one thing and one thing only. It mitigates against direct domain 
> abuse in a deterministic manner, nothing else. It doesn't stop spam and it 
> doesn't depend on or involve reputation. It is but one tool among a number of 
> tools that various parties can choose from. A message passing DMARC 
> validation does not mean the message is "good". There is no question of 
> fault. Perhaps you should recommend changes to incorporate a blame game if 
> your goal is to determine fault. 

Deterministic means there is no question -  you follow the protocol. Your 
(speaking in general) opinions don’t matter. 

>> 
>> Please try to be more civil with people’s views or position with this 
>> problematic protocol.
> 
> Thank you for sharing your opinion. I'm truly and deeply sorrowful if I have 
> offended your sensibilities. I will consider including trigger warnings on 
> future posts. 

Share that with Douglas Foster.

>> 
>> Thanks
> 
> You are welcome.

My Pleasure.

—
HLS

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-13 Thread Douglas Foster
Let's analyze the problem Jim raises, using it to answer Hector's question
about where responsibility lies.

Our assumed reference model is a fully automated, by-the-spec
implementation of RFC 7489.   In particular, this means that:
- when p=none, unauthenticated messages are never obstructed, for fear of
hindering a wanted message
- when p=reject, unauthenticated messages are never allowed, in the blind
faith that such messages are always unwanted
- when p=quarantine, automation will break down, so the policy is
recategorized as either none or reject.

This raises a coverage problem.   A huge volume of traffic will not be
protected by Sender Authentication, so the evaluator becomes entierly
dependent upon content filtering to protect himself from attacks that
impersonate unprotected domains.  In the unlikely case that a content
filtering implementation is sufficient for non-DMARC domains, it is likely
to be sufficient for DMARC domains also, making DMARC unnecessary.

The coverage problem is aggravated if we assume rational attackers.   With
a plethora of domains available for impersonation, attackers are least
likely to use domains that are protected with p=reject.  Therefore the
reference model implementation protects an evaluator where attacks are
least likely, and fails to protect an evaluator where attacks are most
likely.

Now consider the mailing list problem.

The mailing list owner should assume that all evaluators will enforce DMARC
according to the reference model, regardless of the receiving domain's
published DMARC policy.   This means that every subscribing domain SHOULD
create a DMARC exception for traffic coming from the list's MAILFROM
address.   However, we assume that this does not happen for one of these
reasons:
(a) the list owner does not ask for the exception,
(b) the subscriber fails to forward the exception request,
(c) the email system administrator refuses the request, or
(d) the email filtering system provides no mechanism to implement the
request.

Then subscribers join from one or more domains with p=reject policy, and
the problems start.   When a subscriber gets disenrolled because his domain
enforces DMARC without exceptions, he screams at the mailing list operator,
who then points his finger at the p=reject domain.  Alternatively, the
domain gets munged and the subscribers fuss for that reason instead.  Faced
with this peer pressure, the p=reject subscriber complains loudly to his
mail system administrator.   In the hoped-for-case, the domain owner caves
under this internal pressure and changes his DMARC policy to p=none.  One
of the odd things about this result is that the characteristics of the
incoming messages remain unchanged.  Instead, it is the risk tolerance that
has been increased.

In the simpler solution, subscribers would accept impersonation from one
account in one domain, so that both subscriber and non-subscriber domains
are protected from impersonation attacks using the p=reject domain from any
other source.   In the hoped-for solution, all Internet participants become
vulnerable to impersonation attacks using the no-longer-reject domain.
However, everyone is already undefended against impersonation attacks using
an untold number of unprotected domains, so how much does it matter if a
few more domains are made available to the attacker?  Besides, evaluators
are responsible for being able to protect their networks using content
filtering only, so the change in DMARC policy is unimportant because DMARC
itself is not really important when implemented using the reference model.

The problem is the reference model.  DMARC is not amenable or appropriate
using a fully-automated implementation.  Domain owner policies of "p=none"
or "no policy" SHOULD NOT cause the evaluator to ignore Sender
Authentication considerations.  Since any unauthenticated message carries
risk of an impersonation attack, regardless of DMARC policy, every
unauthenticated message should be assessed for impersonation risk.

I keep raising issues that some consider out of scope because I want the
DMARC specification to actually help protect people from attacks.

Doug Foster

On Wed, Sep 13, 2023 at 5:29 PM Hector Santos  wrote:

> On Sep 11, 2023, at 9:24 AM, Dotzero  chastised
> Douglas Foster
>
> Absolutely incorrect. DMARC is a deterministic pass|fail approach based on
> validation through DKIM or SPF pass (or if both pass). It says nothing
> about the acceptability/goodness/badness of a source.
>
>
> So why are we here?
>
> Correct or incorrect, a published p=reject has to mean something to the
> verifier who is doing the domain a favor by a) implementing the protocol
> and b) the goal of eliminating junk.   If there are false negatives, whose
> fault is that?  The Domain, The Verifier or the Protocol?
>
> I think it’s the protocol but thats my opinion as one of early DKIM POLICY
> adopters and an advanced and costly implementation. If policy does not help
> protect a domain and also the 

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-13 Thread Dotzero
On Wed, Sep 13, 2023 at 5:28 PM Hector Santos  wrote:

> On Sep 11, 2023, at 9:24 AM, Dotzero  chastised
> Douglas Foster
>
> Absolutely incorrect. DMARC is a deterministic pass|fail approach based on
> validation through DKIM or SPF pass (or if both pass). It says nothing
> about the acceptability/goodness/badness of a source.
>
>
> So why are we here?
>

Because you care?

>
> Correct or incorrect, a published p=reject has to mean something to the
> verifier who is doing the domain a favor by a) implementing the protocol
> and b) the goal of eliminating junk.   If there are false negatives, whose
> fault is that?  The Domain, The Verifier or the Protocol?
>

DMARC does one thing and one thing only. It mitigates against direct domain
abuse in a deterministic manner, nothing else. It doesn't stop spam and it
doesn't depend on or involve reputation. It is but one tool among a number
of tools that various parties can choose from. A message passing DMARC
validation does not mean the message is "good". There is no question of
fault. Perhaps you should recommend changes to incorporate a blame game if
your goal is to determine fault.

>
> I think it’s the protocol but thats my opinion as one of early DKIM POLICY
> adopters and an advanced and costly implementation. If policy does not help
> protect a domain and also the receiver with failure hints or better said
> negative classification of a source per the domain policy, then what is the
> point of the work here or lack of there?
>

False negatives are generally the result of implementation choices of
senders. That's not an interoperability problem. It's a case of "Doctor, it
hurts when I do that". The correct response is "Don't do that."

Receivers are free to assign reputation, apply local policy as they see fit
but that all falls outside of DMARC.

>
> Same is true with SPF.
>
> Please try to be more civil with people’s views or position with this
> problematic protocol.
>

Thank you for sharing your opinion. I'm truly and deeply sorrowful if I
have offended your sensibilities. I will consider including trigger
warnings on future posts.

>
> Thanks
>

You are welcome.

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-13 Thread Hector Santos
> On Sep 11, 2023, at 9:24 AM, Dotzero  chastised Douglas 
> Foster
> 
> Absolutely incorrect. DMARC is a deterministic pass|fail approach based on 
> validation through DKIM or SPF pass (or if both pass). It says nothing about 
> the acceptability/goodness/badness of a source. 

So why are we here?

Correct or incorrect, a published p=reject has to mean something to the 
verifier who is doing the domain a favor by a) implementing the protocol and b) 
the goal of eliminating junk.   If there are false negatives, whose fault is 
that?  The Domain, The Verifier or the Protocol?

I think it’s the protocol but thats my opinion as one of early DKIM POLICY 
adopters and an advanced and costly implementation. If policy does not help 
protect a domain and also the receiver with failure hints or better said 
negative classification of a source per the domain policy, then what is the 
point of the work here or lack of there? 

Same is true with SPF.

Please try to be more civil with people’s views or position with this 
problematic protocol.

Thanks

All the best,
Hector Santos


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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-11 Thread Jim Fenton
On 10 Sep 2023, at 18:14, Dotzero wrote:

>> I agree that the SHOULD language is not very useful because it’s likely to
>> be interpreted as only advice. Instead, I think we need a stronger
>> statement about the consequences of this policy. For example, “Domains
>> publishing p=reject MUST NOT expect mail to mailing lists and similar
>> forwarders to be delivered reliably.”
>>
>
> The “MUST NOT you suggest is normative language that many will ignore with
> no particular incremental negative impact to them beyond the current
> situation. I'm not thrilled with the proposed SHOULD NOT language but it
> makes much more sense to me than your proposal.

One of the fundamental problems here is that the domain publishing the policy 
is only indirectly affected by the negative consequences of a p=reject policy. 
The MUST NOT that I proposed was intentionally to get the reader’s attention, 
and directly point out what bad things might occur.

Of course, that assumes that the decision makers are reading the specification 
itself, and not some vendor marketing material. That is probably not a safe 
assumption.

-Jim

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-11 Thread Dotzero
On Mon, Sep 11, 2023 at 6:36 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> We are still trying to fix an evaluator problem by changing domain
> owner behavior.  No harm in giving domain owners the warning, but changing
> evaluator behavior would be much better.   Presumably, the evaluator
> behavior that we have today is the result of RFC 7489 wording, so we may be
> able to change future evaluator behavior by strategizing the language of
> DMARCbis.
>

IETF is not the behavior police.


>
> Compare email authentication to a controlled-access building.   On any
> given day, some employees will arrive at work to discover that their badge
> is back at home.   How is it handled?   By sending the employee to the
> physical equivalent of quarantine:  the pass office.Most employees can
> be validated by another method, such as driver's license or biometrics.
>  An employee who forgot his wallet and cannot be verified by biometrics
> will lose a day's work.   However, a person who is identified as using a
> fake ID will be led away by police.
>
> Email authentication is not much different.   We are judging message
> source acceptability, not individual messages.
>

Absolutely incorrect. DMARC is a deterministic pass|fail approach based on
validation through DKIM or SPF pass (or if both pass). It says nothing
about the acceptability/goodness/badness of a source.

100% email authentication is possible and should be the goal.   Quarantine
> is the preferred place to send unauthenticated mail, regardless of sender
> policy (or lack of policy).In quarantine, acceptable messages are given
> alternate authentication and released, just as the secure-building employee
> is given a temporary badge or replacement badge.   If lack of authenticated
> is discovered to be a fraudulent attacker, then all messages from the
> attacker should be blocked, not just the impersonation messages.
>
> When it seems impossible to quarantine and review every unauthenticated
> message, triage becomes necessary.  The messages with highest perceived
> risk are sent to quarantine and the lower-risk messages are released and
> reviewed as time permits after the fact.
>

This is the dumbest approach possible. Think about it. What you are saying
is "With all our expertise, technology and automation, we are going to hand
the messages we think are the riskiest to you, the end user, who has no
expertise to figure out whether this message is safe". What is wrong with
this picture?


> Either way, the workload steadily decreases as message sources become
> permanently authenticated or permanently blocked.
>

Maybe the workload decreases and maybe it doesn't. You are making a huge
assumption that an authenticated message source will permanently be
authenticated and a blocked message source will permanently be "bad". This
approach creates real problems. In any event, this isn't how DMARC works.
DMARC validates each message on its own. DMARC does not involve reputation.
Please stop trying to conflate things outside of DMARC with DMARC.

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-11 Thread Douglas Foster
We are still trying to fix an evaluator problem by changing domain
owner behavior.  No harm in giving domain owners the warning, but changing
evaluator behavior would be much better.   Presumably, the evaluator
behavior that we have today is the result of RFC 7489 wording, so we may be
able to change future evaluator behavior by strategizing the language of
DMARCbis.

Compare email authentication to a controlled-access building.   On any
given day, some employees will arrive at work to discover that their badge
is back at home.   How is it handled?   By sending the employee to the
physical equivalent of quarantine:  the pass office.Most employees can
be validated by another method, such as driver's license or biometrics.
 An employee who forgot his wallet and cannot be verified by biometrics
will lose a day's work.   However, a person who is identified as using a
fake ID will be led away by police.

Email authentication is not much different.   We are judging message source
acceptability, not individual messages.  100% email authentication is
possible and should be the goal.   Quarantine is the preferred place to
send unauthenticated mail, regardless of sender policy (or lack of
policy).In quarantine, acceptable messages are given alternate
authentication and released, just as the secure-building employee is given
a temporary badge or replacement badge.   If lack of authenticated is
discovered to be a fraudulent attacker, then all messages from the attacker
should be blocked, not just the impersonation messages.

When it seems impossible to quarantine and review every unauthenticated
message, triage becomes necessary.  The messages with highest perceived
risk are sent to quarantine and the lower-risk messages are released and
reviewed as time permits after the fact.   Either way, the workload
steadily decreases as message sources become permanently authenticated or
permanently blocked.

Doug Foster


On Sun, Sep 10, 2023 at 8:46 PM Jim Fenton  wrote:

> On 7 Sep 2023, at 9:28, Wei Chuang wrote:
>
> Many enterprises already have "p=reject" policies. Presumably those
> domains were subject to some sort of spoofing which is why they went to
> such a strict policy.
>
> This is not necessarily the case. For example, DHS has directed
> 
> all Executive Branch federal agencies to publish a policy of reject,
> regardless of whether they were subject to spoofing (and with no mention of
> the problems with doing so. Others have published “Email Security Best
> Practices” advocating the use of p=reject. For example, one well-known
> email vendor has a tool that generates a warning if p=quarantine or
> p=reject isn’t configured, and says on their website, “We recommend reject,
> for reasons we’ll touch on later.”
>
> I agree that the SHOULD language is not very useful because it’s likely to
> be interpreted as only advice. Instead, I think we need a stronger
> statement about the consequences of this policy. For example, “Domains
> publishing p=reject MUST NOT expect mail to mailing lists and similar
> forwarders to be delivered reliably.”
>
> -Jim
> ___
> 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] Some Gmail comments on DMARCbis version 28

2023-09-10 Thread Dotzero
On Sun, Sep 10, 2023 at 8:46 PM Jim Fenton  wrote:

> On 7 Sep 2023, at 9:28, Wei Chuang wrote:
>
> Many enterprises already have "p=reject" policies. Presumably those
> domains were subject to some sort of spoofing which is why they went to
> such a strict policy.
>
> This is not necessarily the case. For example, DHS has directed
> 
> all Executive Branch federal agencies to publish a policy of reject,
> regardless of whether they were subject to spoofing (and with no mention of
> the problems with doing so. Others have published “Email Security Best
> Practices” advocating the use of p=reject. For example, one well-known
> email vendor has a tool that generates a warning if p=quarantine or
> p=reject isn’t configured, and says on their website, “We recommend reject,
> for reasons we’ll touch on later.”
>

The Federal government is not a very good example to make your point. In
the 2010-2011 time frame there were a number of high profile cases where
government email WAS spoofed with various negative outcomes. Two examples
come to mind. The first was an email purporting to be from Senate staff
(Sergeant at Arms) to various news agencies/publications that several high
profile Senators were killed. There were news reports of this as a result
that briefly moved financial markets. The other involved fake online
Christmas cards (email notifications) to various government contractors and
purporting to be from the White House (POTUS) even though at the time the
White House was still only sending printed Christmas cards. This resulted
in compromises at more than one defense contractor. As a result of these
sorts of incidents, Pat Peterson (Agari) and I were asked by EOP (Executive
Office of the President) to put together and give training on email
authentication that was turned into a virtual training environment for
government employees (excluding contractors). Since that time there have
been various efforts by the Federal government to implement stronger email
authentication practices, both at agencies and government contractors. This
ultimately led to the DHS directive. Yes it's a blunt instrument but it is
the culmination of a process triggered by cases of malicious "spoofing".

> I agree that the SHOULD language is not very useful because it’s likely to
> be interpreted as only advice. Instead, I think we need a stronger
> statement about the consequences of this policy. For example, “Domains
> publishing p=reject MUST NOT expect mail to mailing lists and similar
> forwarders to be delivered reliably.”
>

The "MUST NOT you suggest is normative language that many will ignore with
no particular incremental negative impact to them beyond the current
situation. I'm not thrilled with the proposed SHOULD NOT language but it
makes much more sense to me than your proposal.

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-10 Thread Douglas Foster
How I define a "Source":
To the domain owner, it is all of the environments that need to be touched,
as part of a DMARC implementation project, to ensure that they produce DKIM
PASS with SPF PASS or DKIM PASS with SPF NONE.   It includes corporate
employee email, ESPs, CRMs, Web Sites, Shadow IT, etc.

To the evaluator, "Source" is a unique combination of Server domain and
Mail From Domain which act as the last hop for a message from a
particular domain.

These are substantially the same thing, except for external forwarding.
 The forwarder is not a source that the domain owner can configure, but it
is a source for purposes of the evaluator's security analysis.

How "Sources" behave:
Authentication success or failure is not a series of independent random
events.The results are deterministic, based on the configuration (and
legitimacy) of the source.   A message either originates with
authentication or not.   It is either received directly or not.   If
forwarded, the DKIM signature is either intact or invalidated by the
forwarder's changes.

Perhaps In 2015, there was a presumption that authentication rates were
essentially zero, so nobody would object to deferring authentication a
little longer on a subset of messages.   In 2023, I know that most messages
can be authenticated because they are received directly and with SPF PASS.
 DKIM signatures bring the success rate even higher.  SPF errors are
common, but can be detected easily and corrected with local policy.   When
I read the 2015 language in 2023 context, I hear it expecting or perhaps
requiring evaluators to ignore obvious evidence of a potential threat, and
I cannot ever ask an evaluator to do that.   In 2023, 100% authentication
is entirely achievable, except for forwarding.

Our sender authentication techniques are designed for a world without
forwarding, which is why forwarding often involves identity rewrites.
Although DMARC can survive forwarding-without-changes, it does not expose
forwarding.   For forwarded messages, the evaluator needs to know the
identities of both originator and forwarder(s), so that reputation can be
applied to each one.   Currently, we cannot reliably apply all relevant
reputations because we lose visibility to important identifiers.   If the
Mail From is rewritten, then the originating Mail From identity is lost.
If the Mail From identity is preserved, then the forwarder identity becomes
invisible.  In either case, if forwarding is not detected, then the
originating server organization identity is presumed to be an unimportant
component in the forwarder's infrastructure, so its reputation is not
checked.  Forwarding is the remaining hole in our security model.

Doug Foster




On Sat, Sep 9, 2023 at 10:22 PM Murray S. Kucherawy 
wrote:

> On Sat, Sep 9, 2023 at 11:16 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I understand the phased roll-out goal, but phased rollout and percentages
>> are not applicable to the evaluator's task.
>>
>
>> I start with an assumption that message sources reflect the character of
>> the individual or organization that controls the source.   Malicious
>> traffic comes from malicious people.   Innocuous traffic comes from
>> non-malicious people.   Determining the identifier which indicates
>> the responsible people can be a little tricky, but once the responsible
>> identifier is determined, it is a binary issue
>>
>> [...]
>>
>
> I think this is ascribing layers of complexity to what was supposed to be
> a simple capability.  Maybe that's the way things are now and not how they
> were in 2015, but really, if I as a sender am using "pct=" then I'm not
> confident in the outcome, and as a receiver I think it's reasonable to
> infer that you shouldn't be either; the sender is experimenting.  Trying to
> divine spam vs. ham in such a situation is to my mind about as reliable as
> dowsing.
>
>
>> DMARC flags possibly-suspicious senders, not possibly-suspicious
>> messages, and an evaluator should use it accordingly.
>>
>
> How is that possible, when different messages even from this domain take
> different paths to their destinations, and can easily result in different
> outcomes?
>
>
>> Assume that Example.com is at 70% rollout, which means that of their 10
>> sources, 7 are DKIM-signing, two are doing SPF-only, and 1 is a non-signing
>> ESP.
>>
>
> I don't understand your use of "source".  Are you saying example.com has
> 10 different entities sending mail using that domain?  If so, I can assure
> you that none of that was considered when we defined "pct" in the first
> place.
>
> The definition of "pct" doesn't talk about sources, it talks about
> individual messages, evaluated independently.  It's meant to be applied in
> aggregate across all messages purporting to be from that domain,
> independently and irrespective of source.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-10 Thread Jim Fenton



On 7 Sep 2023, at 9:28, Wei Chuang wrote:

Many enterprises already have "p=reject" policies.  Presumably those 
domains were subject to some sort of spoofing which is why they went 
to such a strict policy.


This is not necessarily the case. For example, DHS has 
[directed](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security) 
all Executive Branch federal agencies to publish a policy of reject, 
regardless of whether they were subject to spoofing (and with no mention 
of the problems with doing so. Others have published “Email Security 
Best Practices” advocating the use of p=reject. For example, one 
well-known email vendor has a tool that generates a warning if 
p=quarantine or p=reject isn’t configured, and says on their website, 
“We recommend reject, for reasons we’ll touch on later.”


I agree that the SHOULD language is not very useful because it’s 
likely to be interpreted as only advice. Instead, I think we need a 
stronger statement about the consequences of this policy. For example, 
“Domains publishing p=reject MUST NOT expect mail to mailing lists and 
similar forwarders to be delivered reliably.”


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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-10 Thread Murray S. Kucherawy
One thing I forgot to mention:

On Thu, Sep 7, 2023 at 9:29 AM Wei Chuang  wrote:

> Our suggestion is that there is not a lot of value in including this
> language in the bis document if the likely outcome is that it will be
> ignored, and rather more effort should be placed with a technical solution
> for interop with mailing lists.
>

Absent a viable technical solution, I think the key thing should be the
correctness and appropriateness of the advice, not the likelihood that
people might choose to ignore it.

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-10 Thread Scott Kitterman
On Thursday, September 7, 2023 12:28:59 PM EDT Wei Chuang wrote:
> We had an opportunity to further review the DMARCbis changes more broadly
> within Gmail.  While we don't see any blockers in the language in DMARCbis
> version 28
>  and
> can live with what is there, we wanted to briefly raise some concerns
> around some of the changes.  Two points.
> 
> Regarding the languages in section 8.6 "It is therefore critical that
> domains that host users who might post messages to mailing lists SHOULD NOT
> publish p=reject.  Domains that choose to publish p=reject SHOULD implement
> policies that their users not post to Internet mailing lists", we wanted to
> point out that this is impossible to implement.  Many enterprises already
> have "p=reject" policies.  Presumably those domains were subject to some
> sort of spoofing which is why they went to such a strict policy.  It would
> be unreasonable to tell them to stop posting to mailing lists as many
> likely already use mailing list services and will want to continue to use
> them.  The one thing that makes this tractable is the SHOULD language as we
> may choose not to not follow this aspect of the specification.  Our
> suggestion is that there is not a lot of value in including this language
> in the bis document if the likely outcome is that it will be ignored, and
> rather more effort should be placed with a technical solution for interop
> with mailing lists.

It might be helpful if you could describe this technical solution from your 
perspective.

If there were a reasonable technical solution available, I think this would be 
a much easier change to support (in my opinion, and a believe a substantial 
number of others, rewriting From is not a reasonable technical solution).

Scott K




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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-09 Thread Murray S. Kucherawy
On Sat, Sep 9, 2023 at 11:16 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I understand the phased roll-out goal, but phased rollout and percentages
> are not applicable to the evaluator's task.
>

> I start with an assumption that message sources reflect the character of
> the individual or organization that controls the source.   Malicious
> traffic comes from malicious people.   Innocuous traffic comes from
> non-malicious people.   Determining the identifier which indicates
> the responsible people can be a little tricky, but once the responsible
> identifier is determined, it is a binary issue
>
> [...]
>

I think this is ascribing layers of complexity to what was supposed to be a
simple capability.  Maybe that's the way things are now and not how they
were in 2015, but really, if I as a sender am using "pct=" then I'm not
confident in the outcome, and as a receiver I think it's reasonable to
infer that you shouldn't be either; the sender is experimenting.  Trying to
divine spam vs. ham in such a situation is to my mind about as reliable as
dowsing.


> DMARC flags possibly-suspicious senders, not possibly-suspicious messages,
> and an evaluator should use it accordingly.
>

How is that possible, when different messages even from this domain take
different paths to their destinations, and can easily result in different
outcomes?


> Assume that Example.com is at 70% rollout, which means that of their 10
> sources, 7 are DKIM-signing, two are doing SPF-only, and 1 is a non-signing
> ESP.
>

I don't understand your use of "source".  Are you saying example.com has 10
different entities sending mail using that domain?  If so, I can assure you
that none of that was considered when we defined "pct" in the first place.

The definition of "pct" doesn't talk about sources, it talks about
individual messages, evaluated independently.  It's meant to be applied in
aggregate across all messages purporting to be from that domain,
independently and irrespective of source.

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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-09 Thread Douglas Foster
A not-yet mentioned characteristic of impersonating messages is that:

"Impersonation requires that a message originate from an
attacker-controlled server."


   - Mailbox providers require user-level authentication.
   - Hosting services require domain administrator authentication and use
   Control Panel tools to ensure that the domain administrator does not create
   unacceptable configurations.
   - ESPs require client enrollment and run-time login.  Among other
   reasons, this is necessary to ensure accurate and trusted billing
   statements.

 All of these environments can be (and are) used by malicious clients, but
they are not usable for impersonation.  For message sources that are
reliably known to come from one of these environments, DMARC is
unnecessary.Forwarding tricks can introduce complexity to this
analysis, but the principle stands.

Doug


On Sat, Sep 9, 2023 at 12:20 PM Murray S. Kucherawy 
wrote:

> I'm not looking to change the WG's mind on this matter, but:
>
> On Sat, Sep 9, 2023 at 3:54 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> There are many percentages mixed up together in this issue:
>>
>>- The percentage of domain message sources which provide proper
>>authentication at origination.
>>- The percentage of domain messages which originate with proper
>>authentication.   This is determined by the volume distribution between
>>sources, which is likely to be variable.
>>- The  percentage of domain messages which are received with
>>authentication.   This will be different for each evaluator, depending on
>>the sources from which those messages originate.  This is also affected by
>>transit issues.
>>
>> But none of those percentages actually matter.   The one that matters to
>> the evaluator is:
>>
>>- The conditional probability that an unauthenticated message is
>>actually from the domain and not from an impersonator.   For this test, 
>> the
>>denominator depends on the volume of impersonation messages, which is
>>completely independent of the domain's message volumes.
>>
>>
> This seems to over-complicate the point.  RFC 7489 says that "pct" means:
>
>   Percentage of messages from the Domain Owner's
>   mail stream to which the DMARC policy is to be applied.
>
> It goes on to say report messages are excluded from this test.  It says
> nothing about authentication.  Thus, if I get N messages from example.com,
> and the "pct" value is X, then the DMARC test is applied only to X% of that
> N; the simplest way to do this per-message would be to pick a random number
> between 0 and 1 and if it's greater than X%, the message simply bypasses
> DMARC altogether.
>
> That's how we intended it when we wrote that, and that's how early
> implementations did it.
>
> But maybe this is the lesson: People have inferred lots of different
> things from that rather straightforward definition, so maybe it's more
> ambiguous than we realized all those years ago.
>
> In RFC 7489, we have a domain-provided percentage whose calculation is
>> left undefined.   Whatever the calculation, the result has little relevance
>> to the evaluator's risk assessment.   It is actually harmful to advise
>> evaluators to disposition using the sender's percentage and a random number
>> generator.
>>
>
> How do you figure "harmful"?  The purpose was to enable a graduated
> rollout.  If 1-X% of those messages are outright ignored, what harm is
> being introduced?
>
> -MSK, participating
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-09 Thread Douglas Foster
I understand the phased roll-out goal, but phased rollout and percentages
are not applicable to the evaluator's task.

I start with an assumption that message sources reflect the character of
the individual or organization that controls the source.   Malicious
traffic comes from malicious people.   Innocuous traffic comes from
non-malicious people.   Determining the identifier which indicates
the responsible people can be a little tricky, but once the responsible
identifier is determined, it is a binary issue

DMARC flags possibly-suspicious senders, not possibly-suspicious messages,
and an evaluator should use it accordingly.

Assume that Example.com is at 70% rollout, which means that of their 10
sources, 7 are DKIM-signing, two are doing SPF-only, and 1 is a non-signing
ESP.

 As an evaluator, I will see some Example.com senders as 100% verified, and
others as 100% unverified.Applying a 70% rule will not protect
my network from all of the malicious content and will not ensure that all
of the wanted messages are delivered.The intelligent solution is to
investigate why a source is unverified.   Some of the possible answers:

   - The messages are from a well-known ESP, but not signed.   I trust the
   ESP's process for client enrollment and run-time login, so I don't need to
   worry about impersonation.   The message is legitimate.
   - The messages fail SPF with PERMERROR, because the domain owner tried
   to update his policy but duplicated the record instead of modifying it.
   I see the current source's IP address in both policies, so I don't need to
   worry about impersonation.
   - The messages have an aligned Mail From address, but they produce SPF
   Neutral.  A DKIM signature is always present but can never be verified.
The host names are from unrecognized domains.   The message has odd
   content.   I judge the sender to be malicious and block all traffic from
   that IP address and DNS domain.

Of course, I should be doing this analysis, and updating my filtering
rules, while Example.Com is in p=NONE mode, so that by the time that they
try p=quarantine pct=0, I already know how to filter their current traffic
correctly.

Doug Foster


On Sat, Sep 9, 2023 at 12:20 PM Murray S. Kucherawy 
wrote:

> I'm not looking to change the WG's mind on this matter, but:
>
> On Sat, Sep 9, 2023 at 3:54 AM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> There are many percentages mixed up together in this issue:
>>
>>- The percentage of domain message sources which provide proper
>>authentication at origination.
>>- The percentage of domain messages which originate with proper
>>authentication.   This is determined by the volume distribution between
>>sources, which is likely to be variable.
>>- The  percentage of domain messages which are received with
>>authentication.   This will be different for each evaluator, depending on
>>the sources from which those messages originate.  This is also affected by
>>transit issues.
>>
>> But none of those percentages actually matter.   The one that matters to
>> the evaluator is:
>>
>>- The conditional probability that an unauthenticated message is
>>actually from the domain and not from an impersonator.   For this test, 
>> the
>>denominator depends on the volume of impersonation messages, which is
>>completely independent of the domain's message volumes.
>>
>>
> This seems to over-complicate the point.  RFC 7489 says that "pct" means:
>
>   Percentage of messages from the Domain Owner's
>   mail stream to which the DMARC policy is to be applied.
>
> It goes on to say report messages are excluded from this test.  It says
> nothing about authentication.  Thus, if I get N messages from example.com,
> and the "pct" value is X, then the DMARC test is applied only to X% of that
> N; the simplest way to do this per-message would be to pick a random number
> between 0 and 1 and if it's greater than X%, the message simply bypasses
> DMARC altogether.
>
> That's how we intended it when we wrote that, and that's how early
> implementations did it.
>
> But maybe this is the lesson: People have inferred lots of different
> things from that rather straightforward definition, so maybe it's more
> ambiguous than we realized all those years ago.
>
> In RFC 7489, we have a domain-provided percentage whose calculation is
>> left undefined.   Whatever the calculation, the result has little relevance
>> to the evaluator's risk assessment.   It is actually harmful to advise
>> evaluators to disposition using the sender's percentage and a random number
>> generator.
>>
>
> How do you figure "harmful"?  The purpose was to enable a graduated
> rollout.  If 1-X% of those messages are outright ignored, what harm is
> being introduced?
>
> -MSK, participating
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-09 Thread Murray S. Kucherawy
I'm not looking to change the WG's mind on this matter, but:

On Sat, Sep 9, 2023 at 3:54 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> There are many percentages mixed up together in this issue:
>
>- The percentage of domain message sources which provide proper
>authentication at origination.
>- The percentage of domain messages which originate with proper
>authentication.   This is determined by the volume distribution between
>sources, which is likely to be variable.
>- The  percentage of domain messages which are received with
>authentication.   This will be different for each evaluator, depending on
>the sources from which those messages originate.  This is also affected by
>transit issues.
>
> But none of those percentages actually matter.   The one that matters to
> the evaluator is:
>
>- The conditional probability that an unauthenticated message is
>actually from the domain and not from an impersonator.   For this test, the
>denominator depends on the volume of impersonation messages, which is
>completely independent of the domain's message volumes.
>
>
This seems to over-complicate the point.  RFC 7489 says that "pct" means:

  Percentage of messages from the Domain Owner's
  mail stream to which the DMARC policy is to be applied.

It goes on to say report messages are excluded from this test.  It says
nothing about authentication.  Thus, if I get N messages from example.com,
and the "pct" value is X, then the DMARC test is applied only to X% of that
N; the simplest way to do this per-message would be to pick a random number
between 0 and 1 and if it's greater than X%, the message simply bypasses
DMARC altogether.

That's how we intended it when we wrote that, and that's how early
implementations did it.

But maybe this is the lesson: People have inferred lots of different things
from that rather straightforward definition, so maybe it's more ambiguous
than we realized all those years ago.

In RFC 7489, we have a domain-provided percentage whose calculation is left
> undefined.   Whatever the calculation, the result has little relevance to
> the evaluator's risk assessment.   It is actually harmful to advise
> evaluators to disposition using the sender's percentage and a random number
> generator.
>

How do you figure "harmful"?  The purpose was to enable a graduated
rollout.  If 1-X% of those messages are outright ignored, what harm is
being introduced?

-MSK, participating
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-09 Thread Douglas Foster
I objected strongly to the RFC 7489 language which provides disposition
instructions based on the PCT clause, and still do.
A brief review:
There are many percentages mixed up together in this issue:

   - The percentage of domain message sources which provide proper
   authentication at origination.
   - The percentage of domain messages which originate with proper
   authentication.   This is determined by the volume distribution between
   sources, which is likely to be variable.
   - The  percentage of domain messages which are received with
   authentication.   This will be different for each evaluator, depending on
   the sources from which those messages originate.  This is also affected by
   transit issues.

But none of those percentages actually matter.   The one that matters to
the evaluator is:

   - The conditional probability that an unauthenticated message is
   actually from the domain and not from an impersonator.   For this test, the
   denominator depends on the volume of impersonation messages, which is
   completely independent of the domain's message volumes.

And finally, even if this last percentage could be determined, the advice
is wrong.   If this percentage is the determining factor for allow or
block, the error-minimizing strategy is to either accept all, if the
legitimate percentage is high, or block all, if the legitimate percentage
is low.   The boundary between the two strategies depends on the relative
weight given to allow errors and block errors.   If the weighting is equal,
the breakpoint is 50%.

In RFC 7489, we have a domain-provided percentage whose calculation is left
undefined.   Whatever the calculation, the result has little relevance to
the evaluator's risk assessment.   It is actually harmful to advise
evaluators to disposition using the sender's percentage and a random number
generator.

The WG observed that some forwarders and some evaluators behave differently
between "p=none pct=100" and "p=quarantine pct=0".  The "t=" clause was
introduced to provide that distinction.

I don't object to leaving the PCT clause in place as a historical relic,
but we should repudiate the idea that the evaluator obtains
valuable guidance from it.

Doug Foster


On Fri, Sep 8, 2023 at 7:46 AM Alessandro Vesely  wrote:

> On Thu 07/Sep/2023 18:28:59 +0200 Wei Chuang wrote:
> >
> > Regarding the languages in section 8.6 "It is therefore critical that
> domains
> > that host users who might post messages to mailing lists SHOULD NOT
> publish
> > p=reject.  Domains that choose to publish p=reject SHOULD implement
> policies
> > that their users not post to Internet mailing lists", we wanted to point
> out
> > that this is impossible to implement.  Many enterprises already have
> "p=reject"
> > policies.  Presumably those domains were subject to some sort of
> spoofing which
> > is why they went to such a strict policy.  It would be unreasonable to
> tell
> > them to stop posting to mailing lists as many likely already use mailing
> list
> > services and will want to continue to use them.  The one thing that
> makes this
> > tractable is the SHOULD language as we may choose not to not follow this
> aspect
> > of the specification.  Our suggestion is that there is not a lot of
> value in
> > including this language in the bis document if the likely outcome is
> that it
> > will be ignored, and rather more effort should be placed with a
> technical
> > solution for interop with mailing lists.
>
>
> There is an "until the authentication ecosystem becomes more mature and
> deliverability issues are better resolved."  Some sites may consider that
> the
> mailing lists in their particular niche already solved the problem.  The
> (temporary?) alternative is to use different domains, at the cost of
> reviewing
> all subscriptions...
>
>
> > We question the benefit versus the implementation effort and confusion
> of
> > deprecating the DMARC policy "pct" percentage mode and replacing it with
> "t"
> > test.  We do agree that there is benefit in having receivers support a
> debug
> > mode to enable DMARC deployment and that the test mode supports the most
> useful
> > use case for testing with indirect mailflow behavior.   However "pct"
> > represents a sunk cost and implementing test mode seems redundant to the
> > already existing "pct" percentage mode.  Moreover both modes will likely
> need
> > to be supported for a while.  We do see senders use "pct" ratcheting and
> it
> > will be confusing to them when at some point they will have to switch.
>
>
> +1,  there are sites actually using pct=, however few.  I appeal to the WG
> to
> reconsider this decision.  Removing it is a gratuitous incompatibility.
>
>
> Best
> Ale
> --
>
>
>
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
___
dmarc mailing list
dmarc@ietf.org

Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-08 Thread Alessandro Vesely

On Thu 07/Sep/2023 18:28:59 +0200 Wei Chuang wrote:


Regarding the languages in section 8.6 "It is therefore critical that domains 
that host users who might post messages to mailing lists SHOULD NOT publish 
p=reject.  Domains that choose to publish p=reject SHOULD implement policies 
that their users not post to Internet mailing lists", we wanted to point out 
that this is impossible to implement.  Many enterprises already have "p=reject" 
policies.  Presumably those domains were subject to some sort of spoofing which 
is why they went to such a strict policy.  It would be unreasonable to tell 
them to stop posting to mailing lists as many likely already use mailing list 
services and will want to continue to use them.  The one thing that makes this 
tractable is the SHOULD language as we may choose not to not follow this aspect 
of the specification.  Our suggestion is that there is not a lot of value in 
including this language in the bis document if the likely outcome is that it 
will be ignored, and rather more effort should be placed with a technical 
solution for interop with mailing lists.



There is an "until the authentication ecosystem becomes more mature and 
deliverability issues are better resolved."  Some sites may consider that the 
mailing lists in their particular niche already solved the problem.  The 
(temporary?) alternative is to use different domains, at the cost of reviewing 
all subscriptions...



We question the benefit versus the implementation effort and confusion of 
deprecating the DMARC policy "pct" percentage mode and replacing it with "t" 
test.  We do agree that there is benefit in having receivers support a debug 
mode to enable DMARC deployment and that the test mode supports the most useful 
use case for testing with indirect mailflow behavior.   However "pct" 
represents a sunk cost and implementing test mode seems redundant to the 
already existing "pct" percentage mode.  Moreover both modes will likely need 
to be supported for a while.  We do see senders use "pct" ratcheting and it 
will be confusing to them when at some point they will have to switch.



+1,  there are sites actually using pct=, however few.  I appeal to the WG to 
reconsider this decision.  Removing it is a gratuitous incompatibility.



Best
Ale
--





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


Re: [dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-07 Thread Murray S. Kucherawy
On Thu, Sep 7, 2023 at 9:29 AM Wei Chuang  wrote:

> Regarding the languages in section 8.6 "It is therefore critical that
> domains that host users who might post messages to mailing lists SHOULD NOT
> publish p=reject.  Domains that choose to publish p=reject SHOULD implement
> policies that their users not post to Internet mailing lists", we wanted to
> point out that this is impossible to implement.  Many enterprises already
> have "p=reject" policies.  Presumably those domains were subject to some
> sort of spoofing which is why they went to such a strict policy.  It would
> be unreasonable to tell them to stop posting to mailing lists as many
> likely already use mailing list services and will want to continue to use
> them.  The one thing that makes this tractable is the SHOULD language as we
> may choose not to not follow this aspect of the specification.  Our
> suggestion is that there is not a lot of value in including this language
> in the bis document if the likely outcome is that it will be ignored, and
> rather more effort should be placed with a technical solution for interop
> with mailing lists.
>

Speaking as a participant:

I don't think it's impossible to implement generally.  Google (the company,
not Gmail the service), PayPal, Yahoo, and Facebook (when it was called
that) all found ways to mitigate the damage DMARC causes by moving their
human users (i.e., employees) into domains separate from their services.
That allowed the commercial stuff to go "p=reject" while the humans weren't
so constrained.  Of course the cost is that you have to move all of your
human traffic to a new domain, but that doesn't strike me as "impossible"
so much as inconvenient because they all did it.

As for Gmail itself, I think that argues for SHOULD NOT being the right
thing to say, although I still think that sends a weaker-than-desirable
message about interoperability.

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


[dmarc-ietf] Some Gmail comments on DMARCbis version 28

2023-09-07 Thread Wei Chuang
We had an opportunity to further review the DMARCbis changes more broadly
within Gmail.  While we don't see any blockers in the language in DMARCbis
version 28
 and
can live with what is there, we wanted to briefly raise some concerns
around some of the changes.  Two points.

Regarding the languages in section 8.6 "It is therefore critical that
domains that host users who might post messages to mailing lists SHOULD NOT
publish p=reject.  Domains that choose to publish p=reject SHOULD implement
policies that their users not post to Internet mailing lists", we wanted to
point out that this is impossible to implement.  Many enterprises already
have "p=reject" policies.  Presumably those domains were subject to some
sort of spoofing which is why they went to such a strict policy.  It would
be unreasonable to tell them to stop posting to mailing lists as many
likely already use mailing list services and will want to continue to use
them.  The one thing that makes this tractable is the SHOULD language as we
may choose not to not follow this aspect of the specification.  Our
suggestion is that there is not a lot of value in including this language
in the bis document if the likely outcome is that it will be ignored, and
rather more effort should be placed with a technical solution for interop
with mailing lists.

We question the benefit versus the implementation effort and confusion of
deprecating the DMARC policy "pct" percentage mode and replacing it with
"t" test.  We do agree that there is benefit in having receivers support a
debug mode to enable DMARC deployment and that the test mode supports the
most useful use case for testing with indirect mailflow behavior.   However
"pct" represents a sunk cost and implementing test mode seems redundant to
the already existing "pct" percentage mode.  Moreover both modes will
likely need to be supported for a while.  We do see senders use "pct"
ratcheting and it will be confusing to them when at some point they will
have to switch.


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