Domain-based Message Authentication, Reporting, and Conformance (DMARC)
draft-ietf-dmarc-dmarcbis-41

[Ballot discuss]
(same ballot for -38 and -39)

** Section 9.3. and 9.4.  Status column

-- Section 9.3 “Each registration includes the tag name; the specification that defines it; a brief description; and its status, which is one of "current", "experimental", or "historic".”

-- Section 9.4 “In addition to a reference to a permanent specification, each registration    includes the format name, a brief description, and its status, which must be one of "current", "experimental", or "historic".”

The status column was defined in RFC7489 and already in the existing IANA registries.  However, there doesn't appear to be adequate guidance on setting and using it.  Specifically:

(1) What are the criteria used to set a particular code point to “current”, “experimental” or “historical” status?  There is no guidance for the designated expert.

It can’t be the status of a given RFC since the registration procedure is “specification required” allowing for non-RFC documents.  Section 9.3 appears to be updating the registry to amend existing code points to historic status (e.g., pct, rf, ri) so the WG must have some intuition that would benefit from being document here.

(2) What does experimental or historic signal to implementers?  What do they do with this information?

[Ballot comment]
Thanks for the DMARC-bis, it is even a mostly full rewrite!

I second Paul Wouters' wish that the document had an Operational Considerations Section that explained the pitfalls of DMARC, as section 7.4 does not bring a lot of solutions.

Finally, the example in the appendix are dated 2002...

[Ballot comment]
Thank you for the work on this document.

I wanted to acknowledge the point, particularly controversial, brought up by several people, if this document belongs to the standard track, but I agree that the rough consensus is to publish the document as standard track. I also wanted to say I appreciate the work of the authors and the working group to describe the interoperability considerations and issues.

[Ballot comment]
I wish the document had an Operational Considerations Section that explained the pitfalls of DMARC, eg the issues with mailing lists or alias expanders (eg like we suffer from at IETF itself). It could perhaps recommend something (eg support for From rewriting as commonly done). It feels just declaring the pain points "out of scope" is a bit of a weak solution.



* Signing DNS records with Domain Name System Security Extensions
  (DNSSEC) [RFC4033], which enables recipients to validate the
  integrity of DNS data and detect and discard forged responses.

Please use RFC9364 or BCP237 as the proper reference to DNSSEC.

[Ballot discuss]
** Section 9.3. and 9.4.  Status column

-- Section 9.3 “Each registration includes the tag name; the specification that defines it; a brief description; and its status, which is one of "current", "experimental", or "historic".”

-- Section 9.4 “In addition to a reference to a permanent specification, each registration    includes the format name, a brief description, and its status, which must be one of "current", "experimental", or "historic".”

The status column was defined in RFC7489 and already in the existing IANA registries.  However, there doesn't appear to be adequate guidance on setting and using it.  Specifically:

(1) What are the criteria used to set a particular code point to “current”, “experimental” or “historical” status?  There is no guidance for the designated expert.

It can’t be the status of a given RFC since the registration procedure is “specification required” allowing for non-RFC documents.  Section 9.3 appears to be updating the registry to amend existing code points to historic status (e.g., pct, rf, ri) so the WG must have some intuition that would benefit from being document here.

(2) What does experimental or historic signal to implementers?  What do they do with this information?

[Ballot comment]
Thank you to Ines Robles for the GENART review.

** Section 4.7
  v:  Version (plain-text; REQUIRED).  Identifies the record retrieved
      as a DMARC Policy Record.  It MUST have the value of "DMARC1".
      The value of this tag MUST match precisely;

What does it mean to “match precisely”?  Is this saying a case-sensitive match to “DMARC1”?  I ask because the meaning of the two sentences isn’t clear to me.

Isn’t this first normative MUST duplicative to the ABNF in Section 4.8 (i.e., “dmarc-version = "v" equals %s"DMARC1"”)

** Section 4.6
(a)    v:  Version (plain-text; REQUIRED).  Identifies the record retrieved
      as a DMARC Policy Record.  It MUST have the value of "DMARC1".
      The value of this tag MUST match precisely; if it does not or it
      is absent, the entire record MUST be ignored.  It MUST be the
      first tag in the list.

