Re: [dmarc-ietf] Proposed Introduction and Abstract (was I-D Action: draft-ietf-dmarc-dmarcbis-00.txt)

[Todd Herr <[e-mail]>]

This thread hasn't generated any discussion or momentum yet, and I know
that's not because y'all have found the proposed text for the Abstract and
Introduction to be acceptable, so I'm going to add the text to this thread
and see where the discussion leads.

----------------------------------------------- cut here
----------------------------------------------------

Abstract


   This document describes the Domain-based Message Authentication,

   Reporting, and Conformance (DMARC) protocol.


   DMARC is a scalable mechanism by which a mail-originating

   organization can express domain-level policies and preferences for

   message validation, disposition, and reporting.  Mail-receiving

   organizations can in turn use these expressions of policies and

   preferences to inform their mail handling decisions should they

   choose to do so.


   This document obsoletes RFC 7489.


[...]



1.  Introduction


   RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:

   The source for this draft is maintained in GitHub at:

   https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis

   (https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis)


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

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

   DMARC builds on these protocols.  DMARC is designed to give

   ADminstrative Management Domains (ADMDs) that originate email the

   ability to publish in a DNS TXT record their email authentication

   policies, specify preferred handling for mail that fails

   authentication checks, and request reports about mail purportedly

   originated by the ADMD, as determined by the RFC5322.From header in

   the message.


   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 domain in the

   RFC5322.From header.  In the DMARC protocol, two domains are said to

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

   (a.k.a., relaxed alignment) or they are identical (a.k.a., strict

   alignment).


   A DMARC pass verdict asserts 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 DMARC validation checks

   on inbound mail can choose to use the results and the preferences

   expressed by the originating domain for message disposition to inform

   its mail handling decision for that message.  For messages that pass

   DMARC validation checks, the mail-receiving organization can be

   confident in applying handling based on its known history for

   similarly authenticated messages, whereas messages that fail such

   checks cannot be reliably associated with a domain with a history of

   sending DMARC-validated messages.


   DMARC 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 the ADMD as requested by its 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.



----------------------------------------------- cut here
----------------------------------------------------

On Fri, Nov 13, 2020 at 2:54 PM Todd Herr <[e-mail]> wrote:

> Hi.
>
> I wanted to call everyone's attention to how draft-ietf-dmarc-dmarcbis-00
> differs from the existing RFC 7489.
>
> The key differences are as follows:
>
>    - Section 7, DMARC Feedback, has been mostly removed except for a
>    paragraph that mentions that reporting will be discussed in a different
>    document (as per current plans)
>    - Section 9, Privacy Considerations, has been removed (under the
>    expectation that they'll be discussed in the reporting documents)
>    - Appendix C, DMARC XML Schema, has been removed (under the
>    expectation that it'll be discussed in the the reporting documents)
>    - Remaining target references to "verifying-external-destinations",
>    "failure-reports", and "aggregate-reports", which were anchors in the
>    removed sections mentioned above, have been replaced by hand-wavy language
>    referencing "The DMARC reporting document(s)"
>    - The Abstract and Introduction section have been rewritten as an
>    attempt to address issue #80
>    <https://trac.ietf.org/trac/dmarc/ticket/80> - *DMARCbis Should Have a
>    Clear and Concise Definition of DMARC*
>
> Obviously the text applicable to the first four bullet points above will
> evolve over time, and it may not yet be the right time in the process to
> discuss those sections. However, the proposed new text for the Abstract and
> Introduction is certainly worthy of discussion at this time, I believe.
>
> On Wed, Nov 11, 2020 at 4:55 PM <[e-mail]> wrote:
>
>>
>> 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         : Emil Gustafsson
>>                           Todd M. Herr
>>                           John Levine
>>         Filename        : draft-ietf-dmarc-dmarcbis-00.txt
>>         Pages           : 55
>>         Date            : 2020-11-11
>>
>> Abstract:
>>    This document describes the Domain-based Message Authentication,
>>    Reporting, and Conformance (DMARC) protocol.
>>
>>    DMARC is a scalable mechanism by which a mail-originating
>>    organization can express domain-level policies and preferences for
>>    message validation, disposition, and reporting.  Mail-receiving
>>    organizations can in turn use these expressions of policies and
>>    preferences to inform their mail handling decisions should they
>>    choose to do so.
>>
>>    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-00.html
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>
>
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *e:* [e-mail]
> *p:* 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.
>


-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* [e-mail]
*p:* 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.