Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-dmarcbis-04.txt

From: [email-masked]
Date: Thu, 02 Dec 2021 12:54:56 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : Domain-based Message Authentication, Reporting, and Conformance (DMARC)
        Authors         : Todd M. Herr
                          John Levine
	Filename        : draft-ietf-dmarc-dmarcbis-04.txt
	Pages           : 60
	Date            : 2021-12-02

Abstract:
   This document describes the Domain-based Message Authentication,
   Reporting, and Conformance (DMARC) protocol.

   DMARC permits the owner of an email author's domain name to enable
   verification of the domain's use, to indicate the Domain Owner's or
   Public Suffix Operator's message handling preference regarding failed
   verification, and to request reports about use of the domain name.
   Mail receiving organizations can use this information when evaluating
   handling choices for incoming mail.

   This document obsoletes RFC 7489.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-dmarcbis-04

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 11:07:49 +0100

Hi,

the adoption of the PSD extension experiment brought some heavy-handed wording.

>     This document obsoletes RFC 7489.

In the rest of the document, the phrase is shortened to "Domain Owner or PSO", 
which is less clumsy.  Would it be useful to introduce the notion of Domain 
Controller?  It is the entity which can publish records in the relevant zone.

A Domain Owner is a Domain Controller which also manages a mail server.

Using that term, I'd attempt a more readable version of the second paragraph of 
the Abstract like so:

     DMARC permits a Domain Controller to enable verification of the domain
     name usage for designating email authors, to indicate the Domain
     Controller's message handling preference regarding failed verification,
     and to request reports about such usage of the domain name.  Mail
     receiving organizations can use this information when evaluating
     handling choices for incoming mail.

Does it sound better?

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 11:51:27 +0100

Hi,

could we stick to the term *Report Consumer*, please?

The Producer/ Consumer terminology is used in Authentication-Results parlance. 
  It is convenient because the term receiver is inevitably used without 
qualification in several sentences where it is clear from the context (to the 
writer) whether it is a mail receiver or a report receiver.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 12:31:24 +0100

Hi,

I looked up _dmarc.com and got no data, looked up _dmarc.gov.uk and got a DMARC 
record without a psd= tag.  The spec says:

    Once such a record has been found, [...]

That would be a goof place to say:

   If no labels remain and no record with a psd tag with a value of 'y' was
   found, the Organizational Domain can be determined using the procedure
   described in Appendix A6.

Allowing to use the old procedure anyway would account for slow migration 
toward the tree walk, as psd=y tags become ubiquitous and credible.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 13:15:33 +0100

Hi,

this paragraph is fine:

    To illustrate, in relaxed mode, if a verified DKIM signature
    successfully verifies with a "d=" domain of "example.com", and the
    RFC5322.From address is "[email-masked]", the DKIM "d="
    domain and the RFC5322.From domain are considered to be "in
    alignment", because both domains have the same Organizational Domain
    of "example.com".  In strict mode, this test would fail because the
    d= domain does not exactly match the RFC5322.From domain.

However, the following one is deceiving:

    However, a DKIM signature bearing a value of "d=com" would never
    allow an "in alignment" result, as "com" should be identified as a
    PSD and therefore cannot be an Organizational Domain.

Should a PSL-free implementation walk the tree of the d= domain to determine 
the organizational domain of the signature?  That's not necessary.  I'd point 
out something like so:

    Note that, since the signature was verified and the public key retrieved,
    it is sufficient to verify that the signing domain is either the
    Organizational Domain or a subdomain of it.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 13:34:55 +0100

Hi,

I don't understand the second paragraph:

    A Domain Owner or PSO may choose not to participate in DMARC
    evaluation by Mail Receivers simply by not publishing an appropriate
    DNS TXT record for its domain(s).  A Domain Owner can also choose to
    not have some underlying authentication technologies apply to DMARC
    evaluation of its domain(s).  In this case, the Domain Owner simply
    declines to advertise participation in those schemes.  For example,
    if the results of path authorization checks ought not be considered
    as part of the overall DMARC result for a given Author Domain, then
    the Domain Owner does not publish an SPF policy record that can
    produce an SPF pass result.

