Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 1/5

[Scott Kitterman]

On Saturday, December 4, 2021 11:12:22 PM EST Murray S. Kucherawy wrote:
> On Fri, Dec 3, 2021 at 9:37 AM Alessandro Vesely  wrote:
> > The second paragraph says:
> > Section 8 creates a registry for known DMARC tags and registers the
> > initial set defined in this document.  Only tags defined in this
> > document or in later extensions, and thus added to that registry, are
> > to be processed; unknown tags MUST be ignored.
> > 
> > Couldn't it say something like so:
> > Section 8 creates a registry for known DMARC tags and registers the
> > initial set defined in this document.  Only tags defined in that
> > registry are to be processed.  Unknown tags MUST be ignored.
> > 
> > That way, fo, rua, and ruf definitions could be moved to the corresponding
> > I-Ds.
> 
> Those two paragraphs read identically to me.

I think that their effect is the same, but the proposed change is simpler and 
clearer.  For purposes an implementer striving for interoperability might care 
about what they need to know is that the registry is the authoritative source 
of valid tags.  The text about this document or later extensions doesn't add 
anything and may be confusing.

Imagine a case where some years from now a tag identified in this document is 
determined t be obsolete and another document disuses it and it's removed from 
the registry.  A strict reading of the current text might lead one to believe 
that because the tag was originally defined in this document, it's still 
required even though it's not longer in the registry.

I believe the revision makes it clearer that the registry is the authoritative 
source for determining which tags are valid.

Scott K


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

Re: [dmarc-ietf] 3.2.6. Non-existent Domains

[Tim Wicinski]

On Sat, Dec 4, 2021 at 11:14 PM Scott Kitterman 
wrote:

> Should we modify the definition of non-existent domains so that a domain
> that
> only has an RFC 7505 null mx record is still considered non-existent?
>
> I'll propose text if it's agreed this would be a useful change?
>
> Scott K
>
>
This is a useful addition.

3.2.6 also says:

This is a broader definition than that in [RFC8020].


But RFC8020 only defines "Denied name".  I suggest

This is a broader definition than what is defined as "Denied name" in
[RFC8020].
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

[dmarc-ietf] PSD Flag

[Scott Kitterman]

I think the addition of the PSD flag to support organizational domain 
determination is a good change.  I have some quibbles about the exact 
definition though:

>   psd:  A flag indicating whether the domain is a PSD. (plain-text;
> OPTIONAL; default is 'n').  Possible values are:
>
> y:  Domains on the PSL that publish DMARC policy records SHOULD
>include this tag with a value of 'y' to indicate that the
>domain is a PSD.  This information will be used during policy
>discovery to determine how to apply any DMARC policy records
>that are discovered during the tree walk.
> 
> n:  The default, indicating that the DMARC policy record is
>published for a domain that is not a PSD.

Why does this need a value at all?  Why can't the flag just be psd?

>   psd:  A flag indicating whether the domain is a PSD. (plain-text;
> OPTIONAL;).  Presence of this flag indicates that the domain
>   is a PSD and that this DMARC record MUST NOT be considered
>   for determining organizational domain.

This would require a change to the second paragraph of Section 4.6 to go with 
it:

>  For any email message, the Organizational Domain of the RFC5322.From 
>
>  domain is determined by performing a DNS Tree Walk as described in
>  Section 4.5.  The target of the search is a valid DMARC record that
>  contains a psd tag with a value of 'y'.  Once such a record has been
>  found, the Organizational Domain for the DNS domain matching the one
>  found in the RFC5322.From domain can be declared to be the target
>  domain queried for in the step just prior to the query that found the
>  PSD domain.

All that's needed is to strike "with a value of 'y'" from the second sentence.

I think this is simpler and clearer.

Scott K


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

[dmarc-ietf] 3.2.6. Non-existent Domains

[Scott Kitterman]

Should we modify the definition of non-existent domains so that a domain that 
only has an RFC 7505 null mx record is still considered non-existent?

I'll propose text if it's agreed this would be a useful change?

Scott K


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

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 1/5

[Murray S. Kucherawy]

On Fri, Dec 3, 2021 at 9:37 AM Alessandro Vesely  wrote:

> The second paragraph says:
>
> Section 8 creates a registry for known DMARC tags and registers the
> initial set defined in this document.  Only tags defined in this
> document or in later extensions, and thus added to that registry, are
> to be processed; unknown tags MUST be ignored.
>
> Couldn't it say something like so:
>
> Section 8 creates a registry for known DMARC tags and registers the
> initial set defined in this document.  Only tags defined in that
> registry are to be processed.  Unknown tags MUST be ignored.
>
> That way, fo, rua, and ruf definitions could be moved to the corresponding
> I-Ds.
>

Those two paragraphs read identically to me.

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

Re: [dmarc-ietf] draft-ietf-dmarc-dmarcbis-04 Release Notes

[Murray S. Kucherawy]

On Thu, Dec 2, 2021 at 12:51 PM Todd Herr  wrote:

> The change log (Appendix C) has been removed, because even though there
> are only two new ideas introduced, there is enough shifting of text to make
> this revision effectively a reboot.
>

No objection to that change, but this leads me to a suggestion: A section,
or an appendix, summarizing what's different between this version of DMARC
and the one described in RFC 7489 might be of benefit, especially to people
who implemented the older specification and might be looking to be sure
they didn't miss anything when updating.

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

[dmarc-ietf] RFC 9091 Downrefs

[Scott Kitterman]

Currently the draft (as did the previous revision) has:

