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, an optional
version 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,
an optional "reason" string plus optional
"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" and "value" are as defined in
section 5.1 of . The "token" used in a "result" above is further
constrained by the necessity of being enumerated
in or an amendment to
it. 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
"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. 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. 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 header
field defined in this memo MUST include a similar
result table either in its defining memo or in
a supplementary one. The result values used by
and
are 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. 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. The result values are used by
as follows:
No DKIM policy
author signing practises (ASP)
record was published. A DKIM ASP policy
was published which indicated the
mail should be signed with an
author signature, and this message
had such a signature that
validated. No valid author
signature was found on the message
and either the published ASP policy
was "unknown", or no policy was
published. A valid author
signature was found on the message
and the published ASP policy
was "unknown". No valid author
signature was found on the message
and the published ASP record
indicated an "all" policy. No valid author
signature was found on the message
and the published ASP record
indicated a "discardable"
policy. Evaluating
the ASP for the author's domain
indicated that the author's domain
does not exist. 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 not transient
in nature, such as a permanent
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
whether or not the sending IP
address is authorized to send
mail on behalf of the sender's
domain. The client is
authorized to inject or relay
mail on behalf of the sender's
domain. 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. 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 distinction between and interpretation
of "none" and "neutral" under these
methods is discussed further in
. The "policy" result would be returned if,
for example, 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). 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 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. 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. 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
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 header field SHOULD
consider "fail" and "temperror"
to be the synonymous in terms of message
authentication, i.e. the client did not
authenticate. 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 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 any Authentication-Results
header field that includes an extension
result. This section defines the supported authentication
methods and discusses the proper means for
applying experimental and other extension
methods. 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. Furthermore, method "iprev" is defined in
. Finally, as its publication is imminent,
this document also defines "dkim-asp" per
.
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 field
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. Each "method" MUST refer to an authentication method
declared in the IANA registry, or an extension method
as defined in , and each
"result" MUST refer to a result code declared in the
IANA registry, or an extension result code as defined
in . See
for further information about
the registered methods and result codes. 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 the result code
registry, or a "ptype" not listed in the
corresponding registry for such values as defined
in . Moreover, an MUA MUST
ignore a result indicated for any "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
below. If a site's local policy is to consider a
non-recoverable failure result (e.g. "fail" for
DKIM, "hardfail" for SPF or "discard" for DKIM-ASP)
for any particular authentication method as
justification to reject the message
completely, the border MTA SHOULD issue an
rejection response to the
message rather than adding this header with
the failure 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. The same MAY also be done for local policy
decisions overriding the results of the
authentication methods (e.g. the "policy" result
codes described in . 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:
Names of message authentication result codes
supported by this specification must be registered
with IANA, with the exception of experimental
codes as described in
. New entries are assigned only for result codes
that have been documented in a published RFC
that has IETF Consensus, per
.
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:
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 Author 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,
Dave Crocker,
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 presence of
"none" (and 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.