Trying to dissuade people from participating in SPF or DKIM authentication 
because they don't want DMARC does not convince me.  How about the following:

    Often, a Domain Controller may choose to not participate in DMARC evaluation
    by Mail Receivers simply by not publishing an appropriate DNS TXT record for
    its domain(s).  However, there are cases where its Public Suffix Operator
    (PSO) does publish a DMARC record, which would also involve domains below
    which don't publish a DMARC record.  Although PSOs publishing such records
    presumably know what they're doing, a Domain Owner may still not want to
    participate.  In that case, it can publish a DMARC record overriding policy
    and report dispositions.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 18:36:42 +0100

Hi,

I have five issues on this section.

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.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 18:36:59 +0100

Hi.

The np tag definition looks identical to that of rfc9091, except for the last 
sentence:
                                                              Note that
       "np" will be ignored for DMARC records published on subdomains of
       Organizational Domains and PSDs due to the effect of the DMARC
       policy discovery mechanism described in Section 5.7.2.1.

During a tree walk DMARC records at subdomain may be discovered if the 
subdomain name is short enough.  Old DMARC filters using the PSL will still 
ignore it.  This applies to "sp" definition as well.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 18:38:40 +0100

Hi,

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

It is not yet clear /how/ that information will be used.  In general, what 
information do records found during the tree walk contribute?

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 18:40:00 +0100

Hi,

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.

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.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 3 Dec 2021 18:37:21 +0100

Hi,

we have:

    p:  Domain Owner Assessment Policy (plain-text; RECOMMENDED for
       policy records).  Indicates the message handling preference the
       Domain Owner or PSO has for mail using its domain but not passing
       DMARC verification.  Policy applies to the domain queried and to
       subdomains, unless subdomain policy is explicitly described using
       the "sp" or "np" tags.  This tag is mandatory for policy records
       only, but not for third-party reporting records (see
       [DMARC-Aggregate-Reporting] and [DMARC-Failure-Reporting])
       Possible values are as follows:

RECOMMENDED and mandatory cannot coexist, and subdomain may publish their own 
policy.  Alternative wording:

    p:  Domain Owner Assessment Policy (plain-text; RECOMMENDED for
       policy records).  Indicates the message handling preference the
       Domain Owner or PSO has for mail using its domain but not passing
       DMARC verification.  Policy applies to the domain queried and to
       subdomains, unless a subdomain publishes its own policy or if
       subdomain policy is explicitly described using the "sp" or "np"
       tags.  This tag is ignored for third-party reporting records
       (see [DMARC-Aggregate-Reporting] and [DMARC-Failure-Reporting])
       Possible values are as follows:

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Fri, 3 Dec 2021 13:38:26 -0500

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

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

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.

> urge various departments to comply, exactly as specified in DMARC1, I
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.

-- 

*Todd Herr * | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*m:* 703.220.4153

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.

---

From: "John Levine" <[email-masked]>
Date: 3 Dec 2021 15:46:12 -0500

>paragraph of this section, doing so requires v=DMARC2.

Todd is right.  We're deprecating the pct tag and adding a new t tag.  No new version needed.

R's,
John

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 4 Dec 2021 12:20:22 +0100

>     the "v" tag's value), but a change to any existing tags does require

Exactly.

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

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

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

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 4 Dec 2021 16:01:50 -0500

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Dec 2021 13:30:30 -0800

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Dec 2021 13:31:55 -0800

Argh:

On Sat, Dec 4, 2021 at 1:30 PM Murray S. Kucherawy <[email-masked]>
wrote:

> 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 clown who said this hit "Send" without proofreading.  The original
intent was (b), for the reason given.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 4 Dec 2021 20:12:22 -0800

> That way, fo, rua, and ruf definitions could be moved to the corresponding

Those two paragraphs read identically to me.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 04 Dec 2021 23:50:10 -0500

> 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

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 5 Dec 2021 13:25:31 +0100