(b)  A DMARC Policy Record MUST comply with the formal specification found
  in Section 4.8 in that the "v" tag MUST be present and MUST appear
  first.

Isn’t there duplication here.  Both (a) and (b) say that v must appear first AND is required.

** Section 5.4
  Mail Receivers are encouraged to maintain anti-abuse technologies to
  combat the possibility of DMARC-enabled criminal campaigns.

No issues with the sentiment.  However, is the WG confident that “criminal campaigns” isn’t too narrow?  For example, what about DMARC-enabled espionage campaigns?  Could this sentence read (roughly) “Mail Receivers are encouraged to maintain anti-abuse technologies to mitigate the possibility of DMARC-enabled abuse”?

** Section 9.2
  IANA has added the following in the "Email Authentication Result
  Names" registry:

-- There are already entries for these Auth Methods.  Shouldn’t the guidance be to replace the reference for them to this document?

-- The current references for each of these Auth Methods includes a section number for RFC7489.  Should section numbers be added for each reference here?

** Section 9.3
  The set of entries to be defined in this registry is as follows:

As above, the current registry has already registered all of these.  The key detail is that some have had their status changed and an updated reference is needed.

Same comment for Section 9.4

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-dmarc-dmarcbis-38
CC @OR13

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-38.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

Thanks to Scott Hollenbeck for the ART ART Review.

## Comments

### use of reports

```
296   Domain Owners can use these reports, especially the aggregate
297   reports, not only to identify sources of mail attempting to
298   fraudulently use their domain, but also (and perhaps more
299   importantly) to flag and fix gaps in their own authentication
300   practices.  However, as with honoring the Domain Owner's stated mail
```

How common is it to receive information in these reports that is impossible to fix?
In other words, are these reports generating alert fatigue more often than they are helping identify real threats?
There is also the question of the cost(cpu/memory/traffic/sustainability) of sending the reports.

### double negative reads awk

```
726   from any domain, even one used by a bad actor.  A DKIM-Authenticated
727   Identifier that does not have Identifier Alignment with the Author
728   Domain is not enough to validate whether the use of the Author Domain
729   has been authorized by its Domain Owner.
```

does not have + is not enough to ... makes this difficult to read.

BCP14 language might be a better fit for describing the interoperability supported by alignment in 4.4.1 and 4.4.2.

### What is recommended?

```
816   Author Domain.  Neither approach is recommended, however.
```

I assume:

It is RECOMMENDED to enable both DKIM and SPF.


### MUST NOT change p=none

```
1514   Identifiers being unaligned or missing entirely.  For such legitimate
1515   uses, these shortcomings MUST be addressed prior to any attempt by
1516   the Domain Owner to publish a Domain Owner Assessment Policy
1517   (#domain-owner-policy) of Enforcement (#enforcement) for the Author
1518   Domain.
```

How does this MUST achieve interoperability?

The way I read this, it is a directive to not change "p=none" until all legitimate use is absent from reports.

Section 7.4 makes this guidance even clearer, but uses SHOULD instead of MUST.

### MAY -> SHOULD NOT

```
1712   Per-message failure reports can be a useful source of information for
1713   a Domain Owner, either for debugging deployments or in analyzing
1714   attacks, and so Mail Receivers MAY choose to send them.  Experience
1715   has shown, however, that Mail Receivers rightly concerned about
1716   protecting user privacy have either chosen to heavily redact the
1717   information in such reports (which can hinder their usefulness) or
1718   not send them at all.  See [I-D.ietf-dmarc-failure-reporting] for
1719   further information.
```

This MAY reads to me as a SHOULD NOT, given the privacy risk can the guidance be strengthened?

### MAY / SHOULD ... accept / reject

```
1735   Mail Receivers MAY choose to accept email that fails the DMARC
1736   validation check even if the published Domain Owner Assessment Policy
1737   is "reject".  In particular, because of the considerations discussed
1738   in [RFC7960] and in Section 7.4 of this document, it is important
1739   that Mail Receivers SHOULD NOT reject messages solely because of a
1740   published policy of "reject", but that they apply other knowledge and
1741   analysis to avoid situations such as rejection of legitimate messages
1742   sent in ways that DMARC cannot describe, harm to the operation of
1743   mailing lists, and similar.
```

