Internet DRAFT - draft-tdraegen-dmarc-usage-guide
draft-tdraegen-dmarc-usage-guide
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,
<http://www.rfc-editor.org/info/rfc2119>.
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,
<http://www.rfc-editor.org/info/rfc3552>.
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,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<http://www.rfc-editor.org/info/rfc7489>.
[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,
<http://www.rfc-editor.org/info/rfc7960>.
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]