On Sat 04/Dec/2021 22:01:50 +0100 Tim Wicinski wrote:
>> In that case, the definition of pct= must still appear in the spec.  As
>> rfc7489 is obsoleted, referencing it makes little sense.
> 

Are they invalid in the sense that Domain Owners should not publish them or 
that receivers should ignore them?  Invalid and deprecated are different 
states.  If we deprecate a tag and explain why, we are compatible with the 
existing base and may keep the same version.

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

The problem is not what pct= means, but how to treat it.  I guess there are 
only a small number of domains who rely on the effect of pct=, but they exist. 
  The following was written in August 2021 by a German admin:

    we're on the way to more then p=none and
    startet with "p=quarantine; pct=10 " more then year ago
    March 2021 we set pct=25 and June 2021 pct=50

    We review the reports once per month and inverstigate findings
    Depending on the current situation we plan to increase pct=

    After the last year we got a signifiant amount of attention.
    Simply because we identified setups that break our plan.
    We offer alternatives, give time for implementation and get positive
    feedback.

    I'm optimistic to step forward up to pct=99 and finally p=reject.
    but not this year

The usual way to deprecate features is to still support them for a good while, 
possibly issuing warnings.  Instead, the current draft seems to be eliminating 
pct= abruptly.  That would be a change.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 6 Dec 2021 11:21:09 +0100

On Sat 04/Dec/2021 22:30:30 +0100 Murray S. Kucherawy wrote:
> On Fri, Dec 3, 2021 at 10:38 AM Todd Herr <todd.herr= wrote:
> 

I implemented (a), and don't understand how (b) can make sense given:

                                                                However,
       this MUST NOT be applied to the DMARC-generated reports, all of
       which must be sent and received unhindered.

In order to compile DMARC result into the report one must first evaluate it.

Besides, after checking SPF and DKIM, the cost of evaluating DMARC boils down 
to compare two strings for alignment.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 6 Dec 2021 13:45:15 +0100

Hi,

I have a few nits about this section:

    This section describes Domain Owner actions to fully implement the
    DMARC mechanism.

Actually, the section doesn't mention DMARC checking, adhering to policies 
found in DMARC records, and sending feedback reports.  Hence I'd strike 
"fully".  It describes sender side actions.

    While it is possible to secure a DMARC pass verdict based on only SPF
    or DKIM, it is commonly accepted best practice to ensure that both
    authentication mechanisms are in place in order to guard against
    failure of just one of them.

SPF normally fails on forwarding.  Should we mention that?

                                  The Domain Owner SHOULD choose a DKIM-
    Signing domain (i.e., the d= domain in the DKIM-Signature header)
    that aligns with the Author Domain and configure its system to sign
    using that domain, to include publishing a corresponding DKIM public
    key in DNS.

Maybe it's me, but I cannot understand "to include" in the last phrase of that 
sentence.

                           Should any overlooked systems be found in the
    reports, the Domain Owner can adjust the SPF record and/or configure
    DKIM signing for those systems.

I'd s/overlooked systems/failures/, since surprises can also arise from systems 
that the Domain Owner considered to have been set up well.

Best
Ale
--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 6 Dec 2021 13:47:49 +0100

Hi,

    The domain in the RFC5322.From header field is extracted as the
    domain to be evaluated by DMARC.  If the domain is encoded with UTF-
    8, the domain name must be converted to an A-label, as described in
    Section 2.3 of [RFC5890], for further processing.

Why?  That paragraph is almost identical to its 7489 version.  However, since 
then, RFC 8616 established that d= in DKIM signatures is a U-label.  In that 
case, to check alignment, the domain name must be converted to U-label.  Of 
course, to perform a DNS lookup names must be converted to A-label.  To use the 
PSL, for those who do, names must be converted to U-label.  In one sentence, a 
verifier must be prepared to convert domain names as needed.

I'd just strike that paragraph.

                   Multi-valued RFC5322.From header fields with multiple
    domains MUST be exempt from DMARC checking.

Cannot we do better than that?  Adding a second author to a message, in such a 
way that it goes unnoticed when displayed by a MUA, can be an attack path. 
Possible alternatives:

* Check the domain of the first mailbox,

* Check all the domains, all must pass.

Best
Ale
--

---

From: Todd Herr <[email-masked]>
Date: Mon, 6 Dec 2021 08:35:10 -0500

> "fully".  It describes sender side actions.
"fully" was left over from a previous attempt to address
https://trac.ietf.org/trac/dmarc/ticket/66

It will be stricken from the next rev.

> SPF normally fails on forwarding.  Should we mention that?

I don't know if it's necessary. SPF breaking due to forwarding is a
well-known condition, and I don't think it has to be documented in every
text that mentions SPF.

For what it's worth, the introductory text to section 5 and the text in
Appendix B.3.1 both hint at forwarding causing authentication problems.

> Maybe it's me, but I cannot understand "to include" in the last phrase of
This was a ham-fisted attempt on my part to mimic text from the preceding
paragraph on SPF.

Section 5.5.1, Publish an SPF Policy for an Aligned Domain, includes this
sentence:

"As a first step the Domain Owner SHOULD choose a domain to use as the
RFC5321.MailFrom domain (i.e., the Return-Path domain) for its mail, one
that aligns with the Author Domain, and then publish an SPF policy in DNS
for that domain."

So, in Section 5.5.2, Configure Sending System for DKIM Signing Using an
Aligned Domain, I was going for similar phrasing to express the idea "Do
the authentication stuff, and publish something in DNS to make it work."

I'll have to think about how to word that better.

> that the Domain Owner considered to have been set up well.

How about:

"Should any authentication failures for systems under the Domain Owner's
control be found in the reports, the Domain Owner can adjust the SPF record
and/or configure DKIM signing for those systems."

--

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 14:07:38 +0000

>On Mon, Dec 6, 2021 at 7:45 AM Alessandro Vesely <[email-masked]> wrote:
...
>and/or configure DKIM signing for those systems."
Have mercy for the poor admins whose bosses will waive this at them and demand they "fix" all the issues in their failure reports.  Most cases of DMARC failure are outside the control of the sending domain and this doesn't seem to acknowledge that at all.  Yes, maybe the DNS group decided one day to prettify their zone files by lower casing everything and now everything is getting a DKIM fail, but usually it's a problem elsewhere.

Maybe add "caused by local misconfiguration or omission" after authentication failures?

Scott K

---

From: Todd Herr <[email-masked]>
Date: Mon, 6 Dec 2021 11:40:47 -0500

On Mon, Dec 6, 2021 at 9:08 AM Scott Kitterman <[email-masked]> wrote:

> Have mercy for the poor admins whose bosses will waive this at them and
> demand they "fix" all the issues in their failure reports.  Most cases of
> DMARC failure are outside the control of the sending domain and this
> doesn't seem to acknowledge that at all.  Yes, maybe the DNS group decided
> one day to prettify their zone files by lower casing everything and now
> everything is getting a DKIM fail, but usually it's a problem elsewhere.
>
In the interests of future-proofing, should there ever be additional
underlying authentication protocols, I propose this:

Should any authentication failures for systems

under the Domain Owner's control be found in the reports, in cases

where the failures are caused by local misconfiguration or omission

the Domain Owner can take steps to address such failures.

--

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 6 Dec 2021 18:38:08 +0100

On Mon 06/Dec/2021 17:40:47 +0100 Todd Herr wrote:
>> On December 6, 2021 1:35:10 PM UTC, Todd Herr wrote:
>>>> I'd s/overlooked systems/failures/, since surprises can also arise
>>>> from systems that the Domain Owner considered to have been set up
>>>> well. >>>
>>> How about:
>>>
>>> "Should any authentication failures for systems under the Domain
>>> Owner's control be found in the reports, the Domain Owner can adjust the
>>> SPF record and/or configure DKIM signing for those systems." >>>
>    Should any authentication failures for systems under the Domain Owner's
>    control be found in the reports, in cases where the failures are caused by
>    local misconfiguration or omission the Domain Owner can take steps to
>    address such failures.

