Subject: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

From: Todd Herr <[email-masked]>
Date: Wed, 5 May 2021 14:48:51 -0400

Greetings.

This thread will be used to track discussion of the proposed text for the
Introduction section of draft-ietf-dmarc-dmarcbis-01.

The proposed text was influenced not only by the original text from
draft-ietf-dmarc-dmarcbis-00, but also by tickets 52, 75, 80, 85, 96 and
108. Rather than trying to track changes to the Introduction section
through all six of those tickets, a new one (Ticket 113
<https://trac.ietf.org/trac/dmarc/ticket/113>) has been opened.

The request from the design team/editors for this ticket is as follows:

If you object to some or all of the proposed text, please communicate the
part(s) to which you object, and propose replacement text for those part(s).

We would like to achieve rough consensus on this section of text by Friday,
May 21.

Current proposed text follows, and side-by-side diffs with version -00 can
be found here
<https://www.ietf.org/rfcdiff?url1=draft-ietf-dmarc-dmarcbis-00&url2=draft-ietf-dmarc-dmarcbis-01&difftype=--html>

------------------------------------begin current proposed text
-----------------------------------
1. Introduction

   The Sender Policy Framework ([RFC7208]) and DomainKeys Identified

   Mail ([RFC6376]) protocols provide domain-level authentication which

   is not directly associated with the RFC5322.From domain, and DMARC

   builds on those protocols.  Using DMARC, Domain Owners that originate

   email can publish a DNS TXT record with their email authentication

   policies, state their level of concern for mail that fails

   authentication checks, and request reports about email use of the

   domain name.  Similarly, Public Suffix Operators (PSOs) may do the

   same for PSO Controlled Domain Names and non-existent subdomains of

   the PSO Controlled Domain Name.

   As with SPF and DKIM, DMARC authentication checks result in verdicts

   of "pass" or "fail".  A DMARC pass verdict requires not only that SPF

   or DKIM pass for the message in question, but also that the domain

   validated by the SPF or DKIM check is aligned with the RFC5322.From

   domain.  In the DMARC protocol, two domains are said to be "in

   alignment" if they have the same Organizational Domain.

   A DMARC pass result indicates only that the RFC5322.From domain has

   been authenticated in that message; there is no explicit or implied

   value assertion attributed to a message that receives such a verdict.

   A mail-receiving organization that performs a DMARC validation check

   on inbound mail can choose to use the result and the published

   severity of concern expressed by the Domain Owner or PSO for

   authentication failures to inform its mail handling decision for that

   message.

   For a mail-receiving organization supporting DMARC, a message that

   passes validation is part of a message stream that is reliably

   associated with the Domain Owner and/or any, some, or all of the

   Authenticated Identifiers.  Therefore, reputation assessment of that

   stream by the mail-receiving organization does not need to be

   encumbered by accounting for unauthorized use of any domains.  A

   message that fails this validation cannot reliably be associated with

   the Domain Owner's domain and its reputation.

   DMARC, in the associated [DMARC-Aggregate-Reporting] and

   [DMARC-Failure-Reporting] documents, also describes a reporting

   framework in which mail-receiving domains can generate regular

   reports containing data about messages seen that claim to be from

   domains that publish DMARC policies, and send those reports to one or

   more addresses as requested by the Domain Owner's or PSO's DMARC

   policy record.

   Experience with DMARC has revealed some issues of interoperability

   with email in general that require due consideration before

   deployment, particularly with configurations that can cause mail to
   be rejected.  These are discussed in Section 9.
-------------------------------------end current proposed text
-----------------------------------

Thank you for your time.

-- 

*Todd Herr* | Sr. Technical Program Manager
*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: Alessandro Vesely <[email-masked]>
Date: Thu, 6 May 2021 11:47:13 +0200

Todd,

does your message assume that the relevant tickets are all accepted as valid 
indications to alter the spec?  In particular, tickets #52 and #75 have never 
been discussed on list. I'd guess they'll have to be discussed in their own 
threads.

Discussing the resulting text before those tickets entails, for example, noting 
the cumbersomeness of the locution "severity of concern" where something like 
"desired disposition" might seem more immediate.  In fact, ticket #85 was only 
discussed as a side effect of ticket #39, where the consensus, IIRC, was to 
keep the existing policy names while wavering about how to describe them.

The term RFC5322.From is consistently used, notwithstanding ticket #96.  For an 
alternative, let me attempt to define DMARC in terms of its acronym:

    The Domain-based Message Authentication, Reporting, and Conformance (DMARC)
    protocol recognizes the prevailing importance of the domain appearing in the
    From: header field of email messages.  That domain name will be called the
    Main Identifier in this document.  DMARC leverages the Sender Policy
    Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376]) protocols
    by focusing the authentication mechanisms they provide toward the Main
    Identifier.  The Domain Owners corresponding to the Main Identifier are
    endowed with the possibility to receive feedback reports about
    authentication results at receivers.  Finally, receivers are provided with
    the Domain Owners' desiderata about messages that fail authentication, which
    receivers may or may not decide to conform to.

