Message Header Field for Indicating Message Authentication Status
Sendmail, Inc.6475 Christie Ave., Suite 350EmeryvilleCA94608US+1 510 594 5400msk+ietf@sendmail.com
Security
Individual submissionInternet-DraftStandards Track This memo defines a new message header field for use with
electronic mail messages to indicate the results of
message authentication efforts. Mail user agents
(MUAs) may use this message header field to relay that
information in a convenient way to users or to make
sorting and filtering decisions. This memo defines a new message header field for electronic
mail messages which presents the results of a message
authentication effort in a machine-readable format.
The intent is to create a place to collect such data when
message authentication mechanisms are in use so that a
Mail User Agent (MUA) can provide a recommendation to the
user as to the validity of the message's origin
and possibly the integrity of its content. This memo defines both the format of this new header field,
and discusses the implications of its presence or
absence. [UPDATE PRIOR TO FINAL VERSION]
At the time of publication of this draft,
,
,
,
and
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 MUAs. Although defined a header field
called Received-SPF for this purpose, that header field
is specific to the conveyance of SPF and similar results
only and thus is insufficient to satisfy the requirements
enumerated below. The header field defined in this memo is expected
to serve several purposes:
Convey to MUAs from filters and Mail
Transfer Agents (MTAs) the results of
various message authentication checks being
applied; Provide a common location for the
presentation of this data; Create an extensible framework for
reporting new authentication methods as
such emerge; 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. This memo establishes no new requirements on
existing protocols or servers, as there is
currently no standard place for the described
data to be collected or presented. In particular, this memo establishes no requirement
on MTAs to reject or filter arriving messages
which do not pass authentication checks. The
data conveyed by the defined header field's
contents are for the information of MUAs
and filters and should be used at their
discretion. 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 . 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. 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
describe such cases, they are not meant to be
excluded from this specification. See
for further discussion on e-mail system
architecture. This section gives a general overview of the format
of the header field being defined, and then provides more
formal specification. The new header field being defined here is called
"Authentication-Results". It is a Structured Header
Field as defined in
and thus all of the related definitions in that
document apply. This new header field MUST be added at the top of
the message as it transits MTAs which do
authentication checks so some idea of how far away
the checks were done can be inferred. It therefore
should be treated as a Trace Header Field as
defined in and thus all of
the related definitions in that document
apply. The value of the header field (after removing
comments) consists
of an authentication identifier and then a series
of "method=result" statements indicating which
authentication method(s) were applied and their
respective results, and then, for each applied
method, one or more "property=value" statements
indicating which message properties were evaluated
to reach that conclusion. The header field MAY appear more than once in a
single message, or more than one result MAY be
represented in a single header field, or a
combination of these MAY be applied. Formally, the header field is specified as
follows using : The "token" is as defined in section 5.1 of
. See for a description
of the "authserv-id" element. The list of commands eligible for use with the
"smtp" ptype can be found in
and subsequent
amendments. "CFWS" is as defined in section 3.2.3 of
. 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 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
"value" 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. Every Authentication-Results header field
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. MUAs may use
this identifier to determine whether or not
the data contained in an Authentication-Results
header field 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. Result values indicate the outcomes of
authentication results. The general descriptions
of the allowed results are as follows:
The authentication
method was not used by the sender of this
message. An example of this might be
a verifier reporting
that the message was not signed. The message passed the
authentication tests. (This may require
accessing an authentication policy of some
kind published by the sending domain.) The message failed the
authentication tests. (This may require
accessing an authentication policy of some
kind published by the sending domain.) The message failed the
authentication tests, and the
authentication method has either an
explicit (published by the sending domain)
or implicit policy, but the policy being
used doesn't require successful
authentication of all messages from that
domain. The authentication
method completed without errors, but was
unable to reach either a positive or
negative result about the message. A temporary
(recoverable) error occurred attempting to
authenticate the message; either the
process couldn't be completed locally, or
(for methods requiring a policy to
be accessed) there was a temporary failure
retrieving the sending domain's policy. A
later retry may produce a final
result. A permanent
(unrecoverable) error occurred attempting
to authenticate the message; either the
process couldn't be completed locally, or
(for methods requiring a policy to be
accessed) there was a permanent failure
retrieving the sending domain's policy. A
later retry is unlikely to yield a final
result. For each specific method, a mapping is required
between the various possible outcomes of the
method and the values above. The subsections
below define these mappings for the authentication
methods specifically supported by this memo.
New methods not specified in this document intended
to be supported by header field defined in this
memo MUST include a similar mapping table either
in its defining memo or in a supplementary
one. The result values are used by
and
as follows:
The message was
not signed. The message was
signed, the signature(s) is (were)
acceptable to the verifier, and
the signature(s) passed
verification tests. The message
was signed and the signature(s)
is (were) acceptable to the
verifier, but it (they) failed the
verification test(s). The message
was signed but the signature(s)
is (were) not acceptable to the
verifier. 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. 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. 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 result values are used by
as follows:
No DKIM policy
record was published. A DKIM policy
was published that indicates all
mail should be signed with an
author signature, and this message
had such a signature that
validated. A DKIM policy
was published that indicates all
mail should be signed with an
author signature, and this message
was not signed or had a signature
that did not validate. Moreover,
the policy requested that such
messages be discarded. A DKIM policy
was published that indicates all
mail should be signed with an
author signature, and this message
was not signed or had a signature
that did not validate. 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. 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 is
unlikely to produce a final
result. The result values are used by
and
as follows:
No policy records
were published by the sender's
domain. The sender's
domain has asserted that it
cannot or does not want to assert
a policy record suitable for
evaluation of the authentication
method. The client is
authorized to inject or relay
mail on behalf of the sender's
domain. This client
is explicitly not authorized
to inject or relay mail on behalf
of the sender's domain. 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. 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. 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 result values are used by the
"iprev" method, defined in
, are as follows:
The reverse DNS
evaluation succeeded, i.e. the
"reverse" and "forward" lookup
results were in agreement. The reverse
DNS evaluation failed. In
particular, the "reverse" and
"forward" lookups each produced
results but they were not in
agreement. 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). 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. The reverse
DNS evaluation could not be
completed due to some error which
is unrecoverable (e.g. a DNS reply
code of NXDOMAIN). A later
attempt is unlikely to produce a
final result. The result values are used by the
method are as
follows:
SMTP
authentication was not
attempted. The SMTP client
had authenicated to the server
reporting the result using
the protocol described in
. The SMTP
client had attempted to
authenticate to the server using
the protocol described in
but was
not successful, yet continued to
send the message about which a
result is being reported. The SMTP
client attempted to authenticate
using the protocol described in
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. Note that an agent making use of the data
provided by this header field SHOULD
consider "hardfail" and "temperror"
to be the synonymous in terms of message
authentication, i.e. the client did not
authenticate. As they are currently existing specifications for
message authentication, it is appropriate to
define an authentication method identifier for each of
,
,
,
and
.
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. See
for details. 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
for further details. Extension methods may be defined for the
following reasons:
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. 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. Authentication method implementors are encouraged
to provide adequate information, via
comments if necessary, to
allow an MUA developer to understand or relay
ancilliary details of authentication results. For
example, if it might be of interest to relay what
data was used to perform an evaluation, such
information could be relayed as a comment in the
header field, such as: 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
Authentication-Results header that includes an
experimental method identifier. 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 contains more
detail about this process as well as some discussion
of possible denial-of-service attacks.
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. This specification makes no attempt to evaluate the
relative strengths of various message authentication
methods that may become available. As such, the order
of the presented authentication methods and results
MUST NOT be used to determine the importance or strength
of any given method over another. Instead, the MUA must
interpret the result of each method based on its knowledge
of what that method evaluates. The "method" MUST refer to an authentication method
declared in the IANA registry, or an extension method
as defined in . See
for further information about
the registered methods. An MTA compliant with this specification MUST add this
header field (after performing one or more message
authentication tests) to indicate at which host
which the test was done, which test got applied and what
the result was. If an MTA applies more than one such
test, it MUST either add this header field once per test,
or one header field indicating all of the results. An
MTA MUST NOT add a result to an existing header. An MTA MAY add this header field containing only the
authentication identifier portion to indicate explicitly
that no message authentication schemes were applied prior
to delivery of this message. In order to ensure non-ambiguous results and avoid
the impact of false header fields, an MUA SHOULD
NOT interpret this header field unless specifically
instructed to do so by the user or administrator.
That is, this interpretation should not be "on by
default". Naturally then, users or administrators
should not activate such a feature unless they are
certain the header field will be added by the
border MTA that accepts the mail that is
ultimately read by the MUA, and instances of the
header field appearing to be from within the trust
domain but actually added by foreign MTAs will be
removed before delivery. Furthermore, an MUA SHOULD NOT interpret this
header field unless the authentication identifier
it bears appears to be one within its own trust
domain as configured by the user or
administrator. An MUA MUST ignore any result reported using
a "result" not specified in this document, or a
"ptype" not listed in the corresponding registry
for such values as defined in
. Moreover, an MUA MUST
ignore a result indicated for a "method" it
does not support. An MUA SHOULD NOT reveal these results to
end users unless the results are accompanied by,
at a minimum, some associated reputation data about
the message that was authenticated. For
example, an attacker could register
examp1e.com (note the digit "one") and send
signed mail to intended victims; a verifier
would detect that the signature was valid and
report a "pass" even though it's clear the
domain name was intended to mislead. See
for further
discussion. As stated in ,
this header field SHOULD be treated as though
it were a trace header field as defined in section
3.6 of , and
hence MUST NOT be reordered and MUST be
prepended to the message, so that there is
generally some indication upon delivery of where
in the chain of handling MTAs the message
authentication was done. Further discussion of this can be found in the
below. If a site's local policy is to consider a
"hardfail" for any particular authentication
method justification to reject the message
completely, the border MTA SHOULD issue an
rejection response to the
message rather than adding this header with
a "hardfail" result and allowing it to proceed
toward delivery. This is more desirable than
allowing the message to reach an internal host's
MTA or spam filter, thus possibly generating a
local rejection such as a to
a forged originator. Such rejections at the SMTP protocol level are not
possible if local policy is enforced at the MUA
and not the MTA. Unfortunately, this may be
a common scenario. For security reasons, any MTA conforming to this
specification MUST delete any discovered instance of
this header field which claims to have been added within
its trust boundary and did not come from another
trusted MTA. For example, an MTA (border or otherwise)
for example.com receiving a message MUST delete any
instance of this header field bearing an authentication
identifier indicating the header field was added within
example.com prior to adding its own header fields. This
may mean each MTA will have to be equipped with a list of
internal MTAs known to be compliant (and hence
trustworthy). Furthermore, a border MTA MAY elect simply to remove all
instances of this header field on mail crossing
into its trust boundary. A formal definition of "trust boundary" is deliberately
not made here. It is entirely possible that a border
MTA for example.com might explicitly trust authentication
results asserted by upstream host example.net even though
they exist in completely disjoint administrative
boundaries. In that case the border MTA MAY elect not to
delete those results; moreover, the upstream host doing
some authentication work could apply a signing technology
such as on its own results
to assure downstream hosts of their authenticity. An
example of this is provided in
. Similarly, in the case of messages signed using
or other message signing methods
that sign headers, this may invalidate one or more
signature on the message if they included the header
field to be removed at the time of signing. This
behaviour can be desirable since there's little value in
validating the signature on a message with forged
headers. However, signing agents MAY therefore elect to
omit these header fields from signing to avoid this
situation. An MTA SHOULD remove any instance of this header bearing
a version (express or implied) that it does not
support. However, an MTA MUST remove such a header
if the connection relaying the
message is from not a trusted internal MTA. An MTA or gateway conforms to this specification if it
applies one or more message authentication mechanisms and
inserts a header field corresponding to this specification
after doing so and prior to delivery (per
) and removes apparently improper
headers (per ). MTAs that are relaying mail rather than delivering it,
i.e. are not part of an intended recipient's trust
boundary, MAY perform message authentication or even take
actions based on the results found, but SHOULD NOT add an
"Authentication-Results" header field if relaying (rather
than rejecting or discarding at the gateway). Conversely,
an MTA doing local delivery and some form of message
authentication MUST add this header field prior to
delivering the message in order to be compliant. An
exception to the former case is described in
. A minimal implementation that does at least one message
authentication check will add the header field defined by
this memo prior to invoking local delivery procedures. IANA is requested to register a new header field
and to create a new table as described below. Per
,
the "Authentication-Results:" header field is
added to the IANA Permanent Message Header Field
Registry. The following is the registration
template:
Names of message authentication methods supported
by this specification must be registered with
IANA, with the exception of experimental names as
described in . New entries are assigned only for values
that have been documented in a published RFC
that has IETF Consensus, per
.
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:
The following security considerations apply when
applying or processing the "Authentication-Results"
header field: An MUA that accesses a mailbox whose mail is
handled by a non-conformant MTA, and understands
Authentication-Results header fields, could
potentially make false conclusions based on forged
header fields. A malicious user or agent could
forge a header field using the destination MX for
a receiving domain as the hostname token in the
value of the header, and with the rest of the
value claim that the message was properly
authenticated. The non-conformant MTA would fail
to strip the forged header field, and the MUA
could inappropriately trust it. It is for this reason an MUA should not have
processing of the "Authentication-Results" header
field enabled by default; instead it should be
ignored, at least for the purposes of enacting
filtering decisions, unless specifically enabled
by the user or administrator after verifying that
the border MTA is compliant. It is acceptable to
have an MUA aware of this specification, but have
an explicit list of hostnames whose
"Authentication-Results" header
fields are trustworthy; however, this list should
initially be empty. Proposed alternate solutions to this problem are
nascent. Possibly the simplest is a digital
signature on the header field that can be verified
by a posted public key. Another would be a means
to interrogate the MTA that added the header field
to see if it is actually providing any message
authentication services and saw the message in
question, but this isn't especially palatable.
In either case, a mechanism needs to exist to
verify that the host that appears to have added the
header field (a) actually did so, and (b) is
legitimately adding that header field for this
delivery. Until some form of service for querying
the reputation of a sending agent is widely
deployed, the existence of this header field
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
by the originator of the
spam, which might be a spammer or a compromised
system). In particular, this issue is not resolved
by forged header removal discussed above. Hence, MUAs must take some care with use of this
header even after possibly malicious headers
are scrubbed. Mitigation of the forged header attack can also
be accomplished by moving the authentication
results data into meta-data associated with
the message. In particular, an
extension could be
established which is used to communicate
authentication results from the border MTA to
intermediate and delivery MTAs; the latter of
these could arrange to store the authentication
results as meta-data retrieved and rendered
along with the message by an
client aware of a similar extension in that
protocol. The delivery MTA would be told to
trust data via this extension only from
MTAs it trusts, and border MTAs would not accept
data via this extension from any source. There is
no vector in such an arrangement for forgery of
authentication data by an outside agent. Despite the requirements of
, header fields can
sometimes be reordered enroute by
intermediate MTAs. The goal of requiring header
field addition only at the top of a message is an
acknowledgement that some MTAs do reorder
header fields, but most do not. Thus, in the
general case, there will be some indication of
which MTAs (if any) handled the message after the
addition of the header field defined here. Section 5.5 of describes
a DNS-based denial-of-service attack for verifiers
that attempt to DNS-based identity verification
of arriving client connections. A verifier
wishing to do this check and report this
information SHOULD take care not to go to unbounded
lengths to resolve "A" and "PTR" queries.
MUAs or other filters making use of an "iprev"
result specified by this memo SHOULD be aware
of the algorithm used by the verifier reporting
the result and thus be aware of its
limitations. Failing to follow the instructions of
can result in a
denial-of-service attack caused by the
generation of messages
(or equivalent) to addresses which did not
send the messages being rejected. describes a procedure
for scrubbing headers which may contain forged
authentication results about a message. A
compliant installation will have to include at
each MTA a list of other MTAs known to be
compliant and trustworthy. Failing to keep this
list current as internal infrastructure changes
may expose a domain to attack. 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 header field 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. It is possible for an attacker to add an
Authentication-Results: header field which
is extraordinarily large or otherwise malformed
in an attempt to discover or exploit weaknesses
in header field parsing code. Implementors must
thoroughly verify all such header fields received
from MTAs and be robust against intentionally as
well as unintentionally malformed header
fields. An internal MUA or MTA which has been compromised
could generate mail with a forged From: header
and a forged Authentication-Results: header
which endorses it. Although it is clearly a
larger concern to have compromised internal
machines than it is to prove the value of this
header, this risk can be mitigated by arranging
that internal MTAs will remove this header
field if it claims to have been added by a trusted
border MTA (as described above) yet the
connection is not coming from
an internal machine known to be running an
authorized MTA. However, in such a configuration,
legitimate MTAs will have to add this header
field when legitimate internal-only messages
are generated. This is also covered in
. Augmented BNF for Syntax
Specifications: ABNF
Brandenburg InternetWorking
THUS plc.
Registration Procedures for Message
Header Fields
Nine By Nine
BEA
HP Labs
Key words for use in RFCs to Indicate
Requirement Levels
Harvard University
Internet Message Format
Qualcomm, Inc.
Multipurpose Internet Mail
Extensions (MIME) Part One: Format of
Internet Message Bodies SMTP Service Extension for
Authentication
Google, Inc.
Isode Limited
DomainKeys Identified Mail (DKIM)
Signatures
Sendmail, Inc.
PGP Corporation
Yahoo!, Inc.
Yahoo!, Inc.
Cisco Systems, Inc.
Cisco Systems, Inc.
DNS Extensions to Support IP
Version 6
Cisco
Microsoft
6WIND
AFNIC
Domain-based Email Authentication
Using Public Keys Advertised in the
DNS (DomainKeys)
Yahoo! Inc.
An Extensible Message Format for
Delivery Status Notifications
University of Tennessee
Lucent Technologies
Internet Mail Architecture
Brandenburg InternetWorking
DKIM Sender Signing Practices
Sendmail, Inc.
Yahoo!, Inc.
Cisco Systems, Inc.
Guidelines for Writing an IANA
Considerations Section in RFCs Internet Message Access Protocol -
Version 4rev1
University of Washington
Sender ID: Authenticating
E-Mail
Microsoft Corp.
pobox.com
Simple Mail Transfer Protocol Sender Policy Framework (SPF) for
Authorizing Use of Domains in E-Mail,
Version 1 The author wishes to acknowledge the following for their
review and constructive criticism of this proposal:
Eric Allman,
Mark Delany,
Frank Ellermann,
Jim Fenton,
Philip Guenther,
Tony Hansen,
Paul Hoffman,
Eliot Lear,
John Levine,
Miles Libbey,
Charles Lindsey,
S. Moonesamy,
Juan Altmayer Pizzorno,
Michael Thomas. Implementors of this proposal should be aware
that many MUAs are unlikely to be retrofitted to
support the new header field and its semantics. In
the interests of convenience and quicker
adaptation, a delivery MTA might want to
consider adding things that are processed by
existing MUAs in addition to the Authentication-Results
header field. One suggestion is to include a Priority:
header field, on messages that don't already have such a
header field, containing a value that reflects the
strength of the authentication that was accomplished,
e.g. "low" for weak or no authentication, "normal" or
"high" for good or strong authentication. Some modern MUAs can already filter based on
the content of this header field. However, there is
keen interest in having MUAs make some kind of
graphical representation of this header field's meaning
to end users. Until this capability is added, other
interim means of conveying authentication results may
be necessary while this proposal and its successors
are adopted. This section presents some examples of the use of this
header field to indicate authentication results. The "Authentication-Results" header field is
completely absent. The MUA may make no conclusion
about the validity of the message. This could be
the case because the message authentication
services were not available at the time of
delivery, or no service is provided, or the MTA
is not in compliance with this specification. The "Authentication-Results" header field is
present, indicating that the delivering MTA (which
is named in the value of the header field)
conforms to this specification. The absence of
any method and result tokens indicates that no
message authentication was done. The "Authentication-Results" header field is
present, indicating that the border MTA
(which is identified in the value of the header
field) conforms to this specification.
Furthermore, the message was authenticated
by that MTA via the method specified
in . The MUA could
extract and relay this extra information if
desired. The "Authentication-Results" header field is
present, indicating the delivering MTA (which is
identified in the value of the header field)
conforms to this specification. Furthermore, the
sender authenticated herself/himself to the MTA
via a method specified in ,
and both and
checks were done and
passed. The MUA could extract and relay this
extra information if desired. Two "Authentication-Results" header fields are
not required since the same host did all of the
checking. The authenticating agent could have
consolidated all the results into one header
field. This example illustrates a scenario in which
a remote user on a dialup connection (example.net)
sends mail to a border MTA (example.com)
using SMTP authentication to prove identity.
The dialup provider has been explicitly authorized
to relay mail as "example.com" resulting in
passes by the SPF and SenderID checks. The "Authentication-Results" header field is
present, indicating conformance to this
specification. It is present twice because two
different MTAs in the chain of delivery did
authentication tests. The first,
"mail-router.example.com" reports that
and
were both used, and
passed but
failed. In the
case, additional data is
provided in the comment field, which the MUA can
choose to render if desired. The second MTA, identifying itself as
"auth-checker.example.com", reports that it did a
test (which failed) and a
test
(which passed). Again, additional
data about one of the tests is provided as a
comment, which the MUA may choose to render. Since different hosts did the two sets of
authentication checks, the header fields cannot be
consolidated in this example. This example illustrates more typical transmission
of mail into "example.com" from a user on a
dialup connection "example.net". The user appears
to be legitimate as he/she had a valid password
allowing authentication at the border MTA using
. The
and tests failed since
"example.com" has not granted "example.net"
authority to relay mail on its behalf. However,
the test passed because
the sending user had a private key matching one
of "example.com"'s published public keys and
used it to sign the message. In this example we see multi-tiered authentication
with an extended trust boundary. The message was sent from someone at example.com's
New York office (newyork.example.com) to a
mailing list managed at an intermediary.
The message was signed at the origin using
. The message was sent to a mailing list service
provider called example.net which is used by
example.com. There meetings@example.net
is expanded to a long list of recipients, one
of which is at the Chicago office. In this
example, we will assume that the trust boundary
for chicago.example.com includes the mailing list
server at example.net. The mailing list server there first authenticated
the message and affixed an
Authentication-Results: header field indicating
such. It then altered the message by affixing some
footer text to the body including some
administrivia such as unsubscription
instructions. Finally, the mailing list server
affixes a second signature
and begins distribution of the message. The border MTA for chicago.example.com explicitly
trusts results from mail-router.example.net
so that header is not removed. It performs
evaluation of both signatures and determines
that the first (most recent) is a "pass" but,
because of the aforementioned modifications, the
second is a "hardfail". However, the first
signature included the Authentication-Results:
header added at mail-router.example.net
which validated the second signature.
Thus, indirectly, it can be determined that
the authentication claimed by both signatures are
indeed valid. [REMOVE BEFORE PUBLICATION] Public discussion of this proposed specification
is handled via the mail-vet-discuss@mipassoc.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.