Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows
draft-ietf-dmarc-interoperability-18

[Ballot comment]

- I think the abstract and intro are too coy in saying that
DMARC "can" introduce interop issues when we know that it
definitely does introduce such issues. Better to be up front
about that I think. The same issue arises elsewhere (e.g.  in
3.2.3.1) and I don't see any real benefit in almost pretending
that this isn't a real issue.

- I think the abstract and intro would be better if they
explicitly ack'd that DMARC affects mailing lists. So maybe
replacing the relevant sentence with something like:
"Collectively these email flows are referred to as indirect
email flows, and include mailing lists, such as those used to
discuss this document."

- 2.3: I'm surprised that we don't know the prevalence of simple
vs. relaxed support and use.

- 3.1.2: Saying that the MTA is the thing to "introduce" the
interop issue here seems a bit wrong - isn't the issue caused by
the existing MTA practice combined with the introduction of
DMARC?

[Ballot comment]
- Abstract: Please expand DMARC on first mention.

- 4.1.1.1, last bullet: "However, for known brands, all active domains are likely to be
      targeted equally by abusers."

I'm not sure quite what is meant by "known brands". Is this the same as well known email services?

6. Some of the mentioned mitigations involved relaxing alignment checks. Do those warrant a mention here?

-- last paragraph: " Section 4.1.3.3 warns that rewriting the RFC5322.From header field
  and changing the domain name should not be done with any domain."

I'm not sure I understand that sentence, especially around "not be done with any domain". Nor do I see which text in 4.1.3.3 specifically says that.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why is this the proper type of RFC?

This document discusses interoperability considerations for the DMARC protocol.
It does not specify any sort of  standard and while it does describe various
mitigation strategies for DMARC interoperability problems, it carefully
avoids labeling them as best practices.

    Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
    Please provide such a Document Announcement Write-Up. Recent examples can
    be found in the "Action" announcements for approved documents. The approval
    announcement contains the following sections:

Technical Summary:

  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.

Working Group Summary:

  This document was initially posted on January 29, 2015. The WGLC began
  September 30, 2015, with no substantive comments being made during the
  last call period.

Document Quality:

  This is an informational specification; it does not specify a standard
  or best practices.

Personnel:

  Ned Freed  is acting as the Document Shepherd. The
  responsible Area Director is Alexey Melnikov .

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.
   
The entire document was carefully reviewed. A number of issues were found,
most of which are editorial in nature. The resulting issues list was posted
to the WG list, leading to the -15 revision.

(4) Does the document Shepherd have any concerns about the depth or breadth of
    the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader
  perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
  internationalization?

No.

(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG
    should be aware of?
   
The usual concern with informational documents is particularly acute here:
The possibility that people will, because it's an RFC, treat it as a standard,
or worse, a list of best practices. It may be appropriate to insert
additional warnings about this given this document's description of various
techniques that are decidedly not best practices.

(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79 have
    already been filed.

  Franck Martin - fmartin@linkedin.com - confirmed
  Eliot Lear - lear@cisco.com - confirmed
  Tim Draegen - tim@dmarcian.com - confirmed
  Elizabeth Zwicky - zwicky@yahoo-inc.com - confirmed
  Kurt Andersen - kandersen@linkedin.com - confirmed

(8) Has an IPR disclosure been filed that references this document?

No.

(9) How solid is the WG consensus behind this document?

It's fairly solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this document.
    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
   
There's nit about one of the IP addresses possibly being in the wrong format;
These were fixed in -16.

(12) Describe how the document meets any required formal review criteria, such
    as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either
    normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state?
   
N/A.

(15) Are there downward normative references references (see RFC 3967)?

N/A.

(16) Will publication of this document change the status of any existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
   
This document has no IANA considerations and the section is marked to be
removed prior to publication.

(18) List any new IANA registries that require Expert Review for future
  allocations.
 
N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such
    as XML code, BNF rules, MIB definitions, etc.
   
There is no use of ABNF, MIBs, XML, or anything similar in this document.

The two sample mail messages in Appendix A were run through the message lint
utility. The results of that run were included in the document shepherd
review which led to revision -15.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dmarc-interoperability-15.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: draft-ietf-dmarc-interoperability@ietf.org, ned.freed@mrochek.com, dmarc@ietf.org, alexey.melnikov@isode.com, "Ned Freed" , dmarc-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Interoperability Issues Between DMARC and Indirect Email Flows) to Informational RFC


The IESG has received a request from the Domain-based Message
Authentication, Reporting & Conformance WG (dmarc) to consider the
following document:
- 'Interoperability Issues Between DMARC and Indirect Email Flows'
  as Informational RFC

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
ietf@ietf.org mailing lists by 2016-06-03. 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


  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/ballot/


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

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why is this the proper type of RFC?

This document discusses interoperability considerations for the DMARC protocol.
It does not specify any sort of  standard and while it does describe various
mitigation strategies for DMARC interoperability problems, it carefully
avoids labeling them as best practices.

    Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
    Please provide such a Document Announcement Write-Up. Recent examples can
    be found in the "Action" announcements for approved documents. The approval
    announcement contains the following sections:

Technical Summary:

  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.

Working Group Summary:

  This document was initially posted on January 29, 2015. The WGLC began
  September 30, 2015, with no substantive comments being made during the
  last call period.

Document Quality:

  This is an informational specification; it does not specify a standard
  or best practices.

Personnel:

  Ned Freed  is acting as the Document Shepherd. The
  responsible Area Director is Alexey Melnikov .

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.
   
The entire document was carefully reviewed. A number of issues were found,
most of which are editorial in nature. The resulting issues list was posted
to the WG list, leading to the -15 revision.

(4) Does the document Shepherd have any concerns about the depth or breadth of
    the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader
  perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
  internationalization?

No.

(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG
    should be aware of?
   
The usual concern with informational documents is particularly acute here:
The possibility that people will, because it's an RFC, treat it as a standard,
or worse, a list of best practices. It may be appropriate to insert
additional warnings about this given this document's description of various
techniques that are decidedly not best practices.

(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79 have
    already been filed.

  Franck Martin - fmartin@linkedin.com - confirmed
  Eliot Lear - lear@cisco.com - confirmed
  Tim Draegen - tim@dmarcian.com - confirmed
  Elizabeth Zwicky - zwicky@yahoo-inc.com - confirmed
  Kurt Andersen - kandersen@linkedin.com - confirmed

(8) Has an IPR disclosure been filed that references this document?

No.

(9) How solid is the WG consensus behind this document?

It's fairly solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this document.
    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
   
There's nit about one of the IP addresses possibly being in the wrong format;
I don't really understand the issue but I included a suggestion that
will hopefully fix it in the shephard review. However, this change was not
implement in the -15 revision; but it can wait for a subsequent revision.

Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such
    as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either
    normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state?
   
N/A.

(15) Are there downward normative references references (see RFC 3967)?

N/A.

(16) Will publication of this document change the status of any existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
   
This document has no IANA considerations and the section is marked to be
removed prior to publication.

(18) List any new IANA registries that require Expert Review for future
  allocations.
 
N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such
    as XML code, BNF rules, MIB definitions, etc.
   
There is no use of ABNF, MIBs, XML, or anything similar in this document.

The two sample mail messages in Appendix A were run through the message lint
utility. The results of that run were included in the document shepherd
review which led to revision -15.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why is this the proper type of RFC?

This document discusses interoperability considerations for the DMARC protocol.
It does not specify any sort of  standard and while it does describe various
mitigation strategies for DMARC interoperability problems, it carefully
avoids labeling them as best practices.

    Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
    Please provide such a Document Announcement Write-Up. Recent examples can
    be found in the "Action" announcements for approved documents. The approval
    announcement contains the following sections:

Technical Summary:

  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.

Working Group Summary:

  This document was initially posted on January 29, 2015. The WGLC began
  September 30, 2015, with no substantive comments being made during the
  last call period.

Document Quality:

  This is an informational specification; it does not specify a standard
  or best practices.

Personnel:

  Ned Freed  is acting as the Document Shepherd. The
  responsible Area Director is Alexey Melnikov .

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.
   
The entire document was carefully reviewed. A number of issues were found,
most of which are editorial in nature. The resulting issues list was posted
to the WG list, leading to the -15 revision.

(4) Does the document Shepherd have any concerns about the depth or breadth of
    the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader
  perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
  internationalization?

No.

(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG
    should be aware of?
   
The usual concern with informational documents is particularly acute here:
The possibility that people will, because it's an RFC, treat it as a standard,
or worse, a list of best practices. It may be appropriate to insert
additional warnings about this given this document's description of various
techniques that are decidedly not best practices.

(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79 have
    already been filed.

  Franck Martin - fmartin@linkedin.com - confirmed
  Eliot Lear - lear@cisco.com - confirmed
  Tim Draegen - tim@dmarcian.com -
  Elizabeth Zwicky - zwicky@yahoo-inc.com - confirmed
  Kurt Andersen - kandersen@linkedin.com - confirmed

(8) Has an IPR disclosure been filed that references this document?

No.

(9) How solid is the WG consensus behind this document?

It's fairly solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this document.
    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
   
There's nit about one of the IP addresses possibly being in the wrong format;
I don't really understand the issue but I included a suggestion that
will hopefully fix it in the shephard review. However, this change was not
implement in the -15 revision; but it can wait for a subsequent revision.

Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such
    as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either
    normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state?
   
N/A.

(15) Are there downward normative references references (see RFC 3967)?

N/A.

(16) Will publication of this document change the status of any existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
   
This document has no IANA considerations and the section is marked to be
removed prior to publication.

(18) List any new IANA registries that require Expert Review for future
  allocations.
 
N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such
    as XML code, BNF rules, MIB definitions, etc.
   
There is no use of ABNF, MIBs, XML, or anything similar in this document.

The two sample mail messages in Appendix A were run through the message lint
utility. The results of that run were included in the document shepherd
review which led to revision -15.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
    Standard, Informational, Experimental, or Historic)?
   
Informational.

    Why is this the proper type of RFC?

This document discusses interoperability considerations for the DMARC protocol.
It does not specify any sort of  standard and while it does describe various
mitigation strategies for DMARC interoperability problems, it carefully
avoids labeling them as best practices.

    Is this type of RFC indicated in the title page header?

Yes.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
    Please provide such a Document Announcement Write-Up. Recent examples can
    be found in the "Action" announcements for approved documents. The approval
    announcement contains the following sections:

Technical Summary:

  DMARC introduces a mechanism for expressing domain-level policies and
  preferences for email message validation, disposition, and reporting.
  The DMARC mechanism can encounter interoperability issues when
  messages do not flow directly from the author's administrative domain
  to the final recipients.  Collectively these email flows are referred
  to as indirect email flows.  This document describes interoperability
  issues between DMARC and indirect email flows.  Possible methods for
  addressing interoperability issues are presented.

Working Group Summary:

  This document was initially posted on January 29, 2015. The WGLC began
  September 30, 2015, with essentially no substantive comments being made. 

Document Quality:

  This is an informational specification; it does not specify a standard
  or best practices.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

(3) Briefly describe the review of this document that was performed by the
    Document Shepherd.
   
The entire document was carefully reviewed. A number of issues were found,
most of which are editorial in nature. The resulting issues list has been posted
to the WG mailing list so the document can be updated.

(4) Does the document Shepherd have any concerns about the depth or breadth of
    the reviews that have been performed?

No.

(5) Do portions of the document need review from a particular or from broader
  perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
  internationalization?

No.

(6) Describe any specific concerns or issues that the Document Shepherd has
    with this document that the Responsible Area Director and/or the IESG
    should be aware of?
   
The usual concern with informational documents is particularly acute here:
The possibility that people will, because it's an RFC, treat it as a standard,
or worse, a list of best practices. It may be appropriate to insert
additional warnings about this given this document's description of various
techniques that are decidedly not best practices.

(7) Has each author confirmed that any and all appropriate IPR disclosures
    required for full conformance with the provisions of BCP 78 and BCP 79 have
    already been filed. If not, explain why?

  Franck Martin - fmartin@linkedin.com - confirmed
  Eliot Lear - lear@cisco.com -
  Tim Draegen - tim@dmarcian.com -
  Elizabeth Zwicky - zwicky@yahoo-inc.com -
  Kurt Andersen - kandersen@linkedin.com - confirmed

(8) Has an IPR disclosure been filed that references this document?

No.

(9) How solid is the WG consensus behind this document?

It's fairly solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this document.
    (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
   
There's nit about one of the IP addresses possibly being in the wrong format;
I don't really understand the issue but I included a suggestion that
will hopefully fix it in the shephard review.

Boilerplate checks are not enough; this check needs to be thorough.

(12) Describe how the document meets any required formal review criteria, such
    as the MIB Doctor, media type, and URI type reviews.

N/A.

(13) Have all references within this document been identified as either
    normative or informative?

Yes.

(14) Are there normative references to documents that are not ready for
    advancement or are otherwise in an unclear state?
   
No.

(15) Are there downward normative references references (see RFC 3967)?

No.

(16) Will publication of this document change the status of any existing RFCs?

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
   
This document has no IANA considerations and the section is marked to be
removed prior to publication.

(18) List any new IANA registries that require Expert Review for future
  allocations.
 
N/A.

(19) Describe reviews and automated checks performed by the Document Shepherd
    to validate sections of the document written in a formal language, such
    as XML code, BNF rules, MIB definitions, etc.
   
There is no use of ABNF, MIBs, XML, or anything similar in this document.

The two sample mail messages in Appendix A were run through the message lint
utility. The results of that run were included in the document shepherd
review that has been posted to the WG list.