One document matched: draft-ietf-marf-authfailure-report-10.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<!-- $Id: draft-fontana-marf-authfailure-report,v 06 2011/12/04 12:45:51 hlf Exp hlf $ -->
<rfc ipr="trust200902" category="std"
docName="draft-ietf-marf-authfailure-report-10">
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes" ?>
<front>
<title abbrev="Auth Failure Reporting">
Authentication Failure Reporting using the Abuse Report Format
</title>
<author initials="H.F." surname="Fontana"
fullname="Hilda L. Fontana">
<organization></organization>
<address>
<postal>
<street>3579 E. Foothill Blvd., suite 282</street>
<city>Pasadena</city>
<region>CA</region>
<code>91107</code>
<country>US</country>
</postal>
<phone>+1 626 676 8852</phone>
<email>hilda@hfontana.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 registers an extension report type to the
Abuse Reporting Format (ARF), affecting multiple registries,
for use in generating receipt-time reports about messages
that fail one or more email message authentication checks.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t> The Abuse Reporting Format (<xref target="ARF"/>) defines
a message format for sending reports of abuse in the
messaging infrastructure, with an eye towards automating
both the generation and consumption of those reports.
There is now also a desire to extend the ARF format to
include reporting of messages that fail to authenticate
using known message authentication methods, such as
DomainKeys Identified Mail (<xref target="DKIM"/>) and
Sender Policy Framework (<xref target="SPF"/>), as these
are sometimes evidence of abuse that can be detected and
reported through automated means. The same mechanism can
be used to convey forensic information about the specific
reason the authentication method failed. Thus, this memo
presents such extensions to ARF that allow for detailed
reporting of message authentication method failures. </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="arch" title="Email Architecture">
<t> This memo uses some terms whose definitions and
descriptions can be found in
<xref target="EMAIL-ARCH"/>. </t>
</section>
<section anchor="imports" title="Base 64">
<t> base64 is defined in Section 4 of
<xref target="BASE64"/>. </t>
<t> The values that are base64 encodings MAY contain
FWS for formatting purposes as per the usual
header field wrapping defined in
<xref target="MAIL"/>. During decoding,
any characters not in the base64 alphabet are
ignored so that such line wrapping does not harm
the value. The ABNF token "FWS" is defined
in <xref target="DKIM"/>. No other extensions
to the valid base64 character set are
permitted. </t>
</section>
<section anchor="technologies" title="Technologies">
<t>There are technologies in email security that
provide authentication services and some that do
authorization. These are often conflated. A
discussion of this that is useful for establishing
context can be found in Section
1.5.2 in <xref target="AUTH-RESULTS"/>.</t>
</section>
</section>
<section anchor="arf-extend"
title="ARF Extension for Authentication Failure Reporting">
<t> The current report format defined in <xref target="ARF"/>
lacks some specific features required to do effective
email authentication failure reporting. This section
defines extensions to ARF to accommodate this requirement.
</t>
<t> A single report describes a single email authentication
failure. Multiple reports MAY be used to report multiple
failures for a single message. </t>
<section anchor="arf-fields" title="New ARF Feedback Type">
<t> A new feedback type of "auth-failure" is defined as
an extension per Section 7.3 of
<xref target="ARF"/>. </t>
<t> A message that uses this feedback type has the
following modified header field requirements for
the second (machine-parseable)
<xref target="MIME"/> part of the report:
<list style="hanging">
<t hangText="Authentication-Results:">
Syntax as specified in <xref target="AUTH-RESULTS"/>.
Furthermore, <xref target="ARF"/> specifies this field
is OPTIONAL and appears at most once; for this extension,
this field MUST be present, but MUST reflect only a
single authentication method's result. </t>
<t hangText="Original-Envelope-Id:">
Syntax as specified in <xref target="ARF"/>.
Furthermore, <xref target="ARF"/> specifies this field
is OPTIONAL and appears at most once; for this extension,
this field's inclusion is RECOMMENDED, where that value
is available, to aid in diagnosing of the authentication
failure. </t>
<t hangText="Original-Mail-From:">
Syntax as specified in <xref target="ARF"/>.
Furthermore, <xref target="ARF"/> specifies this field
is OPTIONAL and appears at most once; for this extension,
this field's inclusion is RECOMMENDED, where that value
is available, to aid in diagnosing of the authentication
failure. </t>
<t hangText="Source-IP:">
Syntax as specified in <xref target="ARF"/>.
Furthermore, <xref target="ARF"/> specifies this field
is OPTIONAL and appears at most once; for this extension,
this field's inclusion is RECOMMENDED, where that value
is available, to aid in diagnosing of the authentication
failure. </t>
<t hangText="Reported-Domain:">
Syntax as specified in <xref target="ARF"/>.
Furthermore, <xref target="ARF"/> specifies this field
is OPTIONAL and appears at most once; for this extension,
this field MUST be present if such a value is available.
</t>
<t hangText="Delivery-Result:">
As specified in
<xref target="arf-headers-2"/>. This field
is OPTIONAL, but MUST NOT appear more than
once. If present, it SHOULD indicate the
outcome of the message in some meaningful
way, but MAY be set to "other" for
local policy reasons.
</t>
</list> </t>
<t>
The third MIME part of the message is either of
type "message/rfc822" (as defined in
<xref target="MIME-TYPES"/>) or
"text/rfc822-headers" (as defined in
<xref target="REPORT"/>) and contains a copy of
the entire header block from the original message.
This part MUST be included (contrary to
<xref target="REPORT"/>, which makes it
optional). </t>
<t> For privacy reasons, report generators might
need to redact portions of a reported message
such as an identifier or address associated with
the end user whose complaint action
resulted in the report. A discussion of relevant
issues and a suggested method for doing so can
be found in
<xref target="I-D.IETF-MARF-REDACTION"/>. </t>
</section>
<section anchor="arf-headers"
title="New ARF Header Field Names">
<t> The following new ARF field names are defined
as extensions to Section 3.1 of
<xref target="ARF"/>. </t>
<section anchor="arf-headers-1"
title="Required For All Reports">
<t> <list style="hanging">
<t hangText="Auth-Failure:"> Indicates the failure from
an email authentication method that
is being reported. The list of valid
values is enumerated in <xref target="auth-failures"/>. </t>
</list></t>
</section>
<section anchor="arf-headers-2"
title="Optional For All Reports">
<t><list style="hanging">
<t hangText="Delivery-Result:"> The final
message disposition that was enacted
by the Administrative Management
Domain (ADMD) generating the report and
MUST NOT appear more than once.
Possible values are:
<list style="hanging">
<t hangText="delivered:">
The message was delivered
(not specific as to where). </t>
<t hangText="spam:">
The message was delivered
to the recipient's spam
folder (or equivalent). </t>
<t hangText="policy:">
The message was not
delivered to the intended
inbox due to a failure from
an email authentication method.
The specific action taken is not
specified. </t>
<t hangText="reject:">
The message was
rejected. </t>
<t hangText="other:">
The message had a final
disposition not covered
by one of the above
values. </t>
</list></t></list></t>
</section>
<section anchor="arf-headers-3"
title="Required For DKIM Reports">
<t>
<list style="hanging">
<t hangText="DKIM-Domain:"> The domain that
signed the message, taken from the
"d=" tag of the signature. </t>
<t hangText="DKIM-Identity:"> The identity of
the signature that failed
verification, taken from the "i=" tag
of the signature. </t>
<t hangText="DKIM-Selector:"> The selector of
the signature that failed
verification, taken from the "s=" tag
of the signature. </t>
</list>
</t>
</section>
<section anchor="arf-headers-4"
title="Optional For DKIM Reports">
<t>
<list style="hanging">
<t hangText="DKIM-Canonicalized-Header:">
A base64 encoding of the canonicalized
header of the message as generated
by the verifier. </t>
<t hangText="DKIM-Canonicalized-Body:">
A base64 encoding of the canonicalized body of the
message as generated by the verifier. The encoded
content MUST be limited to those octets that
contribute to the DKIM body hash (i.e., the value
of the "l=" tag; see Section 3.7 of <xref target="DKIM"/>).
</t>
</list>
</t>
<t>
If DKIM-Canonicalized-Header and DKIM-Canonicalized-Body
encode redacted data, they MUST NOT be included. Otherwise,
they SHOULD be included. The data presented there have to
be exactly the canonicalized header and body as defined by
<xref target="DKIM"/> and computed at the verifier. This
is because these fields are intended to aid in identifying
message alterations that invalidate DKIM signatures in transit.
Including redacted data in them renders the data unusable.
(See also <xref target="arf-fields"/> and <xref target="redaction_dkim_reports"/> for further discussion.)
</t>
</section>
<section anchor="arf-headers-5"
title="Required For ADSP Reports">
<t>
<list style="hanging">
<t hangText="DKIM-ADSP-DNS:"> Includes the
Author Domain Signing Practices (ADSP)
policy used to obtain the
verifier's ADSP result. This
MUST be formatted per Section 4.2.1
of <xref target="ADSP"/>. </t>
</list> </t>
</section>
<section anchor="arf-headers-6"
title="Required For SPF Reports">
<t>
<list style="hanging">
<t hangText="SPF-DNS:"> This field MUST appear
once for every Sender Policy Framework
(<xref target="SPF"/>) SPF record used
to obtain the SPF result. It MUST
include the DNS RRTYPE used,
the DNS domain from which the record
was retrieved, and the content of
that record. The syntax is defined
in <xref target="abnf_fields"/>. </t>
</list> </t>
</section>
</section>
<section anchor="auth-failures"
title="Authentication Failure Types">
<t> The list of defined email authentication failure types
used in the "Auth-Failure:" header field (defined above),
is as follows:
<list style="hanging">
<t hangText="adsp:"> The message did not
conform to the author domain's published
<xref target="ADSP"/> signing practises.
The DKIM-ADSP-DNS field MUST be included
in the report. </t>
<t hangText="bodyhash:"> The body hash in
the signature and the body hash computed
by the verifier did not match. The
DKIM-Canonicalized-Body field SHOULD be
included in the report (see <xref target="arf-headers-4"/>). </t>
<t hangText="revoked:"> The DKIM key referenced
by the signature on the message has been
revoked. The DKIM-Domain and DKIM-Selector
fields MUST be included in the report. </t>
<t hangText="signature:"> The DKIM signature on
the message did not successfully verify against
the header hash and public key. The DKIM-Domain
and DKIM-Selector fields MUST be included in the
report, and the DKIM-Canonicalized-Header field
SHOULD be included in the report (see <xref target="arf-headers-4"/>).
</t>
<t hangText="spf:"> The evaluation of the
author domain's SPF record produced a
"none", "fail", "softfail", "temperror" or
"permerror" result. ("none" is not strictly
a failure per <xref target="SPF"/>, but a
service that demands successful SPF
evaluations of clients could treat it like a
failure.) </t>
</list> </t>
<t> Supplementary data MAY be included in the form of
<xref target="MAIL"/>-compliant comments. For
example, "Auth-Failure: adsp" could be augmented
by a comment to indicate that the failed message
was rejected because it was not signed when it
should have been. See <xref target="example"/>
for an example. </t>
</section>
</section>
<section anchor="abnf_fields"
title="Syntax For Added ARF Header Fields">
<t> The <xref target="ABNF"/> definitions for the new fields are as
follows: </t>
<figure><artwork>
auth-failure = "Auth-Failure:" [CFWS]
( "adsp" / "bodyhash" / "revoked" /
"signature" / "spf" ) [CFWS] CRLF
; "CFWS" is defined in [MAIL]
delivery-result = "Delivery-Result:" [CFWS]
( "delivered" / "spam" /"policy" /
"reject" / "other" ) [CFWS] CRLF
dkim-header = "DKIM-Canonicalized-Header:" [CFWS]
base64string CRLF
; "base64string" is defined in [DKIM]
dkim-sig-domain = "DKIM-Domain:" [CFWS] dkim-domain [CFWS]
CRLF
; "dkim-domain" is defined in [DKIM]
dkim-identity = "DKIM-Identity:" [CFWS] [ local-part ] "@"
domain-name [CFWS] CRLF
; "local-part" is defined in [MAIL]
dkim-selector = "DKIM-Selector:" [CFWS] selector [CFWS] CRLF
; "selector" is defined in [DKIM]
dkim-adsp-dns = "DKIM-ADSP-DNS:" [CFWS]
quoted-string [CFWS] CRLF
; "quoted-string" is defined in [MAIL]
dkim-body = "DKIM-Canonicalized-Body:" [CFWS]
base64string CRLF
dkim-selector-dns = "DKIM-Selector-DNS:" [CFWS]
quoted-string [CFWS] CRLF
spf-dns = "SPF-DNS:" [CFWS] ( "txt" / "spf" ) [CFWS] ":" [CFWS]
domain [CFWS] ":" [CFWS] quoted-string [CFWS] CRLF
</artwork></figure>
</section>
<section anchor="iana" title="IANA Considerations">
<t> As required by <xref target="IANA"/>,
this section contains registry information for the
extension to <xref target="ARF"/>. </t>
<section anchor="iana-dkim-arf-types"
title="Updates to ARF Feedback Types">
<t> The following feedback type is added to the
Feedback Report Type Values registry: </t>
<figure><artwork>
Feedback Type: auth-failure
Description: email authentication failure report
Published in: [this memo]
Status: current
</artwork></figure>
</section>
<section anchor="iana-dkim-arf-headers"
title="Updates to ARF Header Field Names">
<t> The following headers are added to the Feedback
Report Header Fields registry: </t>
<figure><artwork>
Field Name: Auth-Failure
Description: Type of email authentication method failure
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
<figure><artwork>
Field Name: Delivery-Result
Description: Final disposition of the subject message
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
<figure><artwork>
Field Name: DKIM-ADSP-DNS
Description: Retrieved DKIM ADSP record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Canonicalized-Body
Description: Canonicalized body, per DKIM
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Canonicalized-Header
Description: Canonicalized header, per DKIM
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Domain
Description: DKIM signing domain from "d=" tag
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Identity
Description: Identity from DKIM signature
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Selector
Description: Selector from DKIM signature
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
<figure><artwork>
Field Name: DKIM-Selector-DNS
Description: Retrieved DKIM key record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
<figure><artwork>
Field Name: SPF-DNS
Description: Retrieved SPF record
Multiple Appearances: No
Related "Feedback-Type": auth-failure
Published in: [this memo]
Status: current
</artwork></figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t> Security issues with respect to these reports
are similar to those found in <xref target="DSN"/>. </t>
<section anchor="inherited" title="Inherited Considerations">
<t> Implementers are advised to consider the
Security Considerations sections of
<xref target="DKIM"/>, <xref target="ADSP"/>
<xref target="SPF"/> and <xref target="ARF"/>. </t>
</section>
<section anchor="forgeries" title="Forgeries">
<t> These reports can be forged as easily as ordinary
Internet electronic mail. User agents and
automatic mail handling facilities (such as mail
distribution list exploders) that wish to make
automatic use of DSNs of any kind should take
appropriate precautions to minimize the potential
damage from denial-of-service attacks. </t>
<t> Security threats related to forged DSNs include the
sending of:
<list style="letters">
<t> A falsified email authentication method
failure notification when the message was
in fact delivered to the indicated
recipient; </t>
<t> Falsified signature information,
such as selector, domain, etc. </t>
</list> </t>
<t> Perhaps the simplest means of mitigating this
threat is to assert that these reports should
themselves be signed with something like DKIM.
On the other hand, if there's a problem with the
DKIM infrastructure at the verifier, signing DKIM
failure reports might produce reports that aren't
trusted or even accepted by their intended
recipients. </t>
</section>
<section anchor="autogen" title="Automatic Generation">
<t> Automatic generation of these reports by verifying
agents can cause a denial-of-service attack when
a large volume of e-mail is sent that causes
email authentication failures for whatever
reason. </t>
<t> Limiting the rate of generation of these
messages might be appropriate but threatens to
inhibit the distribution of important and possibly
time-sensitive information. </t>
<t> In general ARF feedback loop terms, it is
suggested that report generators only create
these (or any) ARF reports after an out-of-band
arrangement has been made between two parties.
This mechanism then becomes a way to adjust
parameters of an authorized abuse report feedback
loop that is configured and activated by private
agreement rather than starting to send them
automatically based solely on discovered data in
the DNS. </t>
</section>
<section anchor="empty-sender"
title="Envelope Sender Selection">
<t> In the case of transmitted reports in the form of
a new message, it is necessary to consider the
construction and transmission of the message so as
to avoid amplification attacks, deliberate or
otherwise. See Section 5 of <xref target="ARF"/>
for further information.
</t>
</section>
<section anchor="multiple-incidents"
title="Reporting Multiple Incidents">
<t> If it is known that a particular host generates
abuse reports upon certain incidents, an attacker
could forge a high volume of messages that will
trigger such a report. The recipient of the
report could then be innundated with reports.
This could easily be extended to a distributed
denial-of-service attack by finding a number of
report-generating servers. </t>
<t> The incident count referenced in
<xref target="ARF"/> provides
a limited form of mitigation. The host
generating reports may elect to send reports only
periodically, with each report representing a
number of identical or near-identical incidents.
One might even do something inverse-exponentially,
sending reports for each of the first ten
incidents, then every tenth incident up to 100,
then every 100th incident up to 1000, etc.
until some period of relative quiet after which
the limitation resets. </t>
<t> The use of this for "near-identical" incidents
in particular causes a degradation in reporting
quality, however. If for example a large number
of pieces of spam arrive from one attacker,
a reporting agent might decide only to send a
report about a fraction of those messages.
While this averts a flood of reports to a
system administrator, the precise details of
each incident are similarly not sent. </t>
</section>
<section anchor="redaction_dkim_reports"
title="Redaction of Data in DKIM Reports">
<t>This memo requires that the canonicalized header
and body be returned without being subject to redaction
when a DKIM failure is being reported. This is
necessary to ensure that the returned canonicalized
forms are useful for debugging as they must be compared
to the equivalent form at the signer. If a message is
altered in transit, and the returned data are also
redacted, the redacted portion and the altered portion
may overlap, rendering the comparison results
meaningless. However, unredacted data can leak
information the reporting entity considers to be
private. It is for this reason the return of the
canonicalized forms is not required.
</t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="ABNF">
<front>
<title> Augmented BNF for Syntax Specifications: ABNF </title>
<author initials="D." surname="Crocker"
fullname="D. Crocker">
<organization>
Brandenburg InternetWorking
</organization>
</author>
<author initials="P." surname="Overell"
fullname="P. Overell">
<organization>
THUS plc.
</organization>
</author>
<date month="January" year="2008" />
</front>
<seriesInfo name="RFC" value="5234"/>
</reference>
<reference anchor="ADSP">
<front>
<title> DKIM Sender Signing Practises </title>
<author initials="E." surname="Allman"
fullname="E. Allman">
<organization>
Sendmail, Inc.
</organization>
</author>
<author initials="M." surname="Delany"
fullname="M. Delany">
<organization>
Yahoo! Inc.
</organization>
</author>
<author initials="J." surname="Fenton"
fullname="J. Fenton">
<organization>
Cisco Systems, Inc.
</organization>
</author>
<author initials="J." surname="Levine"
fullname="J. Levine">
<organization>
Taughannock Networks
</organization>
</author>
<date month="August" year="2009" />
</front>
<seriesInfo name="RFC" value="5617"/>
</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="AUTH-RESULTS">
<front>
<title> Message Header Field for Indicating
Message Authentication Status </title>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy">
<organization>
Sendmail, Inc.
</organization>
</author>
<date month="April" year="2009" />
</front>
<seriesInfo name="RFC" value="5451"/>
</reference>
<reference anchor="BASE64">
<front>
<title> The Base16, Base32, and Base64 Data
Encodings </title>
<author initials="S." surname="Josefsson"
fullname="S. Josefsson">
<organization>
SJD
</organization>
</author>
<date month="October" year="2006" />
</front>
<seriesInfo name="RFC" value="4648"/>
</reference>
<reference anchor="DKIM">
<front>
<title> DomainKeys Identified Mail (DKIM)
Signatures </title>
<author initials="D." surname="Crocker"
fullname="Dave Crocker">
</author>
<author initials="T." surname="Hansen"
fullname="T. Hansen">
</author>
<author initials="M." surname="Kucherawy"
fullname="M. Kucherawy">
</author>
<date month="September" year="2011" />
</front>
<seriesInfo name="RFC" value="6376" />
</reference>
<reference anchor="IANA">
<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="MIME-TYPES">
<front>
<title> Multipurpose Internet Mail
Extensions (MIME) Part Two:
Media Types </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="2046" />
</reference>
<reference anchor="I-D.IETF-MARF-REDACTION">
<front>
<title>Redaction of Potentially Sensitive Data from Mail Abuse Reports</title>
<author initials="JD" surname="Falk"
fullname="JD Falk">
<organization>
Return Path
</organization>
</author>
<date month="March" year="2011"/>
</front>
<seriesInfo name="I-D"
value="draft-ietf-marf-redaction" />
</reference>
<reference anchor="REPORT">
<front>
<title> The Multipart/Report Content Type for
the Reporting of Mail System
Administrative Messages </title>
<author initials="G." surname="Vaudreuil"
fullname="G. Vaudreuil">
<organization>
Lucent Technologies
</organization>
</author>
<date month="January" year="2003" />
</front>
<seriesInfo name="RFC" value="3462" />
</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>
</references>
<references title="Informative References">
<reference anchor="DSN">
<front>
<title> An Extensible Message Format for
Delivery Status Notifications </title>
<author initials="K." surname="Moore"
fullname="K. Moore">
<organization>
University of Tennessee
</organization>
</author>
<author initials="G." surname="Vaudreuil"
fullname="G. Vaudreuil">
<organization>
Lucent Technologies
</organization>
</author>
<date month="January" year="2003" />
</front>
<seriesInfo name="RFC" value="3464" />
</reference>
<reference anchor="EMAIL-ARCH">
<front>
<title>Internet Mail Architecture</title>
<author initials="D" surname="Crocker"
fullname="Dave Crocker">
<organization/>
</author>
<date month="October" day="31" year="2008"/>
<abstract>
<t> Over its thirty-five year history,
Internet Mail has changed
significantly in scale and
complexity, as it has become a
global infrastructure service.
These changes have been
evolutionary, rather than
revolutionary, reflecting a strong
desire to preserve both its
installed base and its usefulness.
To collaborate productively on
this large and complex system,
all participants must work from a
common view of it and use a common
language to describe its
components and the interactions
among them. But the many
differences in perspective
currently make it difficult to
know exactly what another
participant means. To serve as
the necessary common frame of
reference, this document describes
the enhanced Internet Mail
architecture, reflecting the
current service. </t>
</abstract>
</front>
<seriesInfo name="RFC" value="5598"/>
<format type="TXT" octets="342738"
target="ftp://ftp.isi.edu/in-notes/rfc5598.txt"/>
</reference>
</references>
<section anchor="thanks" title="Acknowledgements">
<t> The authors wish to acknowledge the following for their
review and constructive criticism of this proposal:
Frank Ellerman, J.D. Falk, Scott Kitterman, John Levine,
Mike Markley, Kelly Wanser, Murray Kucherawy and Alessandro Vesely.
</t>
</section>
<section anchor="example" title="Example">
<t> This section contains an example of the use of the
extension defined by this memo. </t>
<section anchor="example-report"
title="Example Use of ARF Extension Headers">
<figure>
<preamble> An ARF-formatted report
using the proposed
ARF extension fields: </preamble>
<artwork>
Message-ID: <433689.81121.example@mta.mail.receiver.example>
From: "SomeISP Antispam Feedback" <feedback@mail.receiver.example>
To: arf-failure@sender.example
Subject: FW: You have a new bill from your bank
Date: Sat, 8 Oct 2011 15:15:59 -0500 (CDT)
MIME-Version: 1.0
Content-Type: multipart/report;
boundary="------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg";
report-type=feedback-report
Content-Transfer-Encoding: 7bit
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
This is an authentication failure report for an email message
received from a.sender.example on 8 Oct 2011 20:15:58 +0000 (GMT).
For more information about this format please see [this memo].
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: message/feedback-report
Content-Transfer-Encoding: 7bit
Feedback-Type: auth-failure
User-Agent: Someisp!Mail-Feedback/1.0
Version: 1
Original-Mail-From: anexample.reply@a.sender.example
Original-Envelope-Id: o3F52gxO029144
Authentication-Results: mta1011.mail.tp2.receiver.example;
dkim=fail (bodyhash) header.d=sender.example
Auth-Failure: bodyhash
DKIM-Canonicalized-Body: VGhpcyBpcyBhIG1lc3NhZ2UgYm9keSB0
aGF0IGdvdCBtb2RpZmllZCBpbiB0cmFuc2l0LgoKQXQgdGhlIHNhbWU
gdGltZSB0aGF0IHRoZSBib2R5aGFzaCBmYWlscyB0byB2ZXJpZnksIH
RoZQptZXNzYWdlIGNvbnRlbnQgaXMgY2xlYXJseSBhYnVzaXZlIG9yI
HBoaXNoeSwgYXMgdGhlClN1YmplY3QgYWxyZWFkeSBoaW50cy4gIElu
ZGVlZCwgdGhpcyBib2R5IGFsc28gY29udGFpbnMKdGhlIGZvbGxvd2l
uZyB0ZXh0OgoKICAgUGxlYXNlIGVudGVyIHlvdXIgZnVsbCBiYW5rIG
NyZWRlbnRpYWxzIGF0CiAgIGh0dHA6Ly93d3cuc2VuZGVyLmV4YW1wb
GUvCgpXZSBhcmUgaW1wbHlpbmcgdGhhdCwgYWx0aG91Z2ggbXVsdGlw
bGUgZmFpbHVyZXMKcmVxdWlyZSBtdWx0aXBsZSByZXBvcnRzLCBhIHN
pbmdsZSBmYWlsdXJlIGNhbiBiZQpyZXBvcnRlZCBhbG9uZyB3aXRoIH
BoaXNoaW5nIGluIGEgc2luZ2xlIHJlcG9ydC4K
DKIM-Domain: sender.example
DKIM-Identity: @sender.example
DKIM-Selector: testkey
Arrival-Date: 8 Oct 2011 20:15:58 +0000 (GMT)
Source-IP: 192.0.2.1
Reported-Domain: a.sender.example
Reported-URI: http://www.sender.example/
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg
Content-Type: text/rfc822-headers
Content-Transfer-Encoding: 7bit
Authentication-Results: mta1011.mail.tp2.receiver.example;
dkim=fail (bodyhash) header.d=sender.example;
spf=pass smtp.mailfrom=anexample.reply@a.sender.example
Received: from smtp-out.sender.example
by mta1011.mail.tp2.receiver.example
with SMTP id oB85W8xV000169;
Sat, 08 Oct 2011 13:15:58 -0700 (PDT)
DKIM-Signature: v=1; c=relaxed/simple; a=rsa-sha256;
s=testkey; d=sender.example; h=From:To:Subject:Date;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
4bmp/YzhwvcubU4=
Received: from mail.sender.example
by smtp-out.sender.example
with SMTP id o3F52gxO029144;
Sat, 08 Oct 2011 13:15:31 -0700 (PDT)
Received: from internal-client-001.sender.example
by mail.sender.example
with SMTP id o3F3BwdY028431;
Sat, 08 Oct 2011 13:15:24 -0700 (PDT)
Date: Sat, 8 Oct 2011 16:15:24 -0400 (EDT)
Reply-To: anexample.reply@a.sender.example
From: anexample@a.sender.example
To: someuser@receiver.example
Subject: You have a new bill from your bank
Message-ID: <87913910.1318094604546@out.sender.example>
--------------Boundary-00=_3BCR4Y7kX93yP9uUPRhg--
</artwork>
<postamble> Example 1: Example ARF report
using these extensions </postamble>
</figure>
<t> This example ARF message is making the following
assertion:
<list style="symbols">
<t> DKIM verification of the signature
added within "example.com" failed
</t>
<t> The cause for the verification failure
was a mismatch between the body contents
observed at the verifier and the body
hash contained in the signature. </t>
</list> </t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:35:55 |