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

From: [email-masked]
Date: Wed, 11 Nov 2020 13:54:55 -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         : 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/

---

From: Todd Herr <[email-masked]>
Date: Fri, 13 Nov 2020 14:54:33 -0500

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 <[email-masked]> wrote:

> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> 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:* [email-masked]
*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.

---

From: Gene Hightower <[email-masked]>
Date: Mon, 16 Nov 2020 10:57:39 -0800

From the document:

<https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-00.html:>

> 4.1. Authentication Mechanisms

> The following mechanisms for determining Authenticated Identifiers
> are supported in this version of DMARC: […]

> [RFC3986], which can authenticate both the domain found in an
> [RFC5322] HELO/EHLO command (the HELO identity) and the domain found
> in an SMTP MAIL command (the MAIL FROM identity). DMARC uses the
> result of SPF authentication of the MAIL FROM identity. Section 2.4
> of [RFC7208] describes MAIL FROM processing for cases in which the
> MAIL command has a null path.

RFC-3986 is titled “Uniform Resource Identifier (URI): Generic Syntax.”
I suspect a reference to RFC-7208 was intended here.

RFC-5322 is the standard for the Internet Message Format, which doesn't
have a HELO/EHLO. I suspect a reference to RFC-5321 was intended here.

So, maybe this section should read:

“[RFC7208], which can authenticate both the domain found in an
 [RFC5321] HELO/EHLO command (the RFC5321.HELO identity) and the
 domain found in an SMTP MAIL command (the RFC5321.MailFrom
 identity). DMARC uses the result of SPF authentication of the MAIL
 FROM identity. Section 2.4 of [RFC7208] defines the MAIL FROM
 identity for cases in which the MAIL command has a null path.”

---

From: Todd Herr <[email-masked]>
Date: Wed, 18 Nov 2020 00:35:14 -0500

>  identity for cases in which the MAIL command has a null path.”
Thank you, Gene.

The text in question is taken directly from RFC 7489, so I'll follow up
with the authors of that document to get clarity on what was intended, and
change the new base spec if necessary.

--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 17 Nov 2020 22:54:55 -0800

> I suspect a reference to RFC-7208 was intended here.

This error actually exists in at least two other locations in the document.

-MSK

---

From: Todd Herr <[email-masked]>
Date: Wed, 18 Nov 2020 08:52:47 -0500

> This error actually exists in at least two other locations in the document.
Noted.

I'll open an issue and make sure the document is updated.

--

---

From: Todd Herr <[email-masked]>
Date: Wed, 18 Nov 2020 09:26:04 -0500

> I'll open an issue and make sure the document is updated.

 Issue 84 is open for this - https://trac.ietf.org/trac/dmarc/ticket/84

--

---

From: Todd Herr <[email-masked]>
Date: Thu, 19 Nov 2020 17:55:20 -0500

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

   choose to do so.

[...]

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 <[email-masked]> wrote:

>    - Appendix C, DMARC XML Schema, has been removed (under the
>    expectation that it'll be discussed in the the reporting documents)
>    attempt to address issue #80
>    <https://trac.ietf.org/trac/dmarc/ticket/80> - *DMARCbis Should Have a
>    Clear and Concise Definition of DMARC*
>

--