Network Working Group D. Crocker, Ed.
Internet-Draft Brandenburg InternetWorking
Intended status: Best Current Practice February 17, 2013
Expires: August 21, 2013
Using DMARC
draft-crocker-dmarc-bcp-00
Abstract
Email abuse often relies on unauthorized use of a domain name, such
as one belonging to a well-known company (brand). SPF and DKIM
provide basic domain name authentication methods for email. A recent
industry effort built an additional authentication-based layer,
called Domain-based Message Authentication, Reporting & Conformance
(DMARC). It allows a sender to indicate that their emails are
protected by SPF and/or DKIM, and tells a receiver what to do if
neither of those authentication methods passes; it also provides a
reporting mechanism, from receivers back to domain owners. Such
capabilities over the public Internet are unusual and their use is
not yet well-understood. This document formulates a set of best
practices for the use of DMARC.
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 August 21, 2013.
Copyright Notice
Copyright (c) 2013 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
Crocker Expires August 21, 2013 [Page 1]
Internet-Draft dmarcops February 2013
(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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Development . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DNS Configuration . . . . . . . . . . . . . . . . . . . . . . 3
4. Receiver Processing . . . . . . . . . . . . . . . . . . . . . 3
5. Report Generation . . . . . . . . . . . . . . . . . . . . . . 4
6. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
8.1. References - Normative . . . . . . . . . . . . . . . . . 5
8.2. References - Informative . . . . . . . . . . . . . . . . 5
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Email abuse often relies on unauthorized use of a domain name, such
as one belonging to a well-known company (brand). SPF [RFC4408] and
DKIM [RFC6376] provide basic domain name authentication methods for
email. A recent industry effort [DMARC.ORG] built an additional
authentication-based layer, called Domain-based Message
Authentication, Reporting & Conformance. [DMARC] allows a sender to
indicate that their emails are protected by SPF and/or DKIM, and
tells a receiver what to do if neither of those authentication
methods passes; it also provides a reporting mechanism, from
receivers back to domain owners. Such capabilities over the public
Internet are unusual and their use is not yet well-understood. This
document formulates a set of best practices for the use of DMARC.
Discussion is divided along basic lines of activity:
o Development
o DNS Configuration
o Receiver Processing
o Report Generation
Crocker Expires August 21, 2013 [Page 2]
Internet-Draft dmarcops February 2013
This initial version of the document is primarily meant to seed
discussion, rather than offer complete consideration of the topic...
Besides obviously soliciting more content and discussion, a review of
the document's organization is strongly requested.
An IETF mailing list for discussing DMARC issues has been requested:
dmarc@ietf.org.
2. Development
{This section is meant for any software development practices,
relevant to the use of DMARC. -ed}
3. DNS Configuration
o Malformed DMARC policy TXT records in DNS.
Can these be used for anything?
Should a policy that does not conform to the spec be ignored?
Is there any benefit in attempting to infer meaning (monitor =
none, non = ??, rejec = ??)
How lenient can one safely be as regards spacing, quotes,
separators and slashes?
Is there anyway I can report the malformation to the domain
owner?
4. Receiver Processing
o Rapid adoption of DMARC by apparent spammers
Thousands upon thousands of DMARC records published by abusive
domains -- probably wildcarding, but it works out the same
Using data that is several weeks old, we have a handful of
domains that are accepting aggregate reports for over 20
thousand subdomains each
Are the reports (either aggregate or forensic) providing the
spammers insight that they did not already have?
***POTENTIALLY PROBLEMATIC QUESTION TO FOLLOW*** Should I only
send reports to domains that I trust?
Crocker Expires August 21, 2013 [Page 3]
Internet-Draft dmarcops February 2013
5. Report Generation
o Minimum requirements for aggregate report XML documents
What is the bare minimum (in terms of data gleaned from a given
email) I need to produce a valid report?
What sections of the XML need to be repeated when there is a
new aggregation point (email from a different IP, for example)
Essentially this could be considered "XML for people who
thought they could figure out how to read an XSD but reality
crashed that party."
o Minimum requirements for forensic reports (soft-fail reports)
What is the bare minimum required to produce a forensic report.
6. Miscellaneous
This section is meant as a catch-all, for items that haven't yet been
assigned to their appropriate section.
o Performing remote destination checking
What happens if I don't?
o Identifier alignment
{This has been cited, but not yet explained, as a potential BCP
issue. -ed}
o Owner vs. Operator
{It is possible that there are distinctive practices for domain
name owners, versus agents that operate DNS or email services
on behalf of the name owner. -ed}
7. Security Considerations
o DNS Abuse
Most probably don't see this, but adding potentially multiple
new DNS lookups per email multiplies rapidly
DNS Cache can only help for so long
Agg reports are (probably) created from some other host
Crocker Expires August 21, 2013 [Page 4]
Internet-Draft dmarcops February 2013
If Org Domain policy lookups are required, you may get two
lookups every time there is a single lookup
8. References
8.1. References - Normative
[DMARC] Kucherawy, M., Ed., "Domain-based Message Authentication,
Reporting and Conformance (DMARC)", URL
http://http://www.dmarc.org/draft-dmarc-base-00-02.txt,
March 2013.
8.2. References - Informative
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1", RFC
4408, April 2006.
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys
Identified Mail (DKIM) Signatures", RFC 6376, September
2011.
Appendix A. Acknowledgements
DMARC and this draft are the result of lengthy efforts by an informal
industry consortium: dmarc.org.
Author's Address
Dave Crocker (editor)
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086
USA
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
Crocker Expires August 21, 2013 [Page 5]