jm2c
Ale
-- 

On Wed 05/May/2021 20:48:51 +0200 Todd Herr wrote:
> draft-ietf-dmarc-dmarcbis-00, but also by tickets 52, 75, 80, 85, 96 and 108. 
> Rather than trying to track changes to the Introduction section through all six 
> of those tickets, a new one (Ticket 113 
> We would like to achieve rough consensus on this section of text by Friday, May 21.
> 
> Current proposed text follows, and side-by-side diffs with version -00 can be 
> found here 
> builds on those protocols.Using DMARC, Domain Owners that originate
> 
> domain name.Similarly, Public Suffix Operators (PSOs) may do the
> 
> of "pass" or "fail".A DMARC pass verdict requires not only that SPF
> 
> domain.In the DMARC protocol, two domains are said to be "in
> 
> Authenticated Identifiers.Therefore, reputation assessment of that
> 
> encumbered by accounting for unauthorized use of any domains.A
> 
> be rejected.These are discussed in Section 9.
> *Todd Herr*| Sr. Technical Program Manager
> *e:[email-masked] <mailto:[email-masked]>
> *m:*703.220.4153
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Todd Herr <[email-masked]>
Date: Thu, 6 May 2021 08:21:46 -0400

> been discussed on list. I'd guess they'll have to be discussed in their

I don't know if each of those individual tickets has to be discussed in
their own threads or not, and I think it's more a decision for the chairs
to make than for the editors or the working group, but I could be very
wrong about that.

What I will say is this:

   - The design team went off and effectively created a new version of
   draft-ietf-dmarc-dmarcbis, specifically draft-ietf-dmarc-dmarcbis-01. It is
   proposed text, nothing more, nothing less.
   - The design team's work was influenced by those tickets which
   currently show a status of 'infoneeded'.
   - Due to the nature of the text, both of the following are true:
      - Most, but perhaps not all, of the 'infoneeded' tickets had impacts
      on multiple sections of draft-ietf-dmarc-dmarcbis-01
      - Most of the changes to sections of draft-ietf-dmarc-dmarcbis-00
      that were made in producing draft-ietf-dmarc-dmarcbis-01 were
influenced by
      multiple tickets

Back on April 23, when I posted here about setting expectations, I thought
at the time that adjudicating each of the infoneeded tickets might be the
way to go, but upon further reflection I'm not sure that's the case, since
it can be argued that those tickets were created against a work product
that no longer exists. It's also true that because those tickets affect the
wording in multiple sections of the document, adjudicating the -00 tickets
can theoretically result in a morass of edits made across multiple sections
of -01 and subsequent revisions, and everyone eventually losing the plot.

Chairs, your thoughts?

>     receivers may or may not decide to conform to.
As I stated above, I believe the better path for the working group is to
adjudicate draft-ietf-dmarc-dmarcbis-01. That revision contains a section
labeled "Introduction", you have proposed alternate text for that section,
let's discuss that section on the list, come to a consensus, and do it all
under the auspices of ticket 113.

But that's just my opinion...

--

---

From: Dotzero <[email-masked]>
Date: Thu, 6 May 2021 12:55:44 -0400

Overall I'm comfortable with the introduction verbiage. I do have one
concern:

"For a mail-receiving organization supporting DMARC, a message that

   encumbered by accounting for unauthorized use of any domains."

My concern is with "does not need to be encumbered by accounting for
unauthorized use of any domains". This ignores cases such as DNS hijacking
and domain compromise. Perhaps changing it to "does not need to be
encumbered by accounting for unauthorized use of any domains by 3rd party
senders" or  "does not need to be encumbered by accounting for unauthorized
use of any domains by 3rd party originators"

Michael Hammer

On Thu, May 6, 2021 at 8:22 AM Todd Herr <todd.herr=
[email-masked]> wrote:

>       - Most, but perhaps not all, of the 'infoneeded' tickets had
>       impacts on multiple sections of draft-ietf-dmarc-dmarcbis-01
>       that were made in producing draft-ietf-dmarc-dmarcbis-01 were influenced by
>       multiple tickets
>