After discussing this at length with a few people at both IETF and
MAAWG, it sounds like we'll eventually need an ESMTP extension to create
an unforgeable channel between the border MTAs and the MUAs/LDAs. The
time to implement this is a lot longer than a header field so it's
important to have both, but it's quite possibly the more long-term solution.
Attached is a new draft I'll be submitting soon which creates such an
extension. On the heels of this I intend to present a third draft which
defines an IMAP annotation to be used to store authentication results
along with messages as message metadata in a message store.
Comments requested ("RFC", after all!).
-MSK
Individual submission M. Kucherawy
Internet-Draft Sendmail, Inc.
Intended status: Standards Track October 2007
Expires: April 3, 2008
SMTP Service Extension for Indicating Message Authentication Status
draft-kucherawy-sender-auth-esmtp-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 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Kucherawy Expires April 3, 2008 [Page 1]
Internet-Draft Authentication-Results SMTP Extension October 2007
Abstract
This memo defines an extension to the Simple Mail Transfer protocol
(SMTP) service whereby a server can indicate its ability to accept
and apply information regarding the efforts of upstream SMTP servers
to establish authenticity of the message via various authentication
methods.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
2. Framework for the Authentication Results Extension . . . . . . 6
3. The Authentication-Results Service Extension . . . . . . . . . 7
3.1. Client Implementation . . . . . . . . . . . . . . . . . . 7
3.2. Server Implementation . . . . . . . . . . . . . . . . . . 7
3.3. MAIL Command Extension . . . . . . . . . . . . . . . . . . 8
3.4. Extension Fields . . . . . . . . . . . . . . . . . . . . . 9
4. Conformance and Usage Requirements . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Email Authentication Method Name Registry . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Trusting SMTP Clients . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 16
B.1. Single authentication result . . . . . . . . . . . . . . . 16
Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Kucherawy Expires April 3, 2008 [Page 2]
Internet-Draft Authentication-Results SMTP Extension October 2007
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
[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 SMTP extension which is used to 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 extension is defined using the methods specified in
[SMTP-EXTENSIONS] to enable a server to announce that it is willing
to accept this information from upstream mail servers. Clients
observing this announcement can then elect to send that information
with the message when the latter is relayed.
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 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 SMTP extension defined in this memo is expected to serve several
purposes:
Kucherawy Expires April 3, 2008 [Page 3]
Internet-Draft Authentication-Results SMTP Extension October 2007
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;
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 3, 2008 [Page 4]
Internet-Draft Authentication-Results SMTP Extension October 2007
+-----+ +-----+ +------------+
| 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 3, 2008 [Page 5]
Internet-Draft Authentication-Results SMTP Extension October 2007
2. Framework for the Authentication Results Extension
The framework for the Authentication Results Extension is as follows:
1. The name of the SMTP service extension is "Authentication-
Results";
2. The SMTP buffer length is extended by 256 bytes on servers
offering this service extension;
3. The EHLO keyword value associated with the extension is AUTHRES;
4. No parameter is used with the AUTHRES EHLO keyword;
5. An additional, optional parameter called AUTHRES is added to the
MAIL command;
6. No additional parameters are added to the RCPT command;
7. No additional SMTP verbs are defined by this extension; and
8. The next section specifies how support for the extension affects
the behaviour of a server and client SMTP session.
Kucherawy Expires April 3, 2008 [Page 6]
Internet-Draft Authentication-Results SMTP Extension October 2007
3. The Authentication-Results Service Extension
When a client wishes to relay message authentication information to a
downstream server, it first issues the EHLO command to the SMTP
server. If the SMTP server responds with code 250 to the EHLO
command and the response includes the EHLO keyword AUTHRES, then the
SMTP server has indicated that it can accept message authentication
information from the client.
3.1. Client Implementation
Once the client has confirmed that support exists for this extension
in the server to which it has connected, it may then elect to relay
its collected message authentication results as part of an extended
MAIL command. The format of the extended command is defined below.
More than one such result may be relayed in a single extended MAIL
command.
The authentication results relayed by this method need not have been
established by the agent acting as SMTP client. A client may elect
to forward, by way of this extension, authentication results relayed
to it about a message by previous clients.
3.2. Server Implementation
The SMTP server, upon receiving the EHLO command from the new client,
may decide to advertise its support of this extension by including
the AUTHRES keyword in its reply to the EHLO command.
Although software support for the extension may be present, the
server is not required to advertise such support if, for example, the
client making the connection is not one from which the server wishes
to trust such data.
Upon receipt of authentication results from the upstream MTA, the
receiving MTA may analyze the results and, if it decides the results
are not favourable, may elect to return an SMTP result code other
than the typical 250 success result to the extended MAIL command in
order to reject the message.
The authentication results ultimately received by an MDA may elect to
store that information for ultimate consumption by the end user,
either graphically or by way of filtering. This can be accomplished
using the message header field defined in
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] or by means of a new and as-
yet-unspecified [IMAP] extension.
Kucherawy Expires April 3, 2008 [Page 7]
Internet-Draft Authentication-Results SMTP Extension October 2007
3.3. MAIL Command Extension
The MAIL command is extended by this specification to allow the
relaying of authentication results. As there are several message
authentication schemes in common and growing use, the extension must
permit multiple results to be relayed for a given message.
The extension adds an AUTHRES parameter to the MAIL command. The
formal definition:
authres = 1*( "AUTHRES" "=" methodspec ":" propspec )
; relays a single unit of authentication results
; information
methodspec = method "=" result
; indicates which authentication method was evaluated
propspec = ptype "." property "=" value
; 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 "value", and is one of the methods
; explicitly defined as valid in this document
; or is an extension method as defined below
version = 1*( ALPHA / DIGIT ) 0*( "." 1*( ALPHA / DIGIT ) )
; indicates which version of the method was applied
result = "pass" / "hardfail" / "softfail" / "neutral" /
"temperror" / "permerror"
; an indication of the results of the attempt to
; authenticate the message
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
Kucherawy Expires April 3, 2008 [Page 8]
Internet-Draft Authentication-Results SMTP Extension October 2007
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)
value = token / mailbox
; the value extracted from the message property defined
; by the "ptype.property" construction; if the value
; identifies a mailbox, then it is a "mailbox"
; as defined in section 3.4 of [MAIL];
; "mailbox" allows CFWS so something better should
; either be defined or referenced
The "token" is as defined in section 5.1 of [MIME].
3.4. Extension Fields
Additional authentication method identifiers may be defined in the
future by later revisions or extensions to this specification.
Extension identifiers 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 5 for further details.
Extension identifiers may be defined for the following reasons (for
example):
1. To allow additional information from emergent 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".
Kucherawy Expires April 3, 2008 [Page 9]
Internet-Draft Authentication-Results SMTP Extension October 2007
4. Conformance and Usage Requirements
An agent acting as an SMTP server conforms to this specification if
it offers the AUTHRES extension to upstream MTAs from which it would
trust such data. Servers that advertise AUTHRES in their EHLOs MUST
expect the additional envelope information described in this draft.
A client wishing to use this extension MUST first see AUTHRES as part
of the EHLO response from a server.
Kucherawy Expires April 3, 2008 [Page 10]
Internet-Draft Authentication-Results SMTP Extension October 2007
5. IANA Considerations
IANA is requested to register this new SMTP extension and to create a
new table as described below.
5.1. 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 3.4.
New entries are assigned only for values that have been documented in
a published RFC that has IETF Consensus, 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:
+------------+---------+--------+----------------+--------------------+
| Method | defined | ptype | property | value |
+------------+---------+--------+----------------+--------------------+
| auth | RFC2554 | smtp | auth | authenticated user |
+------------+---------+--------+----------------+--------------------+
| dkim | RFC4871 | header | i | value of |
| | | | | signature "i" tag |
+------------+---------+--------+----------------+--------------------+
| domainkeys | RFC4870 | header | from | value of From |
| | | | | header field |
| | | +----------------+--------------------+
| | | | sender | value of Sender |
| | | | | header field |
+------------+---------+--------+----------------+--------------------+
| senderid | RFC4406 | header | name of header | value of header |
| | | | field used by | field used by PRA |
| | | | PRA | |
| | +--------+----------------+--------------------+
| | | smtp | from | envelope sender |
+------------+---------+--------+----------------+--------------------+
| spf | RFC4408 | smtp | from | envelope sender |
+------------+---------+--------+----------------+--------------------+
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 3, 2008 [Page 11]
Internet-Draft Authentication-Results SMTP Extension October 2007
6. Security Considerations
The following security considerations apply when applying or
processing the Authentication-Results SMTP service extension:
6.1. Trusting SMTP Clients
As described in Section 3.2, an MTA server implementing this
extension need not offer the AUTHRES service to an SMTP client if
it's sure it won't care what that client has to say about the
authenticity of the message. This establishes a "trust boundary"
within which SMTP clients are offered the extension; clients outside
that boundary are not offered the extension.
A client that tries to use the extension when it was not offered may
be deemed a security risk.
Although an obvious location of this boundary would be a published MX
for the recipient's domain, this is not always the case. Thus,
implementors are advised to default to a "trust no-one" posture and
have the trust boundary established explicitly by the user.
Kucherawy Expires April 3, 2008 [Page 12]
Internet-Draft Authentication-Results SMTP Extension October 2007
7. References
7.1. Normative References
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[SMTP-EXTENSIONS]
Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions", RFC 1869,
November 1995.
7.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.
[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-KUCHERAWY-SENDER-AUTH-HEADER]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status",
I-D draft-kucherawy-sender-auth-header-08, October 2007.
[IANA-CONSIDERATIONS]
Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
October 1998.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
[LMTP] Meyers, J., "Local Mail Transport Protocol", RFC 2033,
Kucherawy Expires April 3, 2008 [Page 13]
Internet-Draft Authentication-Results SMTP Extension October 2007
October 1996.
[SENDERID]
Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
[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 3, 2008 [Page 14]
Internet-Draft Authentication-Results SMTP Extension October 2007
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 3, 2008 [Page 15]
Internet-Draft Authentication-Results SMTP Extension October 2007
Appendix B. Examples
This section presents some examples of the use of this protocol
extension to relay message authentication results. In these
examples, "C" indicates data sent by the SMTP client and "S"
indicates data sent by the SMTP server, and other annotations are
enclosed in square brackets.
B.1. Single authentication result
Relaying a single authentication result:
[connection established]
S: 220 inbox.example.com SMTP server ready
C: EHLO border.example.com
S: 250-inbox.example.com Hello root(_at_)foobar(_dot_)example(_dot_)net
S: 250-ENHANCEDSTATUSCODES
S: 250-SIZE
S: 250-DSN
S: 250-AUTHRES
S: 250 HELP
C: MAIL FROM:<me(_at_)example(_dot_)net>
AUTHRES=dkim=pass:header(_dot_)i=(_at_)example(_dot_)net
S: 250 Sender OK
C: RCPT TO:<postmaster(_at_)example(_dot_)com>
S: 250 Recipient OK
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: [message body]
C: .
S: 250 l9NE6WYF026506 Message received
C: QUIT
S: 221 Bye!
[connection closed]
Example 1: Relaying a single authentication result
In this example we see a border SMTP server relaying a message to an
internal SMTP server which will do local delivery for example.com's
users. The SMTP extension is advertised by the server (it trusts
this source as one likely to relay valid authentication data) and
used by the client. In this instance, the server validated the
message's authenticity using [DKIM] and determined that the
verification test passed. Also relayed is information about what
agent was responsible for affixing the signature.
Kucherawy Expires April 3, 2008 [Page 16]
Internet-Draft Authentication-Results SMTP Extension October 2007
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 3, 2008 [Page 17]
Internet-Draft Authentication-Results SMTP Extension October 2007
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 3, 2008 [Page 18]
Internet-Draft Authentication-Results SMTP Extension October 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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 3, 2008 [Page 19]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html