DMARC Working Group T. Draegen, Ed. Internet-Draft June 17, 2017 Intended status: Best Current Practice Expires: December 19, 2017 DMARC Interoperability Usage Guide draft-tdraegen-dmarc-usage-guide-00 Abstract Domain-based Message Authentication, Reporting, and Conformance (DMARC) allows for the expression of domain-level policies and preferences for message validation, disposition, and reporting between mail-originating and mail-receiving organizations. This usage guide presents strategies for successful interoperation of historically disparate mail systems in the presence of domain-level policies. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 19, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Draegen Expires December 19, 2017 [Page 1] Internet-Draft DMARC Interoperability Usage Guide June 2017 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Domain Owners . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Mail-Originating Organizations . . . . . . . . . . . . . . . 3 4. Mail-Receiving Organizations . . . . . . . . . . . . . . . . 4 5. Internet Mail Architecture, DMARC, and Domain-level Policies 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Appendix A. Additional Usage Notes . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction DMARC [RFC7489] allows for the expression of domain-level policies and preferences for message validation, disposition, and reporting between mail-originating and mail-receiving organizations. Aside from documented interoperability issues between DMARC and indirect email flows [RFC7960], mail-originating and mail-receiving organizations can benefit from operational experience collected during the initial years of Internet-wide DMARC deployment. Within mail-originating organizations, domain-level policies can introduce challenges between domain operators and historically disparate mail systems. Domain-level policies require a degree of coordination and management across mail systems involved in sending email on behalf of domains. Mail-receiving organizations can face challenges when handling mail flows that fall under the auspices of domain-level DMARC policies. Indirect mail flows [RFC7960], legitimate but unauthorized sources of mail, and overly broad authorization by domain owners all present unique mail handling challenges that result in trade offs between implementing a requested domain-level policy and possible disruption of the delivery of desired mail. Variance in processing of mail and the significance of stable domain- level identifiers raises further issues between organizations. This usage guide presents strategies for successful mail handling operation in the presence of domain-level policies. Draegen Expires December 19, 2017 [Page 2] Internet-Draft DMARC Interoperability Usage Guide June 2017 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terms "Organizational Domain", "Authenticated Identifiers", and "Domain Owner" are specified in Section 3 of DMARC [RFC7489]. 2. Domain Owners o How does new scope of domain-level policies influence organization? o DMARC Report Processing and Analysis o DMARC Policy * Implementation of compliance to allow for policy * Steady state operations * Monitoring for ongoing compliance * Remediation of discovered issues * Doing all the work but not moving to p=reject; decision point o DNS Management to achieve Identifier Alignment o SPF Considerations o DKIM Considerations 3. Mail-Originating Organizations o Default authentication ala how MS and Google do 'customer-domain- com.microogle-service.com' o Sending on Behalf of Others * When "Other" is within same company * XXX Where does ADMD come from? * DNS Management Draegen Expires December 19, 2017 [Page 3] Internet-Draft DMARC Interoperability Usage Guide June 2017 * Does new scope of domain-level policies create new requirements? * Identifier Alignment o SPF Considerations * See M3AAWG documents? o DKIM Considerations * See M3AAWG documents? o Policy implications * Monitoring of potential policy * Operational reporting for ongoing compliance 4. Mail-Receiving Organizations o Processing inputs to DMARC check: * Dealing with malformed email * Processing SPF + MFROM vs HELO checks + Reporting implications * Processing DKIM + Multiple signatures + Reporting implications + Insufficient key lengths - Communication of weak key back to DO? * Passing inputs between gateways within same organization + Intra ADMD + Inter ADMD + Extra ADMD Draegen Expires December 19, 2017 [Page 4] Internet-Draft DMARC Interoperability Usage Guide June 2017 o Mailbox Hosting * Issues delivering into mbox hosting environment? + Is anything enforcing policy at MDA level? * Issues accepting email from mbox hosting env? + Should MSA be performing DMARC compliance checks to prevent injection of doomed email? - EG, cable company's MSA accepting email to deliver using customers @aol.com address - Would it make sense to enumerate and standardize error codes? o Presentation of DMARC disposition to MUAs * Big gulf between operators doing things and MUAs talking to clients * Are you only an operator or an operator + MUA? * MUA portion seems huge o Reintroducing mail to Message Handling Systems * Mediators (see RFC7960 3.2.) * Mailbox forwarding * SMTP relay/security services * Mailing Lists * XXX Need easy way to test if message will remain DMARC compliant? o Generating DMARC feedback * Aggregate + Add additional notes/issues back to domain owner? Needed? - Embed X-ARF style notification? Draegen Expires December 19, 2017 [Page 5] Internet-Draft DMARC Interoperability Usage Guide June 2017 - Embed reporting address for Domain Owner into DMARC record? o Just use existing notification? postmaster@? (postmaster might != DO) * Forensic + Different levels of redaction today + Purpose to inform accurate deployment vs supply threat intelligence? Does posture make a difference? + Considerations around implementation of various options (eg "fo=") * DMARC records with no reporting address. What to do with them? o Overriding requested DMARC policy o Handling inquiries to DMARC contact address (as found in DMARC XML) 5. Internet Mail Architecture, DMARC, and Domain-level Policies o MUA: check if user is authorized to send using domain. Create UX to inform user that unauthorized domain usage will likely not work. Likely involves communication with aMSA to determine authorization. o Message Handling System * MSA: before accepting submission, aMSA can determine if hMSA will be able to successfully meet DMARC compliance. Other 1/2 of MUA. * MSA: check to see if submitter is authorized to send on behalf of domain. Disallow unauthorized usage of domains especially if infrastructure uses shared-IPs (prevent neighbor-IP attacks). o MTA: detect if transfered email falls under a DMARC policy. If so, preserve. o MDA: policy enforcement at MDA discouraged. Potential for MDA to act as Mediator.ReSender with all associated considerations. Draegen Expires December 19, 2017 [Page 6] Internet-Draft DMARC Interoperability Usage Guide June 2017 o MS: Reintroduction of mail from MS should be considered against any published domain policies o Mediators: all mediator share common consideration wrt domain- level policies. Handing off email that falls under a DMARC policy to an MTA should be carefully considered 6. Acknowledgements This document was developed initially through encouragement on the DMARC Working Group email list, then through the willingness of DMARC implementors to share and refine their operational experience. 7. IANA Considerations This memo includes no request to IANA. All drafts are required to have an IANA considerations section (see Guidelines for Writing an IANA Considerations Section in RFCs [RFC5226] for a guide). If the draft does not require IANA to do anything, the section contains an explicit statement that this is the case (as above). If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor. 8. Security Considerations All drafts are required to have a security considerations section. See RFC 3552 [RFC3552] for a guide. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . Draegen Expires December 19, 2017 [Page 7] Internet-Draft DMARC Interoperability Usage Guide June 2017 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, . [RFC7960] Martin, F., Ed., Lear, E., Ed., Draegen. Ed., T., Zwicky, E., Ed., and K. Andersen, Ed., "Interoperability Issues between Domain-based Message Authentication, Reporting, and Conformance (DMARC) and Indirect Email Flows", RFC 7960, DOI 10.17487/RFC7960, September 2016, . Appendix A. Additional Usage Notes This is an Appendix. Author's Address Tim Draegen (editor) PO Box 1007 Brevard, NC 28712 USA Phone: +1 831 227 8002 Email: tim@eudaemon.net Draegen Expires December 19, 2017 [Page 8]