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

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Jun 2021 17:27:17 -0700

On 5/5/2021 11:48 AM, Todd Herr wrote:
>
>
> We would like to achieve rough consensus on this section of text by 
> Friday, May 21.

Apologies.  I've only just been able to review this text. Attached are 
suggested changes, done as a Word document with revision tracking turned on.

It might appear that the edits effect major substance changes to the 
Introduction, but I believe they do not; the intent was to retain the 
same goals for the Introduction.

Changes were driven by:

  * Providing better lead-in for readers with less background on the
    document's topic
  * Eliminating detail that is not need in an introduction
  * Minimizing PSO text, since I belive the covered domains have Domain
    Owners whether they are PSOs or not; hence the fact of being a PSO
    has minimal import in the Introduction
  * General wordsmithing, to tighten things up

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

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

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Jun 2021 19:45:58 -0700

> We would like to achieve rough consensus on this section of text by 

Apologies.  I've only just been able to review this text. Here's a link 
to suggested changes, done as a Word document with revision tracking 
turned on:

    https://www.dropbox.com/s/qmp2t5n1g99l9wj/DMARCbis-Intro-dcrocker.docx?dl=0

Changes were driven by:

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Jun 2021 19:50:22 -0700

(this time without an attachment...)

    (I suggest looking at the document without the revision tracks being
    displayed.)

Changes were driven by:

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Thu, 3 Jun 2021 19:55:40 -0700

> (this time without an attachment...)

Interesting.  My own MUA is not showing a received copy of any of my 
postings of the message through the IETF list.  Hence the re-sends, 
guessing at why not.

Finally looked at the IETF's IMAP archive and there they all are. 
Curious.  Anyhow, another round of apologies.

d/
-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Todd Herr <[email-masked]>
Date: Tue, 8 Jun 2021 11:10:03 -0400

On Thu, Jun 3, 2021 at 8:27 PM Dave Crocker <[email-masked]> wrote:

> Introduction, but I believe they do not; the intent was to retain the same
> goals for the Introduction.
>
> Changes were driven by:
>
>    - Providing better lead-in for readers with less background on the
>    document's topic
>    - Eliminating detail that is not need in an introduction
>    - Minimizing PSO text, since I belive the covered domains have Domain
>    Owners whether they are PSOs or not; hence the fact of being a PSO has
>    minimal import in the Introduction
>    - General wordsmithing, to tighten things up
>
>
> Taking most of Dave's input into account results in an Introduction
section that will read as follows:

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

   Abusive email often includes unauthorized and deceptive use of a

   domain name in the RFC5322.From header field.  The domain typically

   belongs to an organization expected to be known to - and presumably

   trusted by - the recipient.  The Sender Policy Framework ([RFC7208])

   and DomainKeys Identified Mail ([RFC6376]) protocols provide domain-

   level authentication but are not directly associated with the

   RFC5322.From domain.  DMARC leverages them, so that Domain Owners

   publish a DNS record indicating their RFC5322.From field:

   *  Email authentication policies

   *  Level of concern for mail that fails authentication checks

   *  Desire for reports about email use of the domain name

   DMARC can cover non-existent sub-domains, below the "Organizational

   Domain", as well as domains at the top of the name hierarchy,

   controlled by Public Suffix Operators (PSOs).

   As with SPF and DKIM, DMARC classes results as "pass" or "fail".  A

   pass from either SPF or DKIM is required.  Also the passed domain

   must be "aligned" with the RFC5322.From domain.  Domains are said to

   be "in alignment" if they have the same Organizational Domain, which

   is at the top of the domain hierarchy, while having the same

   administrative authority as the RFC5322.From domain.

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

   authenticated for that message.  Of course, authentication does not

   carry an explicit or implicit value assertion about that message or

   about the Domain Owner.  Indeed, a mail-receiving organization that

   performing DMARC validation can choose to follow the Domain Owner's

   requested disposition for authentication failures, and to inform the

   Domain Owner of the mail handling decision for that message.  It also

   might choose different actions.

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

   passes validation is part of a message stream that is reliably

   associated with the RFC5322.From field Domain Owner.  Therefore,

   reputation assessment of that stream by the mail-receiving

   organization is not encumbered by accounting for unauthorized use of

   that domain in the RFC5322.From field.  A message that fails this

   validation is not necessarily associated with the Domain Owner's

   domain and its reputation.

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

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

   framework.  Using it, a mail-receiving domain can generate regular

   reports about messages that claim to be from a domain publishing

   DMARC policies, sending those reports to the addresses specified by

   the Domain Owner.

   Use of DMARC creates some interoperability challenges 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
-----------------------------------

I expect that discussion of this topic will continue for some 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.