One document matched: draft-ietf-marf-spf-reporting-09.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" category="std"
docName="draft-ietf-marf-spf-reporting-09" updates="4408">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes" ?>
<front>
<title abbrev="SPF Auth Failure Reporting">
SPF Authentication Failure Reporting using the Abuse Report Format
</title>
<author initials="S." surname="Kitterman"
fullname="Scott Kitterman">
<organization>Agari</organization>
<address>
<postal>
<street>3611 Scheel Dr</street>
<city>Ellicott City</city>
<region>MD</region>
<code>21042</code>
<country>US</country>
</postal>
<phone>+1 301 325 5475</phone>
<email>skitterman@agari.com</email>
</address>
</author>
<date year="2012" />
<area>Applications</area>
<workgroup>MARF Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Standards Track</keyword>
<abstract>
<t> This memo presents extensions to the Abuse Reporting
Format (ARF), and Sender Policy Framework (SPF)
specifications to allow for detailed reporting of message
authentication failures in an on-demand fashion. </t>
<t> This memo updates RFC4408 by providing an IANA registry
for SPF modifiers.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> <xref target="ARF"/> defines a message format for sending
reports of abuse in the messaging infrastructure, with an
eye toward automating both the generating and consumption
of those reports. </t>
<t> <xref target="SPF"/> is one mechanism for message sender
authentication; it is "path-based" meaning it authenticates
the route that a message took from origin to destination.
The output is a verified domain name that can then be
subjected to some sort of evaluation process
(e.g., comparison to a known-good list, submission
to a reputation service, etc.). </t>
<t> This document extends <xref target="SPF"/> to add an
optional reporting address and other parameters.
Extension of <xref target="ARF"/> to add features required
for the reporting of these incidents is covered in <xref
target="I-D.IETF-MARF-AUTHFAILURE-REPORT"/> and <xref
target="I-D.IETF-MARF-AS"/>.</t>
<t> This document additionally creates a an IANA registry of
<xref target="SPF"/> record modifiers to avoid modifier
namespace collisions.</t>
</section>
<section anchor="definitions" title="Definitions">
<section anchor="keywords" title="Keywords">
<t> 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 <xref target="KEYWORDS"/>. </t>
</section>
<section anchor="imports" title="Imported Definitions">
<t> The ABNF token "qp-section" is defined in
<xref target="MIME"/>. </t>
<t> "local-part" is defined in <xref target="MAIL"/>. </t>
<t> "addr-spec" is defined in <xref target="MAIL"/>. </t>
</section>
</section>
<section anchor="spf-update"
title="Optional Reporting Address for SPF">
<t> There exist cases in which an ADministrative Management
Domain (ADMD) (see <xref target="EMAIL-ARCH"/>) employing
<xref target="SPF"/> for announcing sending practices may
want to know when messages are received via unauthorized
routing. Currently there is no such method defined in
conjunction with standardized approaches such as
<xref target="ARF"/>. Similar information can be gathered
using a specially crafted <xref target="SPF"/> record and
a special DNS server to track <xref target="SPF"/> record
lookups.</t>
<t> This document defines the following optional "modifier"
(as defined in Section 4.6.1 of <xref target="SPF"/>) to
SPF records, using the form defined in that specification:
<list style="hanging">
<t hangText="ra="> Reporting Address (plain-text;
OPTIONAL; no default). MUST be a local-part (see
Section 3.4.1 of <xref target="MAIL"/>) specifying an
e-mail address to which a report SHOULD be sent when
mail claiming to be from this domain (see Section 2.4
of <xref target="SPF"/> for a description of how domains
are identified for SPF checks) has failed the evaluation
algorithm described in <xref target="SPF"/>, in
particular because a message arrived via an unauthorized
route. To generate a complete address to which the
report is sent, the verifier simply appends to this
value an "@" followed by the SPF-compliant domain per
paragraph 4.1 of <xref target="SPF"/>. ra= modifiers
in a record that was reached by following an include:
mechanism MUST be ignored.</t>
<t> ABNF: </t>
<t> spf-report-tag = %x72.61 "=" qp-section </t>
<t hangText="rp="> Requested Report Percentage
(plain-text; OPTIONAL; default is "100"). The value is
an integer from 0 to 100 inclusive that indicates what
percentage of incidents of SPF failures, selected at
random, are to cause reports to be generated. The
report generator SHOULD NOT issue reports for more than
the requested percentage of incidents. An exception to
this might be some out-of-band arrangement between two
parties to override it with some mutually agreed value.
Report generators MAY make use of the "Incidents:"
field in [ARF] to indicate that there are more
reportable incidents than there are reports.</t>
<t> ABNF: </t>
<t> spf-rp-tag = %x72.69 *WSP "=" *WSP 1*12DIGIT "/" 1*12DIGIT </t>
<t hangText="rr="> Requested Reports
(plain-text; OPTIONAL; default is "all"). The value
MUST be a colon-separated list of tokens representing
those conditions under which a report is desired.
See <xref target="requests-spf"/> for a list of
valid tags. </t>
<t> ABNF: </t>
<t> spf-rr-type = ( "all" / "e" / "f" / "s" / "n" ) </t>
<t> spf-rr-tag = %x72.72 "=" spf-rr-type 0*
( ":" spf-rr-type ) </t>
</list> </t>
<t> In the absence of an "ra=" tag in the SPF record, the
"rp=" and "rr=" tags MUST be ignored, and the report
generator MUST NOT issue a report.</t>
</section>
<section anchor="requests" title="Requested Reports">
<t> This memo also includes, as the "rr" tokens defined
above, the means by which the sender can request
reports for specific circumstances of interest. Verifiers
MUST NOT generate reports for incidents that do not
match a requested report, and MUST ignore requests for
reports not included in this list. </t>
<section anchor="requests-spf"
title="Requested Reports for SPF Failures">
<t> The following report requests are defined
for SPF results:
<list style="hanging">
<t hangText="all"> All reports are
requested. </t>
<t hangText="e"> Reports are requested for
messages that produced an SPF
result of "TempError" or "PermError". </t>
<t hangText="f"> Reports are requested for
messages that produced an SPF
result of "Fail". </t>
<t hangText="s"> Reports are requested for
messages that produced an SPF
result of "SoftFail". </t>
<t hangText="n"> Reports are requested for
messages that produced an SPF
result of "Neutral" or "None". </t>
</list> </t>
</section>
</section>
<section anchor="iana" title="IANA Considerations">
<t> As required by <xref target="IANA-CONSIDERATIONS"/>,
this section contains registry information for the new
<xref target="SPF"/> modifiers. </t>
<section anchor="iana-spf-tags"
title="SPF Modifier Registration">
<t> IANA is requested to create the Sender Policy
Framework Modifier Registry, to include a list of
all registered SPF modifier names and their
defining documents. </t>
<t> New registrations or updates are to be published
in accordance with the "Specification Required"
guidelines as described in
<xref target="IANA-CONSIDERATIONS"/>. New
registrations and updates MUST contain the
following information:
<list style="numbers">
<t> Name of the modifier being registered or
updated </t>
<t> The document in which the specification
of the modifier is published </t>
<t> New or updated status, which MUST be one
of:
<list style="hanging">
<t hangText="current:"> The field
is in current use </t>
<t hangText="deprecated:"> The field
might be in current use but
its use is discouraged </t>
<t hangText="historic:"> The field
is no longer in current
use </t>
</list> </t>
</list> </t>
<t> An update may make a notation on an existing
registration indicating that a registered field
is historic or deprecated if appropriate. </t>
<figure><artwork>
+------------+-----------------+---------+
| MODIFIER | REFERENCE | STATUS |
+------------+-----------------+---------+
| exp | RFC4408 | current |
| redirect | RFC4408 | current |
| ra | (this document) | current |
| rp | (this document) | current |
| rr | (this document) | current |
+------------+-----------------+---------+
</artwork></figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t> Inherited considerations: implementors are advised to
consider the Security Considerations sections of
<xref target="SPF"/>, <xref target="ARF"/>,
<xref target="I-D.IETF-MARF-AS"/>, and
<xref target="I-D.IETF-MARF-AUTHFAILURE-REPORT"/>. </t>
<t> In addition to the advice in the Security Considerations
section of <xref target="I-D.IETF-MARF-AS"/>, these
additional considerations apply to generation of
<xref target="SPF"/> authentication failure reports:</t>
<section anchor="identity" title="Identity Selection">
<t> Preventing an <xref target="SPF"/> failure for SPF
SPF authentication failure reports is essential to
mitigate the risk of data loops.</t>
<t><list style="hanging">
<t> If the <xref target="SMTP"/> return address to be used
will not be the NULL return address, i.e.,
"MAIL FROM:<>", then the selected return address MUST
be selected such that it will pass
<xref target="SPF"/> MAIL FROM checks upon initial
receipt.</t>
<t> If the report is passed to the Mail Submission Agent
(MSA) (MSA is described in <xref target="EMAIL-ARCH"/>
using <xref target="SMTP"/>, the HELO/EHLO command
parameter SHOULD also be selected so that it will pass
<xref target="SPF"/> HELO checks.</t>
</list></t>
</section>
<section anchor="volume" title="Report Volume">
<t> It is impossible to predict the volume of reports
this facility will generate when enabled by a
report receiver. An implementer ought to
anticipate substantial volume, since the amount
of abuse occurring at receivers cannot be known
ahead of time, and may vary rapidly and
unpredictably. </t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="I-D.IETF-MARF-AUTHFAILURE-REPORT">
<front>
<title>
Authentication Failure Reporting using
the Abuse Report Format
</title>
<author initials="H." surname="Fontana"
fullname="H. Fontano">
<organization></organization>
</author>
<date month="January" year="2012" />
</front>
<seriesInfo
name="Internet-Draft"
value="draft-ietf-marf-authfailure-report"/>
</reference>
<reference anchor="I-D.IETF-MARF-AS">
<front>
<title>
Creation and Use of Email Feedback
Reports: An Applicability Statement
for the Abuse Reporting Format (ARF)
</title>
<author initials="J." surname="Falk"
fullname="J. Falk">
<organization>
Return Path
</organization>
</author>
<author initials="M." surname="Kucherawy, Ed."
fullname="M. Kucherawy, Ed.">
<organization>
Cloudmark
</organization>
</author>
<date month="February" year="2012" />
</front>
<seriesInfo
name="Internet-Draft"
value="draft-ietf-marf-as"/>
</reference>
<reference anchor="ARF">
<front>
<title>
An Extensible Format for Email
Feedback Reports
</title>
<author initials="Y." surname="Shafranovich"
fullname="Y. Shafranovich">
<organization>
SolidMatrix Technologies, Inc.
</organization>
</author>
<author initials="J." surname="Levine"
fullname="J. Levine">
<organization>
Domain Assurance Council
</organization>
</author>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy">
<organization>
Cloudmark, Inc.
</organization>
</author>
<date month="August" year="2010" />
</front>
<seriesInfo name="RFC" value="5965"/>
</reference>
<reference anchor="IANA-CONSIDERATIONS">
<front>
<title> Guidelines for Writing an IANA
Considerations Section in RFCs </title>
<author initials="H." surname="Alvestrand"
fullname="H. Alvestrand">
<organization>
Google
</organization>
</author>
<author initials="T." surname="Narten"
fullname="T. Narten">
<organization>
IBM
</organization>
</author>
<date month="May" year="2008" />
</front>
<seriesInfo name="RFC" value="5226" />
</reference>
<reference anchor="KEYWORDS">
<front>
<title> Key words for use in RFCs to Indicate
Requirement Levels </title>
<author initials="S." surname="Bradner"
fullname="S. Bradner">
<organization>
Harvard University
</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="MAIL">
<front>
<title> Internet Message Format </title>
<author initials="P." surname="Resnick"
fullname="P. Resnick (editor)">
<organization>
Qualcomm, Inc.
</organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="RFC" value="5322" />
</reference>
<reference anchor="MIME">
<front>
<title> Multipurpose Internet Mail
Extensions (MIME) Part One: Format of
Internet Message Bodies </title>
<author initials="N." surname="Freed"
fullname="N. Freed">
<organization/>
</author>
<author initials="N." surname="Borenstein"
fullname="N. Borenstein">
<organization/>
</author>
<date month="November" year="1996" />
</front>
<seriesInfo name="RFC" value="2045" />
</reference>
<reference anchor="SPF">
<front>
<title>
Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail,
Version 1
</title>
<author initials="M." surname="Wong"
fullname="M. Wong">
<organization/>
</author>
<author initials="W." surname="Schlitt"
fullname="W. Schlitt">
<organization/>
</author>
<date year="2006" month="April"/>
<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 Sender
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. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="4408"/>
<format type="TXT" octets="105009"
target="ftp://ftp.isi.edu/in-notes/rfc4408.txt"/>
</reference>
<reference anchor="SMTP">
<front>
<title>Simple Mail Transfer Protocol</title>
<author
fullname="J. Klensin"
initials="J."
surname="Klensin">
<organization></organization>
</author>
<date month="October" year="2008" />
</front>
<seriesInfo name="RFC" value="5321" />
</reference>
</references>
<references title="Informative References">
<reference anchor="EMAIL-ARCH">
<front>
<title>Internet Mail Architecture</title>
<author
fullname="Dave Crocker"
initials="D"
surname="Crocker">
<organization></organization>
</author>
<date
day="31"
month="October"
year="2008"></date>
</front>
<seriesInfo name="RFC" value="5598"/>
<format
octets="342738"
target="ftp://ftp.isi.edu/in-notes/rfc5598.txt"
type="TXT"></format>
</reference>
</references>
<section anchor="thanks" title="Acknowledgements">
<t> The author wishes to acknowledge the following for their
review and constructive criticism of this proposal:
Murray Kucherawy, Tim Draegen, Julian Mehnle, and John
Levine. </t>
</section>
<section anchor="examples" title="Examples">
<section anchor="spf-nomail"
title="SPF DNS record for domain that sends no mail, but
requests reports">
<figure>
<artwork>
v=spf1 ra=postmaster -all
</artwork>
</figure>
</section>
<section anchor="spf-basic"
title="Minimal SPF DNS record change to add a reporting
address">
<figure>
<artwork>
v=spf1 mx:example.org ra=postmaster -all
</artwork>
</figure>
</section>
<section anchor="spf-full"
title="SPF DNS record with reporting address, report
percentage, and requested report type">
<figure>
<artwork>
v=spf1 mx:example.org -all ra=postmaster rp=10 rr=e
</artwork>
</figure>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 05:40:10 |