That's very generic and almost works.  Could we add "peculiarity" (or a better 
word) for cases where there's nothing wrong but amendments are possible?  That is:

     Should any authentication failures for systems under the Domain Owner's
     control be found in the reports, in cases where the failures are caused by
     local peculiarity, misconfiguration or omission the Domain Owner can
     take steps to address such failures.

For example, DKIM signing with strict/strict canonicalization is not a 
misconfiguration, but switching to relaxed/strict can survive a forwarder which 
reflows header fields.

Best
Ale
--

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 12:38:36 -0500

On Monday, December 6, 2021 11:40:47 AM EST Todd Herr wrote:
> > On December 6, 2021 1:35:10 PM UTC, Todd Herr <todd.herr=
> > 
> > >control be found in the reports, the Domain Owner can adjust the SPF
> > 
> > record
> > 

I think that's good.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 6 Dec 2021 10:01:51 -0800

>> the Domain Owner can take steps to address such failures.

Sorry, but I think it's not.

1.  A specification should specify.  It should specify things that are 
concrete, precise, reliably actionable, and generally produce the same 
understanding across widely differing readers. Specification language 
that does not satisfy the list in the preceding sentence is not a 
specification.  Rather it is commentary.

2. When a specifications says that something vague and operational is 
allowed or not allowed, consider whether it would be meaningful to 
switch the bit.  The above text is saying that local problems are 
allowed to be fixed by taking local action. Could it make sense here to 
prohibit taking that action?  I sure hope not.  So this text is, really, 
entirely gratuitous.  It purports to be saying something useful, but it 
isn't.

3. IETF specification culture is quite nice in also allowing commentary 
about background or use or 'issues' with the specification.  The 
downside is that this often produces text that is, really, none of the 
things listed in the preceding sentence. Rather, it is language that 
might feel comfortable to the authors but has no practical utility.

On 12/6/2021 5:35 AM, Todd Herr wrote:
> well-known condition, and I don't think it has to be documented in 
> every text that mentions SPF.

Kudos for that point.

4. Duplication of specification details or commentary text invites 
divergence and/or misunderstanding. Sometimes a caution is helpful, not 
not when it is long-standing issue with another specification and is 
already well-understood.  To the extent that there is a continuing 
concern about the reader's understanding the fact of the caution, there 
should be a basic pointer, early in the specification, to material that 
discusses this (other) specification.

The problems here come from good intentions, but from the problematic 
view that adding bits of vague or redundant text will provide meaningful 
protection against the points of concern.  They won't.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
[email-masked]

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 13:06:58 -0500

> protection against the points of concern.  They won't.

OK.  What's your recommendation then?

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 6 Dec 2021 10:39:17 -0800

> OK.  What's your recommendation then?

Scott,

I think my note contained a series of very basic recommendations.  I'm 
not sure what else you are looking for.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 18:48:11 +0000

>not sure what else you are looking for.

What text (if any) would you suggest there?

I understand you don't like what's there, but not how you think it should be changed.  The proposed revision addresses the concern I had raised.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Mon, 6 Dec 2021 10:59:19 -0800

> I understand you don't like what's there, but not how you think it should be changed.  The proposed revision addresses the concern I had raised.

If a sentence or a paragraph is not providing necessary specification 
and is not providing necessary clarification and is not providing useful 
guidance, then drop that text.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 06 Dec 2021 14:10:35 -0500

On Monday, December 6, 2021 1:59:19 PM EST Dave Crocker wrote:
> > I understand you don't like what's there, but not how you think it should
> > be changed.  The proposed revision addresses the concern I had raised.

Thanks.  I think that's fine too.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 6 Dec 2021 14:52:15 -0500

>I'd just strike that paragraph.

If you have EAI mail, which you do if you have a UTF-8 domain in a From header, the U-label form is preferred.

It'd be better to say that in an EAI environment, A-labels and U-labels are equivalent,
and per RFC 8616 you should use the U-label in A-R headers.  Don't have a strong opinion
about what goes into the reports but in aggregate reports, A-labels would likely surprise
fewer people.

R's,
John