The guidance here regarding reject feels like a weak point in the document.
In context, this reads as "reject" is NOT RECOMMENDED, and if present MAY be ignored.
It is RECOMMENDED to ignore it, when "other knowledge" enables legitimate messages to be distinguished?

### normative guidance on 4xy dmarc reject

```
1857   If a Mail Receiver elects to defer delivery due to the inability to
1858   retrieve or apply DMARC policy, this is best done with a 4xy SMTP
1859   reply code.
```

Should this guidance be normative?

### Stronger guidance on encryption

```
2399 11.7.  Secure Protocols

2401   This document encourages the use of secure transport mechanisms to
2402   prevent the loss of private data to third parties that may be able to
2403   monitor such transmissions.  Unencrypted mechanisms should be
2404   avoided.

2406   In particular, a message that was originally encrypted or otherwise
2407   secured might appear in a report that is not sent securely, which
2408   could reveal private information.
```

Is it possible to strengthen the guidance here (MUST / SHOULD)?

## Nits

### An attacker is... ?

```
2460   *  An is able to send mail with the Author Domain of
2461       "evil.example.com" and an Authenticated Identifier of
2462       "mail.example.com"
```

### with -> which

```
1512   uses, as in the case of a mail stream created by an agent of the
1513   Domain Owner but one with is not passing is due to Authenticated
```

### size?

```
1052                 ; Obsolete syntax, reporters should ignore the
1053                 ; size if it is found in a DMARC Policy Record.
```

Not sure what size is referring too.

### Please no anchor references in abstract

```
16   DMARC permits the owner of an email's Author Domain (#author-domain)
17   to enable validation of the domain's use, to indicate the Domain
18   Owner's (#domain-owner) or Public Suffix Operator's (#public-suffix-
19   operator) message handling preference regarding failed validation,
20   and to request reports about the use of the domain name.  Mail
21   receiving organizations can use this information when evaluating
22   handling choices for incoming mail.
```

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-dmarc-dmarcbis-36. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there are seven actions which we must complete.

First, in the Email Authentication Methods registry in the Email Authentication Parameters registry group located at:

https://www.iana.org/assignments/email-auth/

two existing methods will have their references changed as follows:

Method: dmarc
Definition: [ RFC-to-be ]
ptype: header
Value: the domain portion of the RFC5322.From field

Method: dmarc
Definition: [ RFC-to-be ]
ptype: policy
Value: Evaluated DMARC policy applied/to be applied after policy options including pct: and sp: have been processed. Must be none, quarantine, or reject.

Second, in the Email Authentication Result Names registry also in the Email Authentication Parameters registry group located at:

https://www.iana.org/assignments/email-auth/

five results will have their references changed as follows:

Auth Method(s): dmarc
Code: fail
Specification: [ RFC-to-be ]
Status: active

Auth Method(s): dmarc
Code: none
Specification: [ RFC-to-be ]
Status: active

Auth Method(s): dmarc
Code: pass
Specification: [ RFC-to-be ]
Status: active

Auth Method(s): dmarc
Code: permerror
Specification: [ RFC-to-be ]
Status: active

Auth Method(s): dmarc
Code: temperror
Specification: [ RFC-to-be ]
Status: active

Third, in the Feedback Report Header Fields registry in the Messaging Abuse Reporting Format (MARF) Parameters registry group located at:

https://www.iana.org/assignments/marf-parameters/

the existing registration below will have its reference changed to [ RFC-to-be ]:

Field Name: Identity-Alignment
Description: indicates whether the message about which a report is being generated had any identifiers in alignment

Fourth, the Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters registry group located at:

https://www.iana.org/assignments/dmarc-parameters/

will be updated to have all references changed from existing references to [ RFC-to-be ].

Fifth, the DMARC Tag Registry in the Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters registry group located at:

https://www.iana.org/assignments/dmarc-parameters/

is to be completely replaced by the following registrations:

Tag
Name: Reference: Status: Description:
-------------------------------------------------------------------------------------
adkim [ RFC-to-be ] current DKIM alignment mode
aspf [ RFC-to-be ] current SPF alignment mode
fo [ RFC-to-be ] current Failure reporting options
np [ RFC-to-be ] current Requested handling policy for non-existent subdomains
p [ RFC-to-be ] current Requested handling policy
pct [ RFC-to-be ] historic Sampling rate
psd [ RFC-to-be ] current Indicates whether policy record is published by a Public Suffix Domain
rf [ RFC-to-be ] historic Failure reporting format(s)
ri [ RFC-to-be ] historic Aggregate Reporting interval
rua [ RFC-to-be ] current Reporting URI(s) for aggregate data
ruf [ RFC-to-be ] current Reporting URI(s) for failure data
sp [ RFC-to-be ] current Requested handling policy for subdomains
t [ RFC-to-be ] current Test mode for the specified policy
v [ RFC-to-be ] current Specification version

The registration procedure for this registry remains Specification Required as defined by [RFC8126].

Sixth, the DMARC Report Format Registry on the Domain-based Message Authentication, Reporting, and Conformance (DMARC) Parameters registry group located at:

https://www.iana.org/assignments/dmarc-parameters/

is to be completely replaced by the following registration:

Format
Name: Reference: Status: Description:
---------------------------------------------------------------------------------
afrf [this document] current Authentication Failure Reporting Format (see [RFC6591])

The registration procedure for this registry remains Specification Required as defined by [RFC8126].

Seventh, in the Underscored and Globally Scoped DNS Node Names registry on the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

the existing registration for:

RR Type: TXT
_NODE NAME: _dmarc
Reference: [RFC7489]

will have its reference changed to [ RFC-to-be ].

We understand that these seven actions are the only ones required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-12-04):

From: The IESG
To: IETF-Announce
CC: dmarc-chairs@ietf.org, dmarc@ietf.org, draft-ietf-dmarc-dmarcbis@ietf.org, superuser@gmail.com, tjw.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Domain-based Message Authentication, Reporting, and Conformance (DMARC)) to Proposed Standard


The IESG has received a request from the Domain-based Message Authentication,
Reporting & Conformance WG (dmarc) to consider the following document: -
'Domain-based Message Authentication, Reporting, and Conformance
  (DMARC)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-12-04. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes the Domain-based Message Authentication,
  Reporting, and Conformance (DMARC) protocol.

  DMARC permits the owner of an email's Author Domain (#author-domain)
  to enable validation of the domain's use, to indicate the Domain
  Owner's (#domain-owner) or Public Suffix Operator's (#public-suffix-
  operator) message handling preference regarding failed validation,
  and to request reports about the use of the domain name.  Mail
  receiving organizations can use this information when evaluating
  handling choices for incoming mail.

  This document obsoletes RFCs 7489 and 9091.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-dmarcbis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-dmarc-failure-reporting: Domain-based Message Authentication, Reporting, and Conformance (DMARC) Failure Reporting (None - Internet Engineering Task Force (IETF) stream)
    rfc7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC) (Informational - Independent Submission stream)
    rfc7960: Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows (Informational - Internet Engineering Task Force (IETF) stream)

Shepherd Writeup draft-ietf-dmarc-dmarcbis


(1) The document is Standards Track, and this is the correct type.

(2)

Technical Summary:

This document describes the Domain-based Message Authentication,
Reporting, and Conformance (DMARC) protocol.

DMARC permits the owner of an email author's domain name to enable verification of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed verification, and to request reports about the use of the domain name.  Mail receiving organizations can use this information when evaluating handling choices for incoming mail.



Working Group Summary:

The consensus was extremely rough in places, and some places contentious.  The list of major and critical issues tracked is a very good place to start

https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues?q=is%3Aissue+is%3Aclosed+label%3Amajor%2Ccritical


The shepherd has attempted to summarize these issues, but felt the issues should be reviewed.  There are a few discussions worth deep dives.

The PSL/Tree Walk discussion
Using SPF as part of DMARC, despite the industry having issues with it.
p=reject

Document Quality:

There are a number of existing implementations of DMARC, and the industry is strongly behind DMARC. There are a number of reviewers
who have done deep reviews of this document, and the shepherd feels this

Personnel:

Document Shepherd is Tim Wicinski

Responsible AD is Murray Kucherawy



(3) The document underwent detailed review by the shepherd for content and editorial updates.  The AD has done a detailed review also, and should be taken into account

The shepherd does feel this document needs detailed directorate reviews, especially from the Security and DNS Directorates.


(4) This document has undergone a long and involved process and the review by the working group has reached rough consensus.

There are a LOT of changes from 7489 and the RFC diff is not something which is usable.  RFC 7489 also had content on the reporting functions which have been moved into a completely different document.

(5) area and directorate reviews will be carried out, and the shepherd has requested a DNS directorate review.

(6) The shepherd has no concerts with this document at this time.

(7) There are no IPR disclosures required

(8) There are no IPR disclosures filed.

(9) WG consensus is solid, despite the roughness.  It does represent the consensus of the majority of the working group. While there are a few individuals with issues, they do not appear to be on the same specific points.


(10) No appeals at this time.


(11) All nits have been addressed.

(12)

There is ABNF in this document and it has been checked several times, as the WG made changes from the ABNF in 7489.

The document shepherd did several ABNF tests to confirm the ABNF was logically and syntactically correct.

(13) All references have been identified as either normative or informative?


(14) All normative references are in a finished state.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.


  ** Downref: Normative reference to an Informational RFC: RFC 7489

  ** Downref: Normative reference to an Informational RFC: RFC 7960



(16) the document will obsolete RFCs 7489 and 9091 and they are listed in all the correct locations.


(17)

The IANA Considerations section has several updates to the original RFC, but these are all consistent with the current IANA considerations in the document.



(18) No new registries, just updates to existing ones.

(19) ABNF checks were done and confirmed on the updated ABNF

(20) No YANG

Shepherd Writeup draft-ietf-dmarc-dmarcbis


(1) The document is Standards Track, and this is the correct type.

(2)

Technical Summary:

This document describes the Domain-based Message Authentication,
Reporting, and Conformance (DMARC) protocol.

DMARC permits the owner of an email author's domain name to enable verification of the domain's use, to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed verification, and to request reports about the use of the domain name.  Mail receiving organizations can use this information when evaluating handling choices for incoming mail.



Working Group Summary:

The consensus was extremely rough in places, and some places contentious.  The list of major and critical issues tracked is a very good place to start

https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis/issues?q=is%3Aissue+is%3Aclosed+label%3Amajor%2Ccritical


The shepherd has attempted to summarize these issues, but felt the issues should be reviewed.  There are a few discussions worth deep dives.

The PSL/Tree Walk discussion
Using SPF as part of DMARC, despite the industry having issues with it.
p=reject

Document Quality:

There are a number of existing implementations of DMARC, and the industry is strongly behind DMARC. There are a number of reviewers
who have done deep reviews of this document, and the shepherd feels this

Personnel:

Document Shepherd is Tim Wicinski

Responsible AD is Murray Kucherawy



(3) The document underwent detailed review by the shepherd for content and editorial updates.  The AD has done a detailed review also, and should be taken into account

The shepherd does feel this document needs detailed directorate reviews, especially from the Security and DNS Directorates.


(4) This document has undergone a long and involved process and the review by the working group has reached rough consensus.

There are a LOT of changes from 7489 and the RFC diff is not something which is usable.  RFC 7489 also had content on the reporting functions which have been moved into a completely different document.

(5) area and directorate reviews will be carried out, and the shepherd has requested a DNS directorate review.

(6) The shepherd has no concerts with this document at this time.

(7) There are no IPR disclosures required

(8) There are no IPR disclosures filed.

(9) WG consensus is solid, despite the roughness.  It does represent the consensus of the majority of the working group. While there are a few individuals with issues, they do not appear to be on the same specific points.


(10) No appeals at this time.


(11) All nits have been addressed.

(12)

There is ABNF in this document and it has been checked several times, as the WG made changes from the ABNF in 7489.

The document shepherd did several ABNF tests to confirm the ABNF was logically and syntactically correct.

(13) All references have been identified as either normative or informative?


(14) All normative references are in a finished state.

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.


  ** Downref: Normative reference to an Informational RFC: RFC 7489

  ** Downref: Normative reference to an Informational RFC: RFC 7960



(16) the document will obsolete RFCs 7489 and 9091 and they are listed in all the correct locations.


(17)

The IANA Considerations section has several updates to the original RFC, but these are all consistent with the current IANA considerations in the document.



(18) No new registries, just updates to existing ones.

(19) ABNF checks were done and confirmed on the updated ABNF

(20) No YANG