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

[Todd Herr <[e-mail]>]

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:* [e-mail]
*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.