One document matched: draft-crocker-dmarc-bcp-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no"?>
<?rfc toc="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc inline="yes"?>
<?rfc topblock="yes" ?>
<?rfc autobreaks="yes" ?>
<rfc
category="bcp"
docName="draft-crocker-dmarc-bcp-00"
ipr="trust200902">
<front>
<title
abbrev="dmarcops">Using DMARC</title>
<author
fullname="Dave Crocker"
initials="D."
role="editor"
surname="Crocker">
<organization>Brandenburg InternetWorking</organization>
<address>
<postal>
<street>675 Spruce Drive</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94086</code>
<country>USA</country>
</postal>
<phone>+1.408.246.8253</phone>
<email>dcrocker@bbiw.net</email>
</address>
</author>
<date
day=""
month=""
year="2013"></date>
<area></area>
<workgroup></workgroup>
<keyword></keyword>
<abstract>
<t>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. </t>
</abstract>
</front>
<middle>
<section
title="Introduction">
<t>Email abuse often relies on unauthorized use of a domain name, such
as one belonging to a well-known company (brand). <xref
target="RFC4408">SPF</xref> and <xref
target="RFC6376">DKIM</xref> 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. <xref
target="DMARC"></xref> 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. </t>
<t>Discussion is divided along basic lines of activity: <list
style="symbols">
<t>Development</t>
<t>DNS Configuration</t>
<t>Receiver Processing</t>
<t>Report Generation</t>
</list> 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.</t>
<t>An IETF mailing list for discussing DMARC issues has been requested:
dmarc@ietf.org.</t>
</section>
<section
title="Development">
<t>{This section is meant for any software development practices,
relevant to the use of DMARC. -ed}</t>
</section>
<section
title="DNS Configuration">
<t>
<list
style="symbols">
<t>Malformed DMARC policy TXT records in DNS. <list>
<t>Can these be used for anything?</t>
<t>Should a policy that does not conform to the spec be
ignored?</t>
<t>Is there any benefit in attempting to infer meaning
(monitor = none, non = ??, rejec = ??)</t>
<t>How lenient can one safely be as regards spacing,
quotes, separators and slashes?</t>
<t>Is there anyway I can report the malformation to the
domain owner?</t>
</list></t>
</list>
</t>
</section>
<section
title="Receiver Processing">
<t>
<list
style="symbols">
<t>Rapid adoption of DMARC by apparent spammers <list>
<t>Thousands upon thousands of DMARC records published by
abusive domains -- probably wildcarding, but it works
out the same</t>
<t>Using data that is several weeks old, we have a handful
of domains that are accepting aggregate reports for over
20 thousand subdomains each</t>
<t>Are the reports (either aggregate or forensic) providing
the spammers insight that they did not already have?</t>
<t>***POTENTIALLY PROBLEMATIC QUESTION TO FOLLOW*** Should
I only send reports to domains that I trust?</t>
</list></t>
</list>
</t>
</section>
<section
title="Report Generation">
<t><list
style="symbols">
<t>Minimum requirements for aggregate report XML documents <list>
<t>What is the bare minimum (in terms of data gleaned from
a given email) I need to produce a valid report?</t>
<t> What sections of the XML need to be repeated when there
is a new aggregation point (email from a different IP,
for example)</t>
<t>Essentially this could be considered "XML for people who
thought they could figure out how to read an XSD but
reality crashed that party."</t>
</list></t>
<t>Minimum requirements for forensic reports (soft-fail reports) <list>
<t>What is the bare minimum required to produce a forensic
report.</t>
</list>
</t>
</list></t>
</section>
<section
title="Miscellaneous">
<t>This section is meant as a catch-all, for items that haven't yet
been assigned to their appropriate section. <list
style="symbols">
<t>Performing remote destination checking <list>
<t>What happens if I don't?</t>
</list>
</t>
<t>Identifier alignment<list>
<t>{This has been cited, but not yet explained, as a
potential BCP issue. -ed}</t>
</list></t>
<t>Owner vs. Operator<list>
<t>{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}</t>
</list></t>
</list></t>
</section>
<section
title="Security Considerations">
<t><list
style="symbols">
<t>DNS Abuse <list>
<t>Most probably don't see this, but adding potentially
multiple new DNS lookups per email multiplies
rapidly</t>
<t>DNS Cache can only help for so long</t>
<t>Agg reports are (probably) created from some other
host</t>
<t>If Org Domain policy lookups are required, you may get
two lookups every time there is a single lookup </t>
</list></t>
</list></t>
</section>
</middle>
<back>
<references
title="References - Normative">
<reference
anchor="DMARC">
<front>
<title
abbrev="DMARC">Domain-based Message Authentication, Reporting
and Conformance (DMARC)</title>
<author
fullname="M. Kucherawy"
initials="M."
role="editor"
surname="Kucherawy">
<organization>Cloudmark</organization>
</author>
<date
day="30"
month="March"
year="2013"></date>
</front>
<seriesInfo
name="URL"
value="http://http://www.dmarc.org/draft-dmarc-base-00-02.txt"></seriesInfo>
</reference>
</references>
<references
title="References - Informative">
<reference
anchor="RFC4408">
<front>
<title>Sender Policy Framework (SPF) for Authorizing Use of
Domains in E-Mail, Version 1</title>
<author
fullname="M. Wong"
initials="M."
surname="Wong">
<organization></organization>
</author>
<author
fullname="W. Schlitt"
initials="W."
surname="Schlitt">
<organization></organization>
</author>
<date
month="April"
year="2006"></date>
<abstract>
<t>E-mail on the Internet can be forged in a number of ways.
In particular, existing protocols place no restriction on
what a sending host can use as the reverse-path of a
message or the domain given on the SMTP HELO/EHLO commands.
This document describes version 1 of the ender Policy
Framework (SPF) protocol, whereby a domain may explicitly
authorize the hosts that are allowed to use its domain
name, and a receiving host may check such authorization.
This memo defines an Experimental Protocol for the Internet
community.</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="4408"></seriesInfo>
<format
octets="105009"
target="http://www.rfc-editor.org/rfc/rfc4408.txt"
type="TXT"></format>
</reference>
<reference
anchor="RFC6376">
<front>
<title>DomainKeys Identified Mail (DKIM) Signatures</title>
<author
fullname="D. Crocker"
initials="D."
surname="Crocker">
<organization></organization>
</author>
<author
fullname="T. Hansen"
initials="T."
surname="Hansen">
<organization></organization>
</author>
<author
fullname="M. Kucherawy"
initials="M."
surname="Kucherawy">
<organization></organization>
</author>
<date
month="September"
year="2011"></date>
<abstract>
<t>DomainKeys Identified Mail (DKIM) permits a person, role,
or organization that owns the signing domain to claim some
responsibility for a message by associating the domain with
the message. This can be an author's organization, an
operational relay, or one of their agents. DKIM separates
the question of the identity of the Signer of the message
from the purported author of the message. Assertion of
responsibility is validated through a cryptographic
signature and by querying the Signer's domain directly to
retrieve the appropriate public key. Message transit from
author to recipient is through relays that typically make
no substantive change to the message content and thus
preserve the DKIM signature.</t><t> This memo
obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo
name="RFC"
value="6376"></seriesInfo>
<format
octets="176999"
target="http://www.rfc-editor.org/rfc/rfc6376.txt"
type="TXT"></format>
</reference>
</references>
<section
title="Acknowledgements">
<t>DMARC and this draft are the result of lengthy efforts by an
informal industry consortium: dmarc.org.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:38:37 |