Charles Lindsey wrote:
But surely, as others have pointed out, if you (as a mere user) have
chosen to subscribe to the services offered by MTA-X, then presumably you
know what they do, and also presumably you trust them.
I think the feedback I'm getting suggests that we shouldn't force MUAs
to make such presumptions. There should be some capacity for them to
discover the reliability of their upstream MTAs, i.e. whether or not
they provide the protections this specification recommends.
Without an ESMTP extension of some kind, or an equivalent query
mechanism, that would be tough to accomplish.
b) digital signing of the Authentication-Results: header, e.g. with DKIM
If your MUA is capable of verifying such a signature by MTA-X, then it is
presumably equally capable of verifying the original DKIM signature which
the Authenticated header is attesting to.
True, but if this draft were to say MTAs adding an
Authentication-Results: header should also DKIM-sign the message
including that header, then we're only establishing a minimal burden,
namely that MUAs have to learn DKIM. They wouldn't also have to learn a
dozen other mechanisms; the border MTA is the one that has to know how
to evaluate everything we have or might invent, while the MUA only has
to know DKIM for the internal validation.
The spec doesn't actually mandate either of these. It sounds like the
IESG would likely want one or the other.
I would say the IESG are over-reacting a bit.
Actually, the best suggestion I have seen is that POP3/IMAP servers should
see to the matter. I realise that might not be easy for POP3, but IMAP is
already so bloated with extensions that another one would hardly be
noticed :-( .
I've attached a separate draft that makes use of the experimental IMAP
annotations proposal to support this whole concept via IMAP rather than
via a header. I haven't posted the draft yet because I was waiting for
review from a couple of people, but it seems a good time to open it up
to wider scrutiny now. The barrier-to-entry is a little higher than
this draft (especially since there are already several implementations).
The drawback to the IMAP method is that it excludes things like procmail
or other shell-based filters from making use of the results of
authentication attempts by border MTAs. There's still a substantial
install base that uses v7 mailboxes.
A coworker also suggested the following: If you trust that your MTAs from
the border inbound are compliant, then you can pretty much guarantee that
Authentication-Results: will appear immediately above (or perhaps
immediately below) a matching Received: header, and thus you could decide
to trust only those which (a) have such an adjacency, and (b) are from a
host you trust.
And yes, I like that, though it is perhaps less likely to be implemented
by MUAs. Presumably the hope is that future MTA will, when they spot a
believable Authenticated header, display a Large Green Tick beside the
message, so that the naive user will be suitably reassured
Perhaps then I should include this in the list of possible solutions
under Security Considerations.
I have a number of diffs stemming from this discussion and other minor
editorial work. I'll post something later today for consensus review.
Individual submission M. Kucherawy
Internet-Draft Sendmail, Inc.
Intended status: Standards Track September 29, 2008
Expires: April 2, 2009
IMAP Annotation for Indicating Message Authentication Status
draft-kucherawy-sender-auth-imap-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
This document may not be modified, and derivative works of it may not
be created.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 2, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Kucherawy Expires April 2, 2009 [Page 1]
Internet-Draft Authentication-Results IMAP Annotation September 2008
Abstract
This memo defines an application of the IMAP (Internet Message Access
Protocol) Annotations facility whereby a server can store and
retrieve meta-data about a message relating to message authentication
tests performed on the message and the corresponding results.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. SMTP Server or MDA Implementation . . . . . . . . . . . . . . 6
3. IMAP Server Implementation . . . . . . . . . . . . . . . . . . 7
4. IMAP Client Implementation . . . . . . . . . . . . . . . . . . 8
5. IMAP Annotation Format . . . . . . . . . . . . . . . . . . . . 9
5.1. Formal Definition . . . . . . . . . . . . . . . . . . . . 9
5.2. Authentication Identifier Fields . . . . . . . . . . . . . 11
5.3. Result Values . . . . . . . . . . . . . . . . . . . . . . 11
5.3.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 11
5.3.2. DKIM ADSP Results . . . . . . . . . . . . . . . . . . 12
5.3.3. SPF and Sender-ID Results . . . . . . . . . . . . . . 13
5.3.4. iprev Results . . . . . . . . . . . . . . . . . . . . 14
5.3.5. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 15
5.3.6. Extension Result Codes . . . . . . . . . . . . . . . . 15
5.4. Authentication Methods . . . . . . . . . . . . . . . . . . 16
5.4.1. Definition Of Initial Methods . . . . . . . . . . . . 16
5.4.2. Extension Methods . . . . . . . . . . . . . . . . . . 16
6. The 'iprev' Authentication Method . . . . . . . . . . . . . . 18
7. Conformance and Usage Requirements . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8.1. Annotation Registration . . . . . . . . . . . . . . . . . 20
8.2. Email Authentication Method Name Registry . . . . . . . . 20
8.3. Email Authentication Result Name Registry . . . . . . . . 21
9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9.1. Misleading Results . . . . . . . . . . . . . . . . . . . . 25
9.2. Attacks Against Authentication Methods . . . . . . . . . . 25
9.3. Intentionally Malformed Data . . . . . . . . . . . . . . . 25
9.4. Compromised Internal Hosts . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References . . . . . . . . . . . . . . . . . . . 26
10.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 28
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 29
Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 32
Kucherawy Expires April 2, 2009 [Page 2]
Internet-Draft Authentication-Results IMAP Annotation September 2008
1. Introduction
Electronic mail, though ubiquitous and highly useful, is also prone
to increasing abuse by parties that choose to exploit its lenient
design for nefarious purposes such as "spam" and "phishing." Abuse
of this leniency has become so widespread as to become an economic
problem. Several nascent methods of mitigating this problem such as
[SPF] and [DKIM] appear to make strides in this direction but are
themselves not sufficient. In many cases the results of attempts to
authenticate messages must be relayed to the user for final
disposition.
This memo defines a new annotation for [IMAP] using the IANA
Considerations found in [ANNOTATE] which is used to store and relay
message authentication results from upstream (e.g. "border") mail
servers to internal mail servers which ultimately do message
delivery. This information can then be used by delivery agents or
even the users themselves when determining whether or not the content
of such messages is trustworthy.
The message header defined in
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] serves a similar purpose and
is simple to implement but has some moderate security implications,
so a more secure channel is required. In particular, the header
block of a message is generally unauthenticated and is also typically
relayed intact, meaning it is an obvious vector for data forgery.
Thus, trusting part of a message header to be secure is a difficult
problem. This method and that of
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-ESMTP] establishes a much better
trust boundary and removes that obvious attack vector.
[UPDATE PRIOR TO FINAL VERSION] At the time of publication of this
draft, [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF] are the
published e-mail authentication methods in common use. As various
methods emerge, it is necessary to prepare for their appearance and
encourage convergence in the area of interfacing these filters to
electroic mail servers.
1.1. Purpose
The IMAP annotation defined in this memo is expected to serve several
purposes:
1. Convey to MUAs from filters and Mail Transfer Agents (MTAs) the
results of various message authentication checks being applied;
2. Provide a common location for the presentation of this data;
Kucherawy Expires April 2, 2009 [Page 3]
Internet-Draft Authentication-Results IMAP Annotation September 2008
3. Create an extensible framework for specifying results from new
authentication methods as such emerge;
4. Convey the results of message authentication tests to later
filtering agents within the same "trust domain", as such agents
might apply more or less stringent checks based on message
authentication results;
5. Do all of this in a way not prone to forgery or
misinterpretation.
1.2. Definitions
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 RFC2119.
An "MTA" is a Mail Transfer Agent, or any agent which uses [SMTP] or
its extensions to format and transport a message.
An "MDA" is a Mail Delivery Agent (also sometimes referred to as
"LDA" or Local Delivery Agent), or any agent which has access to
receive a message from an MTA and write it into the receiving user's
"inbox".
An "MUA" is a Mail User Agent, or any software which retrieves and
displays messages on behalf of a user.
A "border MTA" is an MTA which acts as a gateway between the general
Internet and the users within an organizational boundary.
A "delivery MTA" (or Mail Delivery Agent or MDA) is an MTA which
actually enacts delivery of a message to a user's inbox or other
final delivery.
An "intermediate MTA" is an MTA which handles messages after a border
MTAs and before a delivery MTA.
Kucherawy Expires April 2, 2009 [Page 4]
Internet-Draft Authentication-Results IMAP Annotation September 2008
+-----+ +-----+ +------------+
| MUA |-->| MSA |-->| Border MTA |
+-----+ +-----+ +------------+
|
|
V
+----------+
| Internet |
+----------+
|
|
V
+-----+ +-----+ +------------------+ +------------+
| MUA |<==| MDA |<==| Intermediate MTA |<--| Border MTA |
+-----+ +-----+ +------------------+ +------------+
Generally it is assumed that the work of applying message
authentication schemes takes place at a border MTA or a delivery MTA.
This specification is written with that assumption in mind. However,
there are some sites at which the entire mail infrastructure consists
of a single host. In such cases, such terms as "border MTA" and
"delivery MTA" may well apply to the same machine or even the very
same agent. It is also possible that message authentication could
take place on an intermediate MTA. Although this document doesn't
specifically include such cases, they are not meant to be excluded
from this specification.
See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail
system architecture.
In the figure shown above, the double-lines indicate the portions of
the transport of a message where this protocol would be applied.
Note also that the Local Mail Transfer Protocol [LMTP] could benefit
from a similar extension.
Kucherawy Expires April 2, 2009 [Page 5]
Internet-Draft Authentication-Results IMAP Annotation September 2008
2. SMTP Server or MDA Implementation
Within the message flow depicted in Section 1.2, message
authentication methods can be applied in a variety of places, most
commonly the Border MTA, an Intermediate MTA, or the MDA.
Where the MDA does the message authentication, its results can be
attached, using the annotation defined defined by this memo, to the
message for later retrieval by an [IMAP] client. Where the message
authentication takes place at one of the earlier MTAs, some method of
carrying those results along each hop until mailbox injection at the
MDA must be applied. One such proposal can be found in
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-ESMTP] and another in
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER], but no specific method is
required by this memo.
If [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] is used, the header field
MAY be deleted on delivery as the data relayed there will be reported
via the annotation defined by this memo.
An MDA MAY choose to file messages other than in a recipient's
message inbox, or discard it altogether, when certain criteria, such
as failed authentications, are met.
Kucherawy Expires April 2, 2009 [Page 6]
Internet-Draft Authentication-Results IMAP Annotation September 2008
3. IMAP Server Implementation
An [IMAP] server conforming to this specification MUST implement
[ANNOTATE] and MUST report these annotations to the client if they
are attached to the message(s) being requested.
The name and format of the annotation can be found in Section 5 and
Section 8.
The [IMAP] server itself may do the message authentication prior to
serving the message to the client, or the MDA or one of the upstream
MTAs may do so. In the former case, the authentication is being done
after delivery and the results could be different (e.g. signatures
could expire, sender policies could change, etc.). It is important
to be aware that the results of authentication methods evaluated by
this server could be notably different from those results returned
during the original transit of the message. At the time this memo
was prepared, all known methods were intended for evaluation at time
of delivery, not at the time the message is served to the end user.
Kucherawy Expires April 2, 2009 [Page 7]
Internet-Draft Authentication-Results IMAP Annotation September 2008
4. IMAP Client Implementation
An [IMAP] client conforming to this specification will request the
"authresults" annotation when retrieving a message, and render those
results to users in some meaningful way.
The name and format of the annotation can be found in Section 5 and
Section 8.
Kucherawy Expires April 2, 2009 [Page 8]
Internet-Draft Authentication-Results IMAP Annotation September 2008
5. IMAP Annotation Format
This section discusses the genreal format of the content of the
annotation, and various aspects of it.
5.1. Formal Definition
The content of the annotation, as defined using [ABNF], is as
follows:
authres = 1*( version ":" authserv-id ":" methodspec
":" propspec )
; relays a single unit of authentication results
; information
version = 1*DIGIT
; indicates which version of this specification is in use;
; this specification is version "1"; the absence of a version
; implies this version of the specification
authserv-id = dot-atom-text
; see below for a description of this element;
; "dot-atom-text" is defined in section 3.2.4 of [MAIL]
methodspec = method "=" result
; indicates which authentication method was evaluated
propspec = ptype "." property "=" pvalue
; an indication of which property of the message
; was evaluated by the authentication scheme being
; applied to yield the reported result
method = token [ "/" version ]
; a method indicates which method's result is
; is represented by "result", and is one of the methods
; explicitly defined as valid in this document
; or is an extension method as defined below
result = token
; an indication of the results of the attempt to
; authenticate the message; see below for details
Kucherawy Expires April 2, 2009 [Page 9]
Internet-Draft Authentication-Results IMAP Annotation September 2008
ptype = "smtp" / "header" / "body" / "policy"
; indicates whether the property being evaluated was
; a parameter to an [SMTP] command, or was a value taken
; from a message header field, or was some property of
; the message body, or some other property evaluated by
; the receiving MTA
property = token
; if "ptype" is "smtp", this indicates which [SMTP]
; command provided the value which was evaluated by the
; authentication scheme being applied; if "ptype" is
; "header", this indicates from which header field the
; value being evaluated was extracted; if "ptype" is
; "body", this indicates the offset into the body at which
; content of interest was detected; if "ptype" is "policy"
; then this indicates the name of the policy which caused
; this header field to be added (see below)
pvalue = token / addr-spec
; the value extracted from the message property defined
; by the "ptype.property" construction; if the value
; identifies a mailbox, then it is an "addr-spec"
; as defined in section 3.4 of [MAIL];
The "token" and "value" are as defined in section 5.1 of [MIME].
The "token" used in a "result" above is further constrained by the
necessity of being enumerated in Section 5.3 or an amendment to it.
See Section 5.2 for a description of the "authserv-id" element.
The list of commands eligible for use with the "smtp" ptype can be
found in [SMTP] and subsequent amendments.
The "propspec" may be omitted if for example the method was unable to
extract any properties to do its evaluation yet has a result to
report.
The "ptype" and "property" values used by each authentication method
should be defined in the specification for that method (or its
amendments).
The "ptype" and "property" are case-insensitive.
A "ptype" value of "policy" indicates a policy decision about the
message not specific to a property of the message that could be
Kucherawy Expires April 2, 2009 [Page 10]
Internet-Draft Authentication-Results IMAP Annotation September 2008
extracted. For example, if a method would normally report a
"ptype.property" of "header.From" and no From: header field was
present, the method can use "policy" to indicate that no conclusion
about the authenticity of the message could be reached.
If the parsed "ptype.property" construction clearly identifies a
mailbox (in particular, smtp.mailfrom, smtp.rcpt, header.from,
header.sender), then the "pvalue" MUST be an "addr-spec". Other
properties (e.g. smtp.helo) may be evaluated, but the property MUST
still be expressed as a "token" for simplified parsing.
5.2. Authentication Identifier Fields
Every annotation has an authentication identifier field
("authserv-id" above). This is similar in syntax to a fully-
qualified domain name.
The authentication identifier field provides a unique identifier that
refers to the authenticating service within a given mail
administrative domain. The uniqueness of the identifier is
guaranteed by the mail administrative domain that generates it and
must pertain to exactly that one mail administrative domain. This
identifier is intended to be machine-readable and not necessarily
meaningful to users. Downstream MTAs may use this identifier to
determine whether or not the data contained in the AUTHRES parameter
can be trusted.
For tracing and debugging purposes, the authentication identifier
SHOULD be the domain name of the MTA performing the authentication
check whose result is being reported.
Examples of valid authentication identifiers are mail.example.org,
engineering.example.net and ms1.newyork.example.com.
5.3. Result Values
Each individual authentication method returns one of a set of
specific result values. The subsections below define these results
for the authentication methods specifically supported by this memo.
New methods not specified in this document intended to be supported
by the extension defined in this memo MUST include a similar result
table either in its defining memo or in a supplementary one.
5.3.1. DKIM and DomainKeys Results
The result values used by [DKIM] and [DOMAINKEYS] are as follows:
Kucherawy Expires April 2, 2009 [Page 11]
Internet-Draft Authentication-Results IMAP Annotation September 2008
none: The message was not signed.
pass: The message was signed, the signature(s) is (were) acceptable
to the verifier, and the signature(s) passed verification tests.
fail: The message was signed and the signature(s) is (were)
acceptable to the verifier, but it (they) failed the verification
test(s).
policy: The message was signed but the signature(s) is (were) not
acceptable to the verifier.
neutral: The message was signed but the signature(s) contained
syntax errors or were not otherwise able to be processed. This
result SHOULD also be used for other failures not covered
elsewhere in this list.
temperror: The message could not be verified due to some error which
is likely transient in nature, such as a temporary inability to
retrieve a public key. A later attempt may produce a final
result.
permerror: The message could not be verified due to some error which
is unrecoverable, such as a required header field being absent. A
later attempt is unlikley to produce a final result.
A signature is "acceptable to the verifier" if it passes local policy
checks (or there are no specific local policy checks). For example,
a verifier might require that the signature(s) on the message be
added by the domain identified in the From: header field of the
message, thus making third-party signatures unacceptable.
5.3.2. DKIM ADSP Results
The result values are used by [I-D.DRAFT-IETF-DKIM-SSP] as follows:
none: No DKIM author domain signing practises (ADSP) record was
published.
pass: A DKIM ADSP record was published which indicated the mail
should be signed with an author signature, and this message had
such a signature that validated.
unknown: No valid author signature was found on the message and
either the published ADSP was "unknown", or no policy was
published.
Kucherawy Expires April 2, 2009 [Page 12]
Internet-Draft Authentication-Results IMAP Annotation September 2008
signed: A valid author signature was found on the message and the
published ADSP was "unknown".
fail: No valid author signature was found on the message and the
published ASDP record indicated an "all" policy.
discard: No valid author signature was found on the message and the
published ADSP record indicated a "discardable" policy.
nxdomain: Evaluating the ADSP for the author's domain indicated that
the author's domain does not exist.
temperror: A DKIM policy could not be retrieved due to some error
which is likely transient in nature, such as a temporary DNS
error. A later attempt may produce a final result.
permerror: A DKIM policy could not be retrieved due to some error
which is likely not transient in nature, such as a permanent DNS
error. A later attempt is unlikely to produce a final result.
5.3.3. SPF and Sender-ID Results
The result values are used by [SPF] and [SENDERID] as follows:
none: No policy records were published by the sender's domain.
neutral: The sender's domain has asserted that it cannot or does not
want to assert whether or not the sending IP address is authorized
to send mail on behalf of the sender's domain.
pass: The client is authorized to inject or relay mail on behalf of
the sender's domain.
policy: The client is authorized to inject or relay mail on behalf
of the sender's domain according to the authentication method's
algorithm, but local policy dictates that the result is
unacceptable.
hardfail: This client is explicitly not authorized to inject or
relay mail on behalf of the sender's domain.
softfail: The sender's domain believes the client was not authorized
to inject or relay mail on its behalf but is unwilling to make a
strong assertion to that effect.
Kucherawy Expires April 2, 2009 [Page 13]
Internet-Draft Authentication-Results IMAP Annotation September 2008
temperror: The message could not be verified due to some error which
is likely transient in nature, such as a temporary inability to
retrieve a policy record from DNS. A later attempt may produce a
final result.
permerror: The message could not be verified due to some error which
is unrecoverable, such as a required header field being absent. A
later attempt is unlikley to produce a final result.
The distinction between and interpretation of "none" and "neutral"
under these methods is discussed further in [SPF].
The "policy" result would be returned if, for example, [SPF] returned
as "pass" result, but a local policy check matches the sending domain
to one found in an explicit list of unacceptable domains (e.g.
spammers).
5.3.4. iprev Results
The result values are used by the "iprev" method, defined in
Section 6, are as follows:
pass: The reverse DNS evaluation succeeded, i.e. the "reverse" and
"forward" lookup results were in agreement.
hardfail: The reverse DNS evaluation failed. In particular, the
"reverse" and "forward" lookups each produced results but they
were not in agreement.
softfail: The reverse DNS evaluation failed. In particular, one or
both of the "reverse" and forward lookups returned no data (i.e. a
DNS reply code of NODATA).
temperror: The reverse DNS evaluation could not be completed due to
some error which is likely transient in nature, such as a
temporary DNS error. A later attempt may produce a final result.
permerror: The reverse DNS evaluation could not be completed due to
some error which is unrecoverable (e.g. a DNS reply code of NODATA
or NXDOMAIN). A later attempt is unlikely to produce a final
result.
There is no "none" for this method since any TCP connection
delivering e-mail has an IP address associated with it, so some kind
of evaluation will always be possible.
Kucherawy Expires April 2, 2009 [Page 14]
Internet-Draft Authentication-Results IMAP Annotation September 2008
5.3.5. SMTP AUTH Results
The result values are used by the [AUTH] method are as follows:
none: SMTP authentication was not attempted.
pass: The SMTP client had authenicated to the server reporting the
result using the protocol described in [AUTH].
fail: The SMTP client had attempted to authenticate to the server
using the protocol described in [AUTH] but was not successful, yet
continued to send the message about which a result is being
reported.
temperror: The SMTP client attempted to authenticate using the
protocol described in [AUTH] but was not able to complete the
attempt due to some error which is likely transient in nature,
such as a temporary LDAP lookup error. A later attempt may
produce a final result.
permerror: The SMTP client attempted to authenticate using the
protocol described in [AUTH] but was not able to complete the
attempt due to some error which is likely not transient in nature,
such as a permanent LDAP lookup error. A later attempt is not
likely produce a final result.
Note that an agent making use of the data provided by this extension
SHOULD consider "fail" and "temperror" to be the synonymous in terms
of message authentication, i.e. the client did not authenticate.
5.3.6. Extension Result Codes
Additional result codes (extension results) may be defined in the
future by later revisions or extensions to this specification.
Extension results beginning with "x-" will never be defined as
standard fields; such names are reserved for experimental use.
Result codes not beginning with "x-" MUST be registered with the
Internet Assigned Numbers Authority (IANA) and published in an RFC.
See Section 8 for further details.
Implementations reporting new result codes MUST use the "x-" prefix
until such time as the new method is registered by IANA.
Extension results MUST only be used within trust domains that have
explicitly consented to use them. These results and the parameters
associated with them are not documented in RFCs. Therefore, they are
subject to change at any time and not suitable for production use.
Any MTA or MUA intended for production use SHOULD ignore or delete
Kucherawy Expires April 2, 2009 [Page 15]
Internet-Draft Authentication-Results IMAP Annotation September 2008
any AUTHRES parameter that includes an extension result.
5.4. Authentication Methods
This section defines the supported authentication methods and
discusses the proper means for applying experimental and other
extension methods.
5.4.1. Definition Of Initial Methods
As they are currently existing specifications for message
authentication, it is appropriate to define an authentication method
identifier for each of [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and
[SPF]. Therefore, the authentication method identifiers "auth",
"dkim", "domainkeys", "senderid" and "spf" respectively are hereby
defined for MTAs applying those specifications for e-mail message
authentication.
Furthermore, method "iprev" is defined in Section 6.
Finally, as its publication is imminent, this document also defines
"dkim-adsp" per [I-D.DRAFT-IETF-DKIM-SSP].
See Section 8 for details.
5.4.2. Extension Methods
Additional authentication method identifiers (extension methods) may
be defined in the future by later revisions or extensions to this
specification. Extension methods beginning with "x-" will never be
defined as standard fields; such names are reserved for experimental
use. Method identifiers not beginning with "x-" MUST be registered
with the Internet Assigned Numbers Authority (IANA) and published in
an RFC. See Section 8 for further details.
Extension methods may be defined for the following reasons:
1. To allow additional information from new authentication systems
to be communicated to MUAs. The names of such identifiers should
reflect the name of the method being defined, but should not be
needlessly long.
2. To allow the creation of "sub-identifiers" which indicate
different levels of authentication and differentiate between
their relative strengths, e.g. "auth1-weak" and "auth1-strong".
Implementations of new methods MUST use the "x-" prefix until such
time as the new method is registered by IANA.
Kucherawy Expires April 2, 2009 [Page 16]
Internet-Draft Authentication-Results IMAP Annotation September 2008
Experimental method identifiers MUST only be used within trust
domains that have explicitly consented to use them. These method
identifiers and the parameters associated with them are not
documented in RFCs. Therefore, they are subject to change at any
time and not suitable for production use. Any MTA or MUA intended
for production use SHOULD ignore or delete any AUTHRES parameter that
includes an experimental method identifier.
Kucherawy Expires April 2, 2009 [Page 17]
Internet-Draft Authentication-Results IMAP Annotation September 2008
6. The 'iprev' Authentication Method
This section defines an additional authentication method called
"iprev".
In general, "iprev" is an attempt to verify that a client appears to
be valid based on some DNS queries. Upon receiving a session
initiation of some kind from a client, the IP address of the client
peer is queried for matching names (i.e. a number-to-name
translation, also known as a "reverse lookup" or a "PTR" record
query). Once that result is acquired, a lookup of each of the names
(i.e. a name-to-number translation, or an "A" record query) thus
retrieved is done. The response to this second check should result
in at least one mapping back to the client's IP address.
More algorithmically: If the client peer's IP address is A, the list
of names to which A maps (after a "PTR" query) is the set N, and the
union of IP addresses to which each member of N maps (after an "A"
query) is L, then this test is successful if A is an element of L.
Section 5.5 of [SPF] contains more detail about this process as well
as some discussion of possible denial-of-service attacks. [DNS-IP6]
discusses the format of this query for the IPv6 case.
A successful test using this algorithm constitutes a result of "pass"
since the domain in which the client's PTR claims it belongs has
confirmed that claim. A failure to match constitutes a "hardfail".
There is no case in which "softfail" or "neutral" can be returned.
The remaining "temperror" and "permerror" cases refer respectively to
temporary and permanent DNS query errors.
There is some contention regarding the wisdom and reliability of this
test. For example, in some regions it can be difficult for this test
ever to pass because the practise of arranging to match the forward
and reverse DNS is infrequently observed. Therefore, the actual
implementation details of how a verifier performs an "iprev" test are
not specified here. The verifier MAY report a successful or failed
"iprev" test at its discretion having done some kind of check of the
validity of the connection's identity using DNS. It is incumbent
upon an agent making use of the reported "iprev" result to understand
what exactly that particular verifier is attempting to report.
[NOTE TO RFC EDITOR] This is a duplicate of a section in
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] and can be removed and
simply referenced if that draft reaches publication first.
Kucherawy Expires April 2, 2009 [Page 18]
Internet-Draft Authentication-Results IMAP Annotation September 2008
7. Conformance and Usage Requirements
Section 2, Section 3 and Section 4 specify the only requirements for
conformance to this specification.
Kucherawy Expires April 2, 2009 [Page 19]
Internet-Draft Authentication-Results IMAP Annotation September 2008
8. IANA Considerations
8.1. Annotation Registration
Per [IANA-CONSIDERATIONS], IANA is requested to register this new
IMAP annotation as per [ANNOTATE]. The template to be registered is
as follows:
To: iana(_at_)iana(_dot_)org
Subject: IMAP Annotate Registration
Please register the following IMAP Annotate item:
[X] Entry [ ] Attribute
Name: /authresults
Description: Results of message authentication tests, as
specified in [I-D.KUCHERAWY.SENDER-AUTH-HEADER]
Content-Type: text-plain; charset=us-ascii
Contact person: Murray S. Kucherawy
Contact email: msk(_at_)sendmail(_dot_)com
8.2. Email Authentication Method Name Registry
Names of message authentication methods supported by this
specification must be registered with IANA, with the exception of
experimental names as described in Section 5.4.2.
New entries are assigned only for values that have been documented in
a published RFC that has IETF Review, per [IANA-CONSIDERATIONS].
Each method must register a name, the specification that defines it,
one or more "ptype" values appropriate for use with that method, and
which "property" value(s) should be reported by that method.
The initial set of entries in this registry is as follows:
Kucherawy Expires April 2, 2009 [Page 20]
Internet-Draft Authentication-Results IMAP Annotation September 2008
+------------+----------+--------+----------------+--------------------+
| Method | Defined | ptype | property | value |
+------------+----------+--------+----------------+--------------------+
| auth | RFC4954 | smtp | auth | AUTH parameter of |
| | | | | the SMTP MAIL |
| | | | | command |
+------------+----------+--------+----------------+--------------------+
| dkim | RFC4871 | header | d | value of |
| | | | | signature "d" tag |
| | | +----------------+--------------------+
| | | | i | value of |
| | | | | signature "i" tag |
+------------+----------+--------+----------------+--------------------+
| dkim-adsp | [TBD] | header | from | value of From |
| | | | | header field |
| | | | | w/comments removed |
+------------+----------+--------+----------------+--------------------+
| domainkeys | RFC4870 | header | from | value of From |
| | | | | header field |
| | | | | w/comments removed |
| | | +----------------+--------------------+
| | | | sender | value of Sender |
| | | | | header field |
| | | | | w/comments removed |
+------------+----------+--------+----------------+--------------------+
| iprev | this | policy | iprev | client IP address |
| | document | | | |
+------------+----------+--------+----------------+--------------------+
| senderid | RFC4406 | header | name of header | value of header |
| | | | field used by | field used by PRA |
| | | | PRA | w/comments removed |
+------------+----------+--------+----------------+--------------------+
| spf | RFC4408 | smtp | mailfrom | envelope sender |
| | +--------+----------------+--------------------+
| | | smtp | helo | HELO/EHLO value |
+------------+----------+--------+----------------+--------------------+
[NOTE TO RFC EDITOR] This is a duplicate of the registry created by
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] and can be removed and
simply referenced if that draft reaches publication first.
8.3. Email Authentication Result Name Registry
Names of message authentication result codes supported by this
specification must be registered with IANA, with the exception of
experimental codes as described in Section 5.3.6.
New entries are assigned only for result codes that have been
Kucherawy Expires April 2, 2009 [Page 21]
Internet-Draft Authentication-Results IMAP Annotation September 2008
documented in a published RFC that has IETF Review, per
[IANA-CONSIDERATIONS]. Each code must register a name, the document
which establishes the registration, the authentication method(s)
which uses it, and either a definition of the semantics of its use or
a reference to the place where those semantics are defined.
The initial set of entries in this registry is as follows:
+-----------+----------+----------------+------------------------------+
| Code | Defined | Auth Method(s) | Meaning |
+-----------+----------+----------------+------------------------------+
| none | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | dkim-adsp | section 2.4.2 |
| | +----------------+------------------------------+
| | | spf | section 2.4.3 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | auth | section 2.4.5 |
+-----------+----------+----------------+------------------------------+
| pass | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | dkim-adsp | section 2.4.2 |
| | +----------------+------------------------------+
| | | spf | section 2.4.3 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.4 |
| | +----------------+------------------------------+
| | | auth | section 2.4.5 |
+-----------+----------+----------------+------------------------------+
| fail | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | dkim-adsp | section 2.4.2 |
| | +----------------+------------------------------+
| | | auth | section 2.4.5 |
+-----------+----------+----------------+------------------------------+
| policy | this | dkim | section 2.4.1 |
| | document | domainkeys | |
+-----------+----------+----------------+------------------------------+
| neutral | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | spf | section 2.4.3 |
| | | sender-id | |
Kucherawy Expires April 2, 2009 [Page 22]
Internet-Draft Authentication-Results IMAP Annotation September 2008
+-----------+----------+----------------+------------------------------+
| temperror | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | dkim-adsp | section 2.4.2 |
| | +----------------+------------------------------+
| | | spf | section 2.4.3 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.4 |
| | +----------------+------------------------------+
| | | auth | section 2.4.5 |
+-----------+----------+----------------+------------------------------+
| permerror | this | dkim | section 2.4.1 |
| | document | domainkeys | |
| | +----------------+------------------------------+
| | | dkim-adsp | section 2.4.2 |
| | +----------------+------------------------------+
| | | spf | section 2.4.3 |
| | | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.4 |
| | +----------------+------------------------------+
| | | auth | section 2.4.5 |
+-----------+----------+----------------+------------------------------+
| nxdomain | this | dkim-adsp | section 2.4.2 |
| | document | | |
+-----------+----------+----------------+------------------------------+
| signed | this | dkim-adsp | section 2.4.2 |
| | document | | |
+-----------+----------+----------------+------------------------------+
| unknown | this | dkim-adsp | section 2.4.2 |
| | document | | |
+-----------+----------+----------------+------------------------------+
| discard | this | dkim-adsp | section 2.4.2 |
| | document | | |
+-----------+----------+----------------+------------------------------+
| hardfail | this | spf | section 2.4.3 |
| | document | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
| softfail | this | spf | section 2.4.3 |
| | document | sender-id | |
| | +----------------+------------------------------+
| | | iprev | section 2.4.4 |
+-----------+----------+----------------+------------------------------+
Kucherawy Expires April 2, 2009 [Page 23]
Internet-Draft Authentication-Results IMAP Annotation September 2008
[NOTE TO RFC EDITOR] This is a duplicate of the registry created by
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] and can be removed and
simply referenced if that draft reaches publication first.
Kucherawy Expires April 2, 2009 [Page 24]
Internet-Draft Authentication-Results IMAP Annotation September 2008
9. Security Considerations
The following security considerations apply when applying or
processing the authresults IMAP annotation:
9.1. Misleading Results
Until some form of service for querying the reputation of a sending
agent is widely deployed, the existence of this annotation indicating
a "pass" does not render the message trustworthy. It is possible for
an arriving piece of spam or other undesirable mail to pass checks by
several of the methods enumerated above (e.g. a piece of spam signed
using [DKIM] by the originator of the spam, which might be a spammer
or a compromised system).
9.2. Attacks Against Authentication Methods
If an attack becomes known against an authentication method, clearly
then the agent verifying that method can be fooled into thinking an
inauthentic message is authentic, and thus the value of this
annotation can be misleading. It follows that any attack against the
authentication methods supported by this document (and later
amendments to it) is also a security consideration here.
9.3. Intentionally Malformed Data
It is possible for an attacker to include data in a message which is
extraordinarily large or otherwise malformed in an attempt to
discover or exploit weaknesses in parsing code. Implementors must
thoroughly verify all such data received from [IMAP] servers and be
robust against intentionally as well as unintentionally malformed
data.
9.4. Compromised Internal Hosts
An internal MUA or MTA which has been compromised could generate mail
with forged data, eventually generating an annotation which endorses
it. Although it is clearly a larger concern to have compromised
internal machines than it is to prove the value of this proposal,
this risk can be mitigated by arranging that internal MDAs not attach
this data if it claims to have been added by a trusted border MTA (as
described above) yet the [SMTP] connection is not coming from an
internal machine known to be running an authorized MTA. However, in
such a configuration, legitimate MDAs will have to add this data when
legitimate internal-only messages are generated.
Kucherawy Expires April 2, 2009 [Page 25]
Internet-Draft Authentication-Results IMAP Annotation September 2008
10. References
10.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
[ANNOTATE]
Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension",
RFC 5257, June 2008.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
10.2. Informative References
[AUTH] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.
[DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4817, May 2007.
[DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[DOMAINKEYS]
Delany, M., "Domain-based Email Authentication Using
Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
May 2007.
[I-D.DRAFT-CROCKER-EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture",
I-D draft-crocker-email-arch, May 2007.
[I-D.DRAFT-IETF-DKIM-SSP]
Allman, E., Delany, M., and J. Fenton, "DKIM Author
Signing Practices", I-D draft-ietf-dkim-ssp-06,
September 2008.
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-ESMTP]
Kucherawy, M., "SMTP Service Extension for Indicating
Message Authentication Status",
Kucherawy Expires April 2, 2009 [Page 26]
Internet-Draft Authentication-Results IMAP Annotation September 2008
I-D draft-kucherawy-sender-auth-esmtp-01, September 2008.
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status",
I-D draft-kucherawy-sender-auth-header-16, September 2008.
[IANA-CONSIDERATIONS]
Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
October 1998.
[LMTP] Meyers, J., "Local Mail Transport Protocol", RFC 2033,
October 1996.
[SENDERID]
Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
Kucherawy Expires April 2, 2009 [Page 27]
Internet-Draft Authentication-Results IMAP Annotation September 2008
Appendix A. Acknowledgements
The author wishes to acknowledge the following for their review and
constructive criticism of this proposal: (add names here)
Kucherawy Expires April 2, 2009 [Page 28]
Internet-Draft Authentication-Results IMAP Annotation September 2008
Appendix B. Examples
This section presents some examples of the use of this IMAP
annotation.
(add examples here)
Kucherawy Expires April 2, 2009 [Page 29]
Internet-Draft Authentication-Results IMAP Annotation September 2008
Appendix C. Public Discussion
[REMOVE BEFORE PUBLICATION]
Public discussion of this proposed specification is handled via the
mail-vet-discuss(_at_)mipassoc(_dot_)org mailing list. The list is open.
Access to subscription forms and to list archives can be found at
http://mipassoc.org/mailman/listinfo/mail-vet-discuss.
Kucherawy Expires April 2, 2009 [Page 30]
Internet-Draft Authentication-Results IMAP Annotation September 2008
Author's Address
Murray S. Kucherawy
Sendmail, Inc.
6475 Christie Ave., Suite 350
Emeryville, CA 94608
US
Phone: +1 510 594 5400
Email: msk+ietf(_at_)sendmail(_dot_)com
Kucherawy Expires April 2, 2009 [Page 31]
Internet-Draft Authentication-Results IMAP Annotation September 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr(_at_)ietf(_dot_)org(_dot_)
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kucherawy Expires April 2, 2009 [Page 32]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html