>   3.2.8.  Public Suffix Domain (PSD)
>   
>  The term Public Suffix Domain is defined in [RFC9091].
>   
>   3.2.9.  Public Suffix Operator (PSO)
>   
> The term Public Suffix Operator is defined in [RFC9091].
>   
>   3.2.10.  PSO Controlled Domain Names
>   
> The term PSO Controlled Domain Names is defined in [RFC9091].

Assuming we don't want to make this draft experimental, These definitions 
should be imported here.

Scott K


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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Murray S. Kucherawy]

On Sat, Dec 4, 2021 at 4:51 PM Dave Crocker  wrote:

> I'm going to suggest that that analysis is not formally correct.
>
> The DKIM specification precisely defines validation for the signature
> and it precisely defines what coverage is 'required'.
>
> A receiver can indeed choose to apply stricter requirements, but a
> failure to satisfy these is NOT a DKIM fail. The extra requirements are
> outside the scope of the DKIM specification and therefore the failure
> has nothing to do with the standard.
>
> This is not a minor point, but it does seem to be a common point of
> confusion.
>

Right, I stand corrected.  The distinction is actually in the definition of
Authentication-Results, where a DKIM "pass" can be reported as a "policy"
result rather than a "pass" when the algorithm completed successfully but
some aspect of the signature was not acceptable to the verifier.

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

Re: [dmarc-ietf] Additions to introduction

[Scott Kitterman]

On December 4, 2021 10:09:48 PM UTC, Seth Blank 
 wrote:
>On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski  wrote:
>
>>
>> I am Ok with adding text of this nature, and I think it's helpful in
>> explaining to folks approaching
>> DMARC for the first time. But I start to lose focus on reading long
>> introductions (okay boomer).
>>
>> Maybe the Intro could get a section or two to help focus it.
>>
>> I am glad to assist wordsmithing Doug's comments if that is useful.
>>
>> tim
>>
>
>as an individual, I don't like the wording that Doug has provided at all. I
>think I understand what he's trying to say, but the text as proposed is far
>more confusing than clarifying.
>
>Further, with SPF and DKIM, it is explicit that you can treat a pass in
>certain ways, but that you are to make no such determination when the
>authentication method does not pass. But DMARC is explicitly about
>providing policy when the auth methods do not validate in an aligned
>manner. So, while we all know there are legitimate reasons such validation
>might fail, this language feels out of place in DMARC because addressing
>these failures is the purpose of the protocol.
>
>As chair, if the group believes some clarification is still needed here,
>that makes sense and follows from similar text in the other auth methods.
>My ask would be that it provides clarity to address operational matters,
>per the charter for this phase of work.

I don't think marketing materials belong in the document.  If you want to give 
an overview about utility and usage of DMARC, then it should be something about 
it being super useful and low risk for automated transactional email, but there 
are substantial false positive risks for email sent from people.

Scott K

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

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

[Scott Kitterman]

As discussion after I had filed this makes clear, my proposed solution isn't a 
great one.  Since we're well on our way towards removing PSL use from the DMARC 
revision, I don't think it matters a lot whether we reject it or hold for 
document update and mark it resolved when the new revision is finalized.

Although it is certainly a corner case, I think it's illustrative of why 
getting away from the PSL for this use will be a good thing.

Scott K

On December 4, 2021 6:00:25 PM UTC, John Levine  wrote:
>It appears that Murray S. Kucherawy   said:
>>-=-=-=-=-=-
>>
>>This was reported but not sent to the WG.  I believe the right disposition
>>is "Hold for Document Update".  Does anyone want to argue for "Rejected" or
>>"Verified"?
>
>Reject it.  Whether you choose to believe the non-ICANN part of the PSL is
>local policy.
>
>I also think that Scott's example in the notes is wrong.  It is perfectly
>plasuble for an operator's customers to have their own DMARC policy, although 
>most
>of the subdomains are less exotic than this one.  Try Centralic's us.com
>where I think you would not want foo.us.com and bar.us.com to share the
>same default policy.
>
>R's,
>John
>
>>-- Forwarded message -
>>From: RFC Errata System 
>>Date: Mon, Nov 1, 2021 at 4:31 PM
>>Subject: [Technical Errata Reported] RFC7489 (6729)
>>To: , , 
>>Cc: , 
>>
>>
>>The following errata report has been submitted for RFC7489,
>>"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".
>>
>>--
>>You may review the report below and at:
>>https://www.rfc-editor.org/errata/eid6729
>>
>>--
>>Type: Technical
>>Reported by: Scott Kitterman 
>>
>>Section: 3.2
>>
>>Original Text
>>-
>>   3.  Search the public suffix list for the name that matches the
>>   largest number of labels found in the subject DNS domain.  Let
>>   that number be "x".
>>
>>Corrected Text
>>--
>>   3.  Search the ICANN DOMAINS section of the public suffix list for
>>   the name that matches the largest number of labels found in the
>>   subject DNS domain.  Let that number be "x".
>>
>>Notes
>>-
>>The PSL includes both public and private domains.  RFC 7489 should have
>>limited name matching to the public, ICANN DOMAINS section of the PSL.  As
>>an example, using the current PSL, the organizational domain for
>>example.s3.dualstack.ap-northeast-1.amazonaws.com is
>>example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since
>>it is listed in the private section of the PSL.  This is clearly the wrong
>>result.
>>
>>Instructions:
>>-
>>This erratum is currently posted as "Reported". If necessary, please
>>use "Reply All" to discuss whether it should be verified or
>>rejected. When a decision is reached, the verifying party
>>can log in to change the status and edit the report, if necessary.
>>
>>--
>>RFC7489 (draft-kucherawy-dmarc-base-12)
>>--
>>Title   : Domain-based Message Authentication, Reporting, and
>>Conformance (DMARC)
>>Publication Date: March 2015
>>Author(s)   : M. Kucherawy, Ed., E. Zwicky, Ed.
>>Category: INFORMATIONAL
>>Source  : INDEPENDENT
>>Area: N/A
>>Stream  : INDEPENDENT
>>Verifying Party : ISE & Editorial Board
>>
>>-=-=-=-=-=-
>>[Alternative: text/html]
>>-=-=-=-=-=-
>
>
>___
>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] Best Guess SPF should not be deprecated.

[Scott Kitterman]

On December 4, 2021 10:35:17 PM UTC, Douglas Foster 
 wrote:
>I have multiple objections to this paragraph in section 5.7.2
>
>"Heuristics applied in the absence of use by a Domain Owner of either SPF
>or DKIM (e.g., [Best-Guess-SPF
>
>]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes a
>Message Receiver not to consider the results of that underlying
>authentication protocol at all."
>
>First, it is unnecessary.   A sender who wants SPF ignored for purposes of
>DMARC can simply publish "?ALL" to produce the desired result.
>
>Second, I don't know why a sender would want this behavior.   I understand
>that some senders have difficulty describing their environment within SPF
>complexity limits, but Google, Microsoft, and Amazon seem to have been able
>to cope with the constraint.Even when complexity is the problem, a
>partial list of clauses, terminated with "?ALL", would be preferable to no
>policy.
>
>My experience has been that SPF=NONE has a high probability of being
>unwanted mail.   There is enough usage of SPF that serious participants are
>unlikely to use it.
>
>I have been using default SPF clauses for the last couple of years, with
>good results, so I need some serious convincing to backtrack.
>
>I think this text was inserted because of an open ticket when discussion
>was going nowhere and a new draft was created.  Perhaps the originator of
>that ticket can elaborate on his thinking.
>
>Counter-proposal
>
>Another part of the draft observes that SPF policies can become too loose.
> For example, this could happen from range consolidation or nested
>includes, either of which might cause unauthorized servers to be included
>in the allowed list.  If a sender knows that his SPF has this problem, and
>that all of his messages are DKIM-signed, he might want to publish a flag
>which says, "All my messages are signed.  Any messages that are not
>DKIM-verified should be treated as DMARC FAIL, even if they pass SPF."  I
>still doubt that we have a critical mass of domain owners who would use
>this option if it were available, and it seems like yet another avenue for
>false positives.   But if such a capability is desired, it should be
>implemented as part of the DMARC policy statement, not as a general
>constraint on evaluators.

The alternative is not needed either.  If operational advice is needed, then it 
should be in an appendix or perhaps another document.  It shouldn't be part of 
the protocol specification.  It's not particularly good advice either.

Scott K

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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Seth Blank]

On Sat, Dec 4, 2021 at 17:48 Scott Kitterman  wrote:

>
>
> On December 5, 2021 12:23:40 AM UTC, "Murray S. Kucherawy" <
> superu...@gmail.com> wrote:
> >On Sat, Dec 4, 2021 at 2:35 PM Douglas Foster <
> >dougfoster.emailstanda...@gmail.com> wrote:
> >
> >> I think this text was inserted because of an open ticket when discussion
> >> was going nowhere and a new draft was created.  Perhaps the originator
> of
> >> that ticket can elaborate on his thinking.
> >>
> >
> >I believe the admonishment against best-guess SPF was based at least in
> >part on the sentiments found here:
> >
> >http://www.open-spf.org/FAQ/Best_guess_record/
> >
> >...which is to say it's apparently a discouraged practice.
> >
> >It makes it difficult for DMARC to be deterministic when the things upon
> >which it's built behave in unpredictable ways.  That's not to say this is
> >unique though; DKIM, for example, allows verifiers to decide what an
> >acceptable signature is (a favorite I remember from the early days was "I
> >don't want to accept a DKIM signature that didn't cover the Subject
> >field"), which again means one site's "pass" is another site's "fail".
>
> Much like Dave's response about DKIM, I think what an SPF result is is
> well defined.  The so called "Best Guess" isn't an SPF result at all.
> Implementation and interoperability requirements for SPF are defined by RFC
> 7208 (and formerly RFC 4408).  Neither it nor it's predecessor ever defined
> this.  It's not implemented in Mail::SPF, which is the closest thing there
> is to a reference implementation.
>
> We already say to use DKIM and SPF.  If you want an enumerated list of all
> the things that aren't DKIM or SPF to tell people not to do, I think it
> would be a long list.  As far as I know, no RFC even mentions "Best Guess"
> and this one should not be the first.


+1


>
> Scott K
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>
-- 

*Seth Blank * | Chief Product Officer
*e:* s...@valimail.com
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Scott Kitterman]

On December 5, 2021 12:23:40 AM UTC, "Murray S. Kucherawy" 
 wrote:
>On Sat, Dec 4, 2021 at 2:35 PM Douglas Foster <
>dougfoster.emailstanda...@gmail.com> wrote:
>
>> I think this text was inserted because of an open ticket when discussion
>> was going nowhere and a new draft was created.  Perhaps the originator of
>> that ticket can elaborate on his thinking.
>>
>
>I believe the admonishment against best-guess SPF was based at least in
>part on the sentiments found here:
>
>http://www.open-spf.org/FAQ/Best_guess_record/
>
>...which is to say it's apparently a discouraged practice.
>
>It makes it difficult for DMARC to be deterministic when the things upon
>which it's built behave in unpredictable ways.  That's not to say this is
>unique though; DKIM, for example, allows verifiers to decide what an
>acceptable signature is (a favorite I remember from the early days was "I
>don't want to accept a DKIM signature that didn't cover the Subject
>field"), which again means one site's "pass" is another site's "fail".

Much like Dave's response about DKIM, I think what an SPF result is is well 
defined.  The so called "Best Guess" isn't an SPF result at all.  
Implementation and interoperability requirements for SPF are defined by RFC 
7208 (and formerly RFC 4408).  Neither it nor it's predecessor ever defined 
this.  It's not implemented in Mail::SPF, which is the closest thing there is 
to a reference implementation.

We already say to use DKIM and SPF.  If you want an enumerated list of all the 
things that aren't DKIM or SPF to tell people not to do, I think it would be a 
long list.  As far as I know, no RFC even mentions "Best Guess" and this one 
should not be the first.

Scott K

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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Dave Crocker]

On 12/4/2021 4:23 PM, Murray S. Kucherawy wrote:
DKIM, for example, allows verifiers to decide what an acceptable 
signature is (a favorite I remember from the early days was "I don't 
want to accept a DKIM signature that didn't cover the Subject field"), 
which again means one site's "pass" is another site's "fail".



I'm going to suggest that that analysis is not formally correct.

The DKIM specification precisely defines validation for the signature 
and it precisely defines what coverage is 'required'.


A receiver can indeed choose to apply stricter requirements, but a 
failure to satisfy these is NOT a DKIM fail. The extra requirements are 
outside the scope of the DKIM specification and therefore the failure 
has nothing to do with the standard.


This is not a minor point, but it does seem to be a common point of 
confusion.


d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

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

Re: [dmarc-ietf] Best Guess SPF should not be deprecated.

[Murray S. Kucherawy]

On Sat, Dec 4, 2021 at 2:35 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:

> I think this text was inserted because of an open ticket when discussion
> was going nowhere and a new draft was created.  Perhaps the originator of
> that ticket can elaborate on his thinking.
>

I believe the admonishment against best-guess SPF was based at least in
part on the sentiments found here:

http://www.open-spf.org/FAQ/Best_guess_record/

...which is to say it's apparently a discouraged practice.

It makes it difficult for DMARC to be deterministic when the things upon
which it's built behave in unpredictable ways.  That's not to say this is
unique though; DKIM, for example, allows verifiers to decide what an
acceptable signature is (a favorite I remember from the early days was "I
don't want to accept a DKIM signature that didn't cover the Subject
field"), which again means one site's "pass" is another site's "fail".

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

[dmarc-ietf] Best Guess SPF should not be deprecated.

[Douglas Foster]

I have multiple objections to this paragraph in section 5.7.2

"Heuristics applied in the absence of use by a Domain Owner of either SPF
or DKIM (e.g., [Best-Guess-SPF

]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes a
Message Receiver not to consider the results of that underlying
authentication protocol at all."

First, it is unnecessary.   A sender who wants SPF ignored for purposes of
DMARC can simply publish "?ALL" to produce the desired result.

Second, I don't know why a sender would want this behavior.   I understand
that some senders have difficulty describing their environment within SPF
complexity limits, but Google, Microsoft, and Amazon seem to have been able
to cope with the constraint.Even when complexity is the problem, a
partial list of clauses, terminated with "?ALL", would be preferable to no
policy.

My experience has been that SPF=NONE has a high probability of being
unwanted mail.   There is enough usage of SPF that serious participants are
unlikely to use it.

I have been using default SPF clauses for the last couple of years, with
good results, so I need some serious convincing to backtrack.

I think this text was inserted because of an open ticket when discussion
was going nowhere and a new draft was created.  Perhaps the originator of
that ticket can elaborate on his thinking.

Counter-proposal

Another part of the draft observes that SPF policies can become too loose.
 For example, this could happen from range consolidation or nested
includes, either of which might cause unauthorized servers to be included
in the allowed list.  If a sender knows that his SPF has this problem, and
that all of his messages are DKIM-signed, he might want to publish a flag
which says, "All my messages are signed.  Any messages that are not
DKIM-verified should be treated as DMARC FAIL, even if they pass SPF."  I
still doubt that we have a critical mass of domain owners who would use
this option if it were available, and it seems like yet another avenue for
false positives.   But if such a capability is desired, it should be
implemented as part of the DMARC policy statement, not as a general
constraint on evaluators.

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

Re: [dmarc-ietf] Additions to introduction

[Seth Blank]

On Sat, Dec 4, 2021 at 1:34 PM Tim Wicinski  wrote:

>
> I am Ok with adding text of this nature, and I think it's helpful in
> explaining to folks approaching
> DMARC for the first time. But I start to lose focus on reading long
> introductions (okay boomer).
>
> Maybe the Intro could get a section or two to help focus it.
>
> I am glad to assist wordsmithing Doug's comments if that is useful.
>
> tim
>

as an individual, I don't like the wording that Doug has provided at all. I
think I understand what he's trying to say, but the text as proposed is far
more confusing than clarifying.

Further, with SPF and DKIM, it is explicit that you can treat a pass in
certain ways, but that you are to make no such determination when the
authentication method does not pass. But DMARC is explicitly about
providing policy when the auth methods do not validate in an aligned
manner. So, while we all know there are legitimate reasons such validation
might fail, this language feels out of place in DMARC because addressing
these failures is the purpose of the protocol.

As chair, if the group believes some clarification is still needed here,
that makes sense and follows from similar text in the other auth methods.
My ask would be that it provides clarity to address operational matters,
per the charter for this phase of work.

Seth



>
>
>
>
> On Sat, Dec 4, 2021 at 4:25 PM Murray S. Kucherawy 
> wrote:
>
>> On Sat, Dec 4, 2021 at 9:55 AM John Levine  wrote:
>>
>>> The point of a spec is to tell people how to interpoerate.  I don't see
>>> how this
>>> contributes to that.
>>>
>>
>> Lots of specifications include informative guidance or best practices
>> advice as well as normative specification.  DKIM has loads of it.
>>
>> -MSK
>> ___
>> 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
>


-- 

*Seth Blank * | Chief Product Officer
*e:* s...@valimail.com
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

[Seth Blank]

On Sat, Dec 4, 2021 at 10:00 AM John Levine  wrote:

> It appears that Murray S. Kucherawy   said:
> >-=-=-=-=-=-
> >
> >This was reported but not sent to the WG.  I believe the right disposition
> >is "Hold for Document Update".  Does anyone want to argue for "Rejected"
> or
> >"Verified"?
>
> Reject it.  Whether you choose to believe the non-ICANN part of the PSL is
> local policy.
>
> I also think that Scott's example in the notes is wrong.  It is perfectly
> plasuble for an operator's customers to have their own DMARC policy,
> although most
> of the subdomains are less exotic than this one.  Try Centralic's us.com
> where I think you would not want foo.us.com and bar.us.com to share the
> same default policy.
>
> R's,
> John
>

+1

Scott's example, which he states as wrong, is in fact correct.

The org domain should in fact be
example.s3.dualstack.ap-northeast-1.amazonaws.com and not amazonaws.com, as
amazonaws.com is not the organization which controls policy for, or should
receive reports for, the organization which has registered and is using
example.s3.dualstack.ap-northeast-1.amazonaws.com.

Seth, as an individual



>
> >-- Forwarded message -
> >From: RFC Errata System 
> >Date: Mon, Nov 1, 2021 at 4:31 PM
> >Subject: [Technical Errata Reported] RFC7489 (6729)
> >To: , , <
> rfc-...@rfc-editor.org>
> >Cc: , 
> >
> >
> >The following errata report has been submitted for RFC7489,
> >"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".
> >
> >--
> >You may review the report below and at:
> >https://www.rfc-editor.org/errata/eid6729
> >
> >--
> >Type: Technical
> >Reported by: Scott Kitterman 
> >
> >Section: 3.2
> >
> >Original Text
> >-
> >   3.  Search the public suffix list for the name that matches the
> >   largest number of labels found in the subject DNS domain.  Let
> >   that number be "x".
> >
> >Corrected Text
> >--
> >   3.  Search the ICANN DOMAINS section of the public suffix list for
> >   the name that matches the largest number of labels found in the
> >   subject DNS domain.  Let that number be "x".
> >
> >Notes
> >-
> >The PSL includes both public and private domains.  RFC 7489 should have
> >limited name matching to the public, ICANN DOMAINS section of the PSL.  As
> >an example, using the current PSL, the organizational domain for
> >example.s3.dualstack.ap-northeast-1.amazonaws.com is
> >example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com
> since
> >it is listed in the private section of the PSL.  This is clearly the wrong
> >result.
> >
> >Instructions:
> >-
> >This erratum is currently posted as "Reported". If necessary, please
> >use "Reply All" to discuss whether it should be verified or
> >rejected. When a decision is reached, the verifying party
> >can log in to change the status and edit the report, if necessary.
> >
> >--
> >RFC7489 (draft-kucherawy-dmarc-base-12)
> >--
> >Title   : Domain-based Message Authentication, Reporting, and
> >Conformance (DMARC)
> >Publication Date: March 2015
> >Author(s)   : M. Kucherawy, Ed., E. Zwicky, Ed.
> >Category: INFORMATIONAL
> >Source  : INDEPENDENT
> >Area: N/A
> >Stream  : INDEPENDENT
> >Verifying Party : ISE & Editorial Board
> >
> >-=-=-=-=-=-
> >[Alternative: text/html]
> >-=-=-=-=-=-
>
>
> ___
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>


-- 

*Seth Blank * | Chief Product Officer
*e:* s...@valimail.com
*p:* 415.273.8818

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Additions to introduction

[Tim Wicinski]

I am Ok with adding text of this nature, and I think it's helpful in
explaining to folks approaching
DMARC for the first time. But I start to lose focus on reading long
introductions (okay boomer).

Maybe the Intro could get a section or two to help focus it.

I am glad to assist wordsmithing Doug's comments if that is useful.

tim




On Sat, Dec 4, 2021 at 4:25 PM Murray S. Kucherawy 
wrote:

> On Sat, Dec 4, 2021 at 9:55 AM John Levine  wrote:
>
>> The point of a spec is to tell people how to interpoerate.  I don't see
>> how this
>> contributes to that.
>>
>
> Lots of specifications include informative guidance or best practices
> advice as well as normative specification.  DKIM has loads of it.
>
> -MSK
> ___
> 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] dmarcbis-04, 5.3. General Record Format 5/5

[Murray S. Kucherawy]

Argh:

On Sat, Dec 4, 2021 at 1:30 PM Murray S. Kucherawy 
wrote:

>
> I'd be happy with either of these two definitions:
>
> (a) All messages are subjected to DMARC checking, and "pct" identifies the
> percentage of messages failing the check that should be subjected to the
> policy;
>
> (b) "pct" identifies the percentage of messages subjected to the DMARC
> check, irrespective of the outcome.
>
> So the dice-roll happens either before you start DMARC, or after you find
> a "fail".  They're not the same thing, and (again if "pct" stays) we need
> to be clear about which one people are expected to implement.
>
> The original intent, as I recall, was (a).  We preferred that because if
> you choose early on to exclude the message you're handling, you avoid all
> that processing cost.
>

The clown who said this hit "Send" without proofreading.  The original
intent was (b), for the reason given.

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

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

[Murray S. Kucherawy]

On Fri, Dec 3, 2021 at 10:38 AM Todd Herr  wrote:

> We can have this conversation too. I will promise, however, that if the
> group decides to keep 'pct', I will absolutely insist that the first
> sentence in its definition be changed. Somehow, RFC 7489 got released with
> this text:
>
>pct:  (plain-text integer between 0 and 100, inclusive; OPTIONAL;
>
>   default is 100).  Percentage of messages from the Domain Owner's
>
>   mail stream to which the DMARC policy is to be applied.
>
>
> And I will go to my grave stating that DMARC policies cannot be applied to
> messages that pass DMARC authentication checks, and the definitions of
> 'quarantine' and 'reject' explicitly refer to messages that fail DMARC
> authentication checks.
>
> The sentence should read something like this:
>
> Percentage of messages using the Domain Owner's domain and failing DMARC
> authentication checks to which the DMARC policy is to be applied.
>
>
I'd be happy with either of these two definitions:

(a) All messages are subjected to DMARC checking, and "pct" identifies the
percentage of messages failing the check that should be subjected to the
policy;

(b) "pct" identifies the percentage of messages subjected to the DMARC
check, irrespective of the outcome.

So the dice-roll happens either before you start DMARC, or after you find a
"fail".  They're not the same thing, and (again if "pct" stays) we need to
be clear about which one people are expected to implement.

The original intent, as I recall, was (a).  We preferred that because if
you choose early on to exclude the message you're handling, you avoid all
that processing cost.

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

Re: [dmarc-ietf] Additions to introduction

[Murray S. Kucherawy]

On Sat, Dec 4, 2021 at 9:55 AM John Levine  wrote:

> The point of a spec is to tell people how to interpoerate.  I don't see
> how this
> contributes to that.
>

Lots of specifications include informative guidance or best practices
advice as well as normative specification.  DKIM has loads of it.

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

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

[Tim Wicinski]

On Sat, Dec 4, 2021 at 6:20 AM Alessandro Vesely  wrote:

> On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote:
> > On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely 
> wrote:
> >>
> >> last message for today:  the "t" tag instead of "pct".
> >>
> >> That's the only part which breaks existing records.  According to the
> last
> >> paragraph of this section, doing so requires v=DMARC2.
> >>
> >
> > I'm not sure I agree with your assertion here. I'm assuming you're
> > referring to this paragraph:
> >
> > Note that given the rules of the previous paragraph, addition of a
> > new tag into the registered list of tags does not itself require a
> > new version of DMARC to be generated (with a corresponding change to
> > the "v" tag's value), but a change to any existing tags does require
> > a new version of DMARC.
>
>
> Exactly.
>
>
> > I contend that introducing 't' to replace 'pct' is not a change to an
> > existing tag but rather an addition of a new tag.
>
>
> In that case, the definition of pct= must still appear in the spec.  As
> rfc7489
> is obsoleted, referencing it makes little sense.
>

Ale,

While RFC7489 will be obsoleted, it did document several tags which are no
longer considered valid.

If the concern is that we will be forcing readers of the new RFC to chase
through
old documents to understand what 'pct' tag was defined, Appendix A.7
explains
the pct tag, and its removal.  I think that is the right place to place
this info.

tim



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

Re: [dmarc-ietf] Fwd: [Technical Errata Reported] RFC7489 (6729)

[Tim Wicinski]

I must agree with Mr Levine on this.

tim


On Sat, Dec 4, 2021 at 1:00 PM John Levine  wrote:

> It appears that Murray S. Kucherawy   said:
> >-=-=-=-=-=-
> >
> >This was reported but not sent to the WG.  I believe the right disposition
> >is "Hold for Document Update".  Does anyone want to argue for "Rejected"
> or
> >"Verified"?
>
> Reject it.  Whether you choose to believe the non-ICANN part of the PSL is
> local policy.
>
> I also think that Scott's example in the notes is wrong.  It is perfectly
> plasuble for an operator's customers to have their own DMARC policy,
> although most
> of the subdomains are less exotic than this one.  Try Centralic's us.com
> where I think you would not want foo.us.com and bar.us.com to share the
> same default policy.
>
> R's,
> John
>
> >-- Forwarded message -
> >From: RFC Errata System 
> >Date: Mon, Nov 1, 2021 at 4:31 PM
> >Subject: [Technical Errata Reported] RFC7489 (6729)
> >To: , , <
> rfc-...@rfc-editor.org>
> >Cc: , 
> >
> >
> >The following errata report has been submitted for RFC7489,
> >"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".
> >
> >--
> >You may review the report below and at:
> >https://www.rfc-editor.org/errata/eid6729
> >
> >--
> >Type: Technical
> >Reported by: Scott Kitterman 
> >
> >Section: 3.2
> >
> >Original Text
> >-
> >   3.  Search the public suffix list for the name that matches the
> >   largest number of labels found in the subject DNS domain.  Let
> >   that number be "x".
> >
> >Corrected Text
> >--
> >   3.  Search the ICANN DOMAINS section of the public suffix list for
> >   the name that matches the largest number of labels found in the
> >   subject DNS domain.  Let that number be "x".
> >
> >Notes
> >-
> >The PSL includes both public and private domains.  RFC 7489 should have
> >limited name matching to the public, ICANN DOMAINS section of the PSL.  As
> >an example, using the current PSL, the organizational domain for
> >example.s3.dualstack.ap-northeast-1.amazonaws.com is
> >example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com
> since
> >it is listed in the private section of the PSL.  This is clearly the wrong
> >result.
> >
> >Instructions:
> >-
> >This erratum is currently posted as "Reported". If necessary, please
> >use "Reply All" to discuss whether it should be verified or
> >rejected. When a decision is reached, the verifying party
> >can log in to change the status and edit the report, if necessary.
> >
> >--
> >RFC7489 (draft-kucherawy-dmarc-base-12)
> >--
> >Title   : Domain-based Message Authentication, Reporting, and
> >Conformance (DMARC)
> >Publication Date: March 2015
> >Author(s)   : M. Kucherawy, Ed., E. Zwicky, Ed.
> >Category: INFORMATIONAL
> >Source  : INDEPENDENT
> >Area: N/A
> >Stream  : INDEPENDENT
> >Verifying Party : ISE & Editorial Board
> >
> >-=-=-=-=-=-
> >[Alternative: text/html]
> >-=-=-=-=-=-
>
>
> ___
> 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] Fwd: [Technical Errata Reported] RFC7489 (6729)

[John Levine]

It appears that Murray S. Kucherawy   said:
>-=-=-=-=-=-
>
>This was reported but not sent to the WG.  I believe the right disposition
>is "Hold for Document Update".  Does anyone want to argue for "Rejected" or
>"Verified"?

Reject it.  Whether you choose to believe the non-ICANN part of the PSL is
local policy.

I also think that Scott's example in the notes is wrong.  It is perfectly
plasuble for an operator's customers to have their own DMARC policy, although 
most
of the subdomains are less exotic than this one.  Try Centralic's us.com
where I think you would not want foo.us.com and bar.us.com to share the
same default policy.

R's,
John

>-- Forwarded message -
>From: RFC Errata System 
>Date: Mon, Nov 1, 2021 at 4:31 PM
>Subject: [Technical Errata Reported] RFC7489 (6729)
>To: , , 
>Cc: , 
>
>
>The following errata report has been submitted for RFC7489,
>"Domain-based Message Authentication, Reporting, and Conformance (DMARC)".
>
>--
>You may review the report below and at:
>https://www.rfc-editor.org/errata/eid6729
>
>--
>Type: Technical
>Reported by: Scott Kitterman 
>
>Section: 3.2
>
>Original Text
>-
>   3.  Search the public suffix list for the name that matches the
>   largest number of labels found in the subject DNS domain.  Let
>   that number be "x".
>
>Corrected Text
>--
>   3.  Search the ICANN DOMAINS section of the public suffix list for
>   the name that matches the largest number of labels found in the
>   subject DNS domain.  Let that number be "x".
>
>Notes
>-
>The PSL includes both public and private domains.  RFC 7489 should have
>limited name matching to the public, ICANN DOMAINS section of the PSL.  As
>an example, using the current PSL, the organizational domain for
>example.s3.dualstack.ap-northeast-1.amazonaws.com is
>example.s3.dualstack.ap-northeast-1.amazonaws.com, not amazonaws.com since
>it is listed in the private section of the PSL.  This is clearly the wrong
>result.
>
>Instructions:
>-
>This erratum is currently posted as "Reported". If necessary, please
>use "Reply All" to discuss whether it should be verified or
>rejected. When a decision is reached, the verifying party
>can log in to change the status and edit the report, if necessary.
>
>--
>RFC7489 (draft-kucherawy-dmarc-base-12)
>--
>Title   : Domain-based Message Authentication, Reporting, and
>Conformance (DMARC)
>Publication Date: March 2015
>Author(s)   : M. Kucherawy, Ed., E. Zwicky, Ed.
>Category: INFORMATIONAL
>Source  : INDEPENDENT
>Area: N/A
>Stream  : INDEPENDENT
>Verifying Party : ISE & Editorial Board
>
>-=-=-=-=-=-
>[Alternative: text/html]
>-=-=-=-=-=-


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

Re: [dmarc-ietf] Additions to introduction

[John Levine]

It appears that Douglas Foster   said:
>-=-=-=-=-=-
>
>I propose that a paragraph along these lines be inserted into the
>introduction:
>
>The DMARC test is characterized by a one-tailed error distribution:
> Messages which pass verification have a low probability of being false
>positives of actual impersonation. When a recipient intends to exempt a
>high-value sender from content filtering, identity verification ensures
>that such special treatment can be done safely, without concern for
>impersonation.However, the same cannot be said about verification
>failures.  Verification failures can occur for many reasons, and many such
>messages will be safe and desired by the recipient.   Messages which do not
>verify are optimally handled with manual review, but this may not be
>feasible due to message volume.DMARC provides a way for senders and
>receivers to safely cooperate to minimize the probability that automated
>disposition decisions will be suboptimal.

The point of a spec is to tell people how to interpoerate.  I don't see how this
contributes to that.  

Also, as we have found from the past several years of argument, the
last sentence is simply wrong. In some cases DMARC lets you make
correct decisions, in others it does not/

R's,
John

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

Re: [dmarc-ietf] Additions to introduction

[Douglas Foster]

After I sent this, I wondered if I needed to add more text to explain that
"manual review" means "manual review, followed by local policy changes, so
that manual review will no longer be necessary on messages with the same
identifiers."   If a reader thinks "manual review" means "look at every
message individually, now and forever," the reader will laugh it off.   But
in an introduction, we cannot say everything.  So I am open to suggestions.

I can say with some confidence that the false-positive problem is not
understood in most of the commercial product market.   I shopped for a
commercial product by asking this question,

"Example.com moved to Office365, but did not update their SPF record.   How
do I treat their Office365 messages as SPF-PASS without enabling
impersonation from other sources?"


I found many that could not answer.   Vendors do not understand that an
"allow" override for sender-authentication must mimic the original:  Start
with a trusted identifier that is also verified, then use it to
authenticate an unverified identifier which has an expected value and is
received in the same message.  This type of rule has three parts
(independent identifier, verification mechanism, and dependent identifier),
most of the products that I surveyed could only implement single-part
rules.   Single-part rules work well for message blocking, because a
distrusted identifier generally remains untrusted in all contexts and is
untrusted whether true or spoofed.   But using them for allow rules can
undermine security.

This text introduces the concept that when an automated process applies a
uniform disposition to a mix of wanted and unwanted messages, the results
will always be suboptimal.   The only way to achieve optimal results is to
perform a manual review and classification.

Since unverified messages must also pass filters based on source reputation
and content, the expected consequences of allowed impersonation is low.
Consequently, this draft assumes that the automation will only block sender
authentication failure when the probability of a true impersonation has
reached a high value.  I think this assumption should be made explicit
somewhere in the document.

Doug Foster

On Sat, Dec 4, 2021 at 1:52 AM Murray S. Kucherawy 
wrote:

> On Fri, Dec 3, 2021 at 6:16 PM Douglas Foster <
> dougfoster.emailstanda...@gmail.com> wrote:
>
>> I propose that a paragraph along these lines be inserted into the
>> introduction:
>>
>> The DMARC test is characterized by a one-tailed error distribution:
>>  Messages which pass verification have a low probability of being false
>> positives of actual impersonation. When a recipient intends to exempt a
>> high-value sender from content filtering, identity verification ensures
>> that such special treatment can be done safely, without concern for
>> impersonation.However, the same cannot be said about verification
>> failures.  Verification failures can occur for many reasons, and many such
>> messages will be safe and desired by the recipient.   Messages which do not
>> verify are optimally handled with manual review, but this may not be
>> feasible due to message volume.DMARC provides a way for senders and
>> receivers to safely cooperate to minimize the probability that automated
>> disposition decisions will be suboptimal.
>>
>
> I have no objection to adding text such as this.  It's worth noting,
> though, that DKIM certainly says this already (at least in its Section
> 6.1), SPF probably says something similar, and DMARC clearly depends on
> those.  DMARC alludes to this in RFC 7489, Section 10.5, but it's not as
> explicit as what's proposed here.
>
> -MSK
>
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] dmarcbis-04, 5.3. General Record Format 5/5

[Alessandro Vesely]

On Fri 03/Dec/2021 19:38:26 +0100 Todd Herr wrote:

On Fri, Dec 3, 2021 at 12:40 PM Alessandro Vesely  wrote:


last message for today:  the "t" tag instead of "pct".

That's the only part which breaks existing records.  According to the last
paragraph of this section, doing so requires v=DMARC2.



I'm not sure I agree with your assertion here. I'm assuming you're
referring to this paragraph:

Note that given the rules of the previous paragraph, addition of a
new tag into the registered list of tags does not itself require a
new version of DMARC to be generated (with a corresponding change to
the "v" tag's value), but a change to any existing tags does require
a new version of DMARC.



Exactly.



I contend that introducing 't' to replace 'pct' is not a change to an
existing tag but rather an addition of a new tag.



In that case, the definition of pct= must still appear in the spec.  As rfc7489 
is obsoleted, referencing it makes little sense.


I never used it, so it doesn't hurt me if it's discouraged.  However, I suggest 
we take a better survey on the subject, and possibly add to Appendix A7 a 
paragraph suggesting how to proceed to those who now have records with pct=x 
and 0 < x < 100.




If you're contending that removing 'pct' is a change to 'pct', we can have
that conversation, but I don't know that I'd agree with that contention
either. There are other tags, namely 'rf' and 'ri', for which removal has
been proposed and I've not heard anyone contend that either of those
removals would constitute a change requiring a new version.



Formally, you're right.  However, rf= and ri= never had a real effect on the 
behavior of DMARC software.  For ri, I still think it might be possible for a 
report producer to increase the reporting frequency in order to match the 
maximum size.  However, I never heard about frequencies other than 1/24h.



Given also that we discovered use cases that were not considered during 
the hasty discussion that resulted in the decision to change tags, cases

where pct=x with 0 < x < 100 is used as a press, gradually increasing x in
order to urge various departments to comply, exactly as specified in
DMARC1, I appeal to revert that decision. >

We can have this conversation too.



Yes please,



I will promise, however, that if the group decides to keep 'pct', I will
absolutely insist that the first sentence in its definition be changed.
Somehow, RFC 7489 got released with this text: >
pct:  (plain-text integer between 0 and 100, inclusive; OPTIONAL;
   default is 100).  Percentage of messages from the Domain Owner's
   mail stream to which the DMARC policy is to be applied.

And I will go to my grave stating that DMARC policies cannot be applied to
messages that pass DMARC authentication checks, and the definitions of
'quarantine' and 'reject' explicitly refer to messages that fail DMARC
authentication checks.

The sentence should read something like this:

Percentage of messages using the Domain Owner's domain and failing DMARC
authentication checks to which the DMARC policy is to be applied.



That's fine, it doesn't change the substance.  You're right that to make sense 
of the former definition one has to consider the somewhat metaphysical concept 
of applying a policy to messages that pass DMARC authentication.  So your 
definition is better.  Correspondingly, the example should be changed like so:


   if verification fails then
  if (random mod 100) < pct then
 apply policy

BTW, I plotted a couple of graphs based on binomial calculations like yours:
https://en.wikipedia.org/wiki/Bernoulli_sampling#Example


Best
Ale
--











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