Skip to main content

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

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: draft-ietf-dmarc-interoperability@ietf.org, ned.freed@mrochek.com, rfc-editor@rfc-editor.org, dmarc@ietf.org, "The IESG" <iesg@ietf.org>, alexey.melnikov@isode.com, "Ned Freed" <ned.freed@mrochek.com>, dmarc-chairs@ietf.org
Subject: Document Action: 'Interoperability Issues Between DMARC and Indirect Email Flows' to Informational RFC (draft-ietf-dmarc-interoperability-18.txt)

The IESG has approved the following document:
- 'Interoperability Issues Between DMARC and Indirect Email Flows'
  (draft-ietf-dmarc-interoperability-18.txt) as Informational RFC

This document is the product of the Domain-based Message Authentication,
Reporting & Conformance Working Group.

The IESG contact persons are Alexey Melnikov, Ben Campbell and Alissa
Cooper.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/


Ballot Text

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 <ned.freed@mrochek.com> is acting as the Document Shepherd. The
   responsible Area Director is Alexey Melnikov <aamelnikov@fastmail.fm>.

RFC Editor Note