Individual submission M. Kucherawy Internet-Draft Sendmail, Inc. Intended status: Standards Track September 29, 2008 Expires: April 2, 2009 SMTP Service Extension for Indicating Message Authentication Status draft-kucherawy-sender-auth-esmtp-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may not be modified, and derivative works of it may not be created. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 2, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Kucherawy Expires April 2, 2009 [Page 1] Internet-Draft Authentication-Results SMTP Extension September 2008 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. Kucherawy Expires April 2, 2009 [Page 2] Internet-Draft Authentication-Results SMTP Extension September 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 2. Framework for the Authentication Results Extension . . . . . . 7 3. The Authentication-Results Service Extension . . . . . . . . . 8 3.1. Client Implementation . . . . . . . . . . . . . . . . . . 8 3.2. Server Implementation . . . . . . . . . . . . . . . . . . 8 3.3. MAIL Command Extension . . . . . . . . . . . . . . . . . . 9 3.4. Authentication Identifier Fields . . . . . . . . . . . . . 11 3.5. Result Values . . . . . . . . . . . . . . . . . . . . . . 11 3.5.1. DKIM and DomainKeys Results . . . . . . . . . . . . . 12 3.5.2. DKIM ADSP Results . . . . . . . . . . . . . . . . . . 12 3.5.3. SPF and Sender-ID Results . . . . . . . . . . . . . . 13 3.5.4. iprev Results . . . . . . . . . . . . . . . . . . . . 14 3.5.5. SMTP AUTH Results . . . . . . . . . . . . . . . . . . 15 3.5.6. Extension Result Codes . . . . . . . . . . . . . . . . 15 3.6. Authentication Methods . . . . . . . . . . . . . . . . . . 16 3.6.1. Definition Of Initial Methods . . . . . . . . . . . . 16 3.6.2. Extension Methods . . . . . . . . . . . . . . . . . . 16 3.7. Local Policy Enforcement . . . . . . . . . . . . . . . . . 17 4. The 'iprev' Authentication Method . . . . . . . . . . . . . . 18 5. Conformance and Usage Requirements . . . . . . . . . . . . . . 19 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6.1. Email Authentication Method Name Registry . . . . . . . . 20 6.2. Email Authentication Result Name Registry . . . . . . . . 21 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7.1. Trusting SMTP Clients . . . . . . . . . . . . . . . . . . 25 7.2. Misleading Results . . . . . . . . . . . . . . . . . . . . 25 7.3. Reverse IP Query Denial-Of-Service Attacks . . . . . . . . 25 7.4. Mitigation of Backscatter . . . . . . . . . . . . . . . . 25 7.5. Internal MTA Lists . . . . . . . . . . . . . . . . . . . . 26 7.6. Attacks Against Authentication Methods . . . . . . . . . . 26 7.7. Intentionally Malformed Extension Parameters . . . . . . . 26 7.8. Compromised Internal Hosts . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 29 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 30 B.1. Single authentication result . . . . . . . . . . . . . . . 30 Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . . . 33 Kucherawy Expires April 2, 2009 [Page 3] Internet-Draft Authentication-Results SMTP Extension September 2008 1. Introduction Electronic mail, though ubiquitous and highly useful, is also prone to increasing abuse by parties that choose to exploit its lenient design for nefarious purposes such as "spam" and "phishing." Abuse of this leniency has become so widespread as to become an economic problem. Several nascent methods of mitigating this problem such as [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] 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 2, 2009 [Page 4] Internet-Draft Authentication-Results SMTP Extension September 2008 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 2, 2009 [Page 5] Internet-Draft Authentication-Results SMTP Extension September 2008 +-----+ +-----+ +------------+ | MUA |-->| MSA |-->| Border MTA | +-----+ +-----+ +------------+ | | V +----------+ | Internet | +----------+ | | V +-----+ +-----+ +------------------+ +------------+ | MUA |<--| MDA |<==| Intermediate MTA |<==| Border MTA | +-----+ +-----+ +------------------+ +------------+ Generally it is assumed that the work of applying message authentication schemes takes place at a border MTA or a delivery MTA. This specification is written with that assumption in mind. However, there are some sites at which the entire mail infrastructure consists of a single host. In such cases, such terms as "border MTA" and "delivery MTA" may well apply to the same machine or even the very same agent. It is also possible that message authentication could take place on an intermediate MTA. Although this document doesn't specifically include such cases, they are not meant to be excluded from this specification. See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail system architecture. In the figure shown above, the double-lines indicate the portions of the transport of a message where this protocol would be applied. Note also that the Local Mail Transfer Protocol [LMTP] could benefit from a similar extension. Kucherawy Expires April 2, 2009 [Page 6] Internet-Draft Authentication-Results SMTP Extension September 2008 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 2, 2009 [Page 7] Internet-Draft Authentication-Results SMTP Extension September 2008 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] annotation via [ANNOTATE]. Kucherawy Expires April 2, 2009 [Page 8] Internet-Draft Authentication-Results SMTP Extension September 2008 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, using [ABNF]: authres = 1*( "AUTHRES" "=" version ":" authserv-id ":" methodspec ":" propspec ) ; relays a single unit of authentication results ; information version = 1*DIGIT ; indicates which version of this specification is in use; ; this specification is version "1"; the absence of a version ; implies this version of the specification authserv-id = dot-atom-text ; see below for a description of this element; ; "dot-atom-text" is defined in section 3.2.4 of [MAIL] methodspec = method "=" result ; indicates which authentication method was evaluated propspec = ptype "." property "=" pvalue ; an indication of which property of the message ; was evaluated by the authentication scheme being ; applied to yield the reported result method = token [ "/" version ] ; a method indicates which method's result is ; is represented by "result", and is one of the methods ; explicitly defined as valid in this document ; or is an extension method as defined below result = token ; an indication of the results of the attempt to Kucherawy Expires April 2, 2009 [Page 9] Internet-Draft Authentication-Results SMTP Extension September 2008 ; authenticate the message; see below for details ptype = "smtp" / "header" / "body" / "policy" ; indicates whether the property being evaluated was ; a parameter to an [SMTP] command, or was a value taken ; from a message header field, or was some property of ; the message body, or some other property evaluated by ; the receiving MTA property = token ; if "ptype" is "smtp", this indicates which [SMTP] ; command provided the value which was evaluated by the ; authentication scheme being applied; if "ptype" is ; "header", this indicates from which header field the ; value being evaluated was extracted; if "ptype" is ; "body", this indicates the offset into the body at which ; content of interest was detected; if "ptype" is "policy" ; then this indicates the name of the policy which caused ; this header field to be added (see below) pvalue = token / addr-spec ; the value extracted from the message property defined ; by the "ptype.property" construction; if the value ; identifies a mailbox, then it is an "addr-spec" ; as defined in section 3.4 of [MAIL]; The "token" and "value" are as defined in section 5.1 of [MIME]. The "token" used in a "result" above is further constrained by the necessity of being enumerated in Section 3.5 or an amendment to it. See Section 3.4 for a description of the "authserv-id" element. The list of commands eligible for use with the "smtp" ptype can be found in [SMTP] and subsequent amendments. The "propspec" may be omitted if for example the method was unable to extract any properties to do its evaluation yet has a result to report. The "ptype" and "property" values used by each authentication method should be defined in the specification for that method (or its amendments). The "ptype" and "property" are case-insensitive. Kucherawy Expires April 2, 2009 [Page 10] Internet-Draft Authentication-Results SMTP Extension September 2008 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. 3.4. Authentication Identifier Fields 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. 3.5. Result Values Each individual authentication method returns one of a set of specific result values. The subsections below define these results for the authentication methods specifically supported by this memo. New methods not specified in this document intended to be supported by the header field defined in this memo MUST include a similar result table either in its defining memo or in a supplementary one. Kucherawy Expires April 2, 2009 [Page 11] Internet-Draft Authentication-Results SMTP Extension September 2008 3.5.1. DKIM and DomainKeys Results The result values used by [DKIM] and [DOMAINKEYS] are as follows: none: The message was not signed. pass: The message was signed, the signature(s) is (were) acceptable to the verifier, and the signature(s) passed verification tests. fail: The message was signed and the signature(s) is (were) acceptable to the verifier, but it (they) failed the verification test(s). policy: The message was signed but the signature(s) is (were) not acceptable to the verifier. neutral: The message was signed but the signature(s) contained syntax errors or were not otherwise able to be processed. This result SHOULD also be used for other failures not covered elsewhere in this list. temperror: The message could not be verified due to some error which is likely transient in nature, such as a temporary inability to retrieve a public key. A later attempt may produce a final result. permerror: The message could not be verified due to some error which is unrecoverable, such as a required header field being absent. A later attempt is unlikley to produce a final result. A signature is "acceptable to the verifier" if it passes local policy checks (or there are no specific local policy checks). For example, a verifier might require that the signature(s) on the message be added by the domain identified in the From: header field of the message, thus making third-party signatures unacceptable. 3.5.2. DKIM ADSP Results The result values are used by [I-D.DRAFT-IETF-DKIM-SSP] as follows: none: No DKIM author domain signing practises (ADSP) record was published. pass: A DKIM ADSP record was published which indicated the mail should be signed with an author signature, and this message had such a signature that validated. Kucherawy Expires April 2, 2009 [Page 12] Internet-Draft Authentication-Results SMTP Extension September 2008 unknown: No valid author signature was found on the message and either the published ADSP was "unknown", or no policy was published. signed: A valid author signature was found on the message and the published ADSP was "unknown". fail: No valid author signature was found on the message and the published ASDP record indicated an "all" policy. discard: No valid author signature was found on the message and the published ADSP record indicated a "discardable" policy. nxdomain: Evaluating the ADSP for the author's domain indicated that the author's domain does not exist. temperror: A DKIM policy could not be retrieved due to some error which is likely transient in nature, such as a temporary DNS error. A later attempt may produce a final result. permerror: A DKIM policy could not be retrieved due to some error which is likely not transient in nature, such as a permanent DNS error. A later attempt is unlikely to produce a final result. 3.5.3. SPF and Sender-ID Results The result values are used by [SPF] and [SENDERID] as follows: none: No policy records were published by the sender's domain. neutral: The sender's domain has asserted that it cannot or does not want to assert whether or not the sending IP address is authorized to send mail on behalf of the sender's domain. pass: The client is authorized to inject or relay mail on behalf of the sender's domain. policy: The client is authorized to inject or relay mail on behalf of the sender's domain according to the authentication method's algorithm, but local policy dictates that the result is unacceptable. hardfail: This client is explicitly not authorized to inject or relay mail on behalf of the sender's domain. Kucherawy Expires April 2, 2009 [Page 13] Internet-Draft Authentication-Results SMTP Extension September 2008 softfail: The sender's domain believes the client was not authorized to inject or relay mail on its behalf but is unwilling to make a strong assertion to that effect. temperror: The message could not be verified due to some error which is likely transient in nature, such as a temporary inability to retrieve a policy record from DNS. A later attempt may produce a final result. permerror: The message could not be verified due to some error which is unrecoverable, such as a required header field being absent. A later attempt is unlikley to produce a final result. The distinction between and interpretation of "none" and "neutral" under these methods is discussed further in [SPF]. The "policy" result would be returned if, for example, [SPF] returned as "pass" result, but a local policy check matches the sending domain to one found in an explicit list of unacceptable domains (e.g. spammers). 3.5.4. iprev Results The result values are used by the "iprev" method, defined in Section 4, are as follows: pass: The reverse DNS evaluation succeeded, i.e. the "reverse" and "forward" lookup results were in agreement. hardfail: The reverse DNS evaluation failed. In particular, the "reverse" and "forward" lookups each produced results but they were not in agreement. softfail: The reverse DNS evaluation failed. In particular, one or both of the "reverse" and forward lookups returned no data (i.e. a DNS reply code of NODATA). temperror: The reverse DNS evaluation could not be completed due to some error which is likely transient in nature, such as a temporary DNS error. A later attempt may produce a final result. permerror: The reverse DNS evaluation could not be completed due to some error which is unrecoverable (e.g. a DNS reply code of NODATA or NXDOMAIN). A later attempt is unlikely to produce a final result. There is no "none" for this method since any TCP connection delivering e-mail has an IP address associated with it, so some kind Kucherawy Expires April 2, 2009 [Page 14] Internet-Draft Authentication-Results SMTP Extension September 2008 of evaluation will always be possible. 3.5.5. SMTP AUTH Results The result values are used by the [AUTH] method are as follows: none: SMTP authentication was not attempted. pass: The SMTP client had authenicated to the server reporting the result using the protocol described in [AUTH]. fail: The SMTP client had attempted to authenticate to the server using the protocol described in [AUTH] but was not successful, yet continued to send the message about which a result is being reported. temperror: The SMTP client attempted to authenticate using the protocol described in [AUTH] but was not able to complete the attempt due to some error which is likely transient in nature, such as a temporary LDAP lookup error. A later attempt may produce a final result. permerror: The SMTP client attempted to authenticate using the protocol described in [AUTH] but was not able to complete the attempt due to some error which is likely not transient in nature, such as a permanent LDAP lookup error. A later attempt is not likely produce a final result. Note that an agent making use of the data provided by this header field SHOULD consider "fail" and "temperror" to be the synonymous in terms of message authentication, i.e. the client did not authenticate. 3.5.6. Extension Result Codes Additional result codes (extension results) may be defined in the future by later revisions or extensions to this specification. Extension results beginning with "x-" will never be defined as standard fields; such names are reserved for experimental use. Result codes not beginning with "x-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC. See Section 6 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 Kucherawy Expires April 2, 2009 [Page 15] Internet-Draft Authentication-Results SMTP Extension September 2008 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. 3.6. Authentication Methods This section defines the supported authentication methods and discusses the proper means for applying experimental and other extension methods. 3.6.1. Definition Of Initial Methods As they are currently existing specifications for message authentication, it is appropriate to define an authentication method identifier for each of [AUTH], [DKIM], [DOMAINKEYS], [SENDERID] and [SPF]. Therefore, the authentication method identifiers "auth", "dkim", "domainkeys", "senderid" and "spf" respectively are hereby defined for MTAs applying those specifications for e-mail message authentication. Furthermore, method "iprev" is defined in Section 4. Finally, as its publication is imminent, this document also defines "dkim-adsp" per [I-D.DRAFT-IETF-DKIM-SSP]. See Section 6 for details. 3.6.2. Extension Methods Additional authentication method identifiers (extension methods) may be defined in the future by later revisions or extensions to this specification. Extension methods beginning with "x-" will never be defined as standard fields; such names are reserved for experimental use. Method identifiers not beginning with "x-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC. See Section 6 for further details. Extension methods may be defined for the following reasons: 1. To allow additional information from new authentication systems to be communicated to MUAs. The names of such identifiers should reflect the name of the method being defined, but should not be needlessly long. 2. To allow the creation of "sub-identifiers" which indicate different levels of authentication and differentiate between Kucherawy Expires April 2, 2009 [Page 16] Internet-Draft Authentication-Results SMTP Extension September 2008 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. 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. 3.7. Local Policy Enforcement 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-ADSP) for any particular authentication method as justification to reject the message completely, the border MTA SHOULD issue an [SMTP] 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 [DSN] 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 Section 3.5. 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. Kucherawy Expires April 2, 2009 [Page 17] Internet-Draft Authentication-Results SMTP Extension September 2008 4. The 'iprev' Authentication Method This section defines an additional authentication method called "iprev". In general, "iprev" is an attempt to verify that a client appears to be valid based on some DNS queries. Upon receiving a session initiation of some kind from a client, the IP address of the client peer is queried for matching names (i.e. a number-to-name translation, also known as a "reverse lookup" or a "PTR" record query). Once that result is acquired, a lookup of each of the names (i.e. a name-to-number translation, or an "A" record query) thus retrieved is done. The response to this second check should result in at least one mapping back to the client's IP address. More algorithmically: If the client peer's IP address is A, the list of names to which A maps (after a "PTR" query) is the set N, and the union of IP addresses to which each member of N maps (after an "A" query) is L, then this test is successful if A is an element of L. Section 5.5 of [SPF] contains more detail about this process as well as some discussion of possible denial-of-service attacks. [DNS-IP6] discusses the format of this query for the IPv6 case. A successful test using this algorithm constitutes a result of "pass" since the domain in which the client's PTR claims it belongs has confirmed that claim. A failure to match constitutes a "hardfail". There is no case in which "softfail" or "neutral" can be returned. The remaining "temperror" and "permerror" cases refer respectively to temporary and permanent DNS query errors. There is some contention regarding the wisdom and reliability of this test. For example, in some regions it can be difficult for this test ever to pass because the practise of arranging to match the forward and reverse DNS is infrequently observed. Therefore, the actual implementation details of how a verifier performs an "iprev" test are not specified here. The verifier MAY report a successful or failed "iprev" test at its discretion having done some kind of check of the validity of the connection's identity using DNS. It is incumbent upon an agent making use of the reported "iprev" result to understand what exactly that particular verifier is attempting to report. [NOTE TO RFC EDITOR] This is a duplicate of a section in [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] and can be removed and simply referenced if that draft reaches publication first. Kucherawy Expires April 2, 2009 [Page 18] Internet-Draft Authentication-Results SMTP Extension September 2008 5. 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 2, 2009 [Page 19] Internet-Draft Authentication-Results SMTP Extension September 2008 6. IANA Considerations IANA is requested to register this new SMTP extension and to create a new table as described below. 6.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.6.2. New entries are assigned only for values that have been documented in a published RFC that has IETF Review, per [IANA-CONSIDERATIONS]. Each method must register a name, the specification that defines it, one or more "ptype" values appropriate for use with that method, and which "property" value(s) should be reported by that method. The initial set of entries in this registry is as follows: Kucherawy Expires April 2, 2009 [Page 20] Internet-Draft Authentication-Results SMTP Extension September 2008 +------------+----------+--------+----------------+--------------------+ | Method | Defined | ptype | property | value | +------------+----------+--------+----------------+--------------------+ | auth | RFC4954 | smtp | auth | AUTH parameter of | | | | | | the SMTP MAIL | | | | | | command | +------------+----------+--------+----------------+--------------------+ | dkim | RFC4871 | header | d | value of | | | | | | signature "d" tag | | | | +----------------+--------------------+ | | | | i | value of | | | | | | signature "i" tag | +------------+----------+--------+----------------+--------------------+ | dkim-adsp | [TBD] | header | from | value of From | | | | | | header field | | | | | | w/comments removed | +------------+----------+--------+----------------+--------------------+ | domainkeys | RFC4870 | header | from | value of From | | | | | | header field | | | | | | w/comments removed | | | | +----------------+--------------------+ | | | | sender | value of Sender | | | | | | header field | | | | | | w/comments removed | +------------+----------+--------+----------------+--------------------+ | iprev | this | policy | iprev | client IP address | | | document | | | | +------------+----------+--------+----------------+--------------------+ | senderid | RFC4406 | header | name of header | value of header | | | | | field used by | field used by PRA | | | | | PRA | w/comments removed | +------------+----------+--------+----------------+--------------------+ | spf | RFC4408 | smtp | mailfrom | envelope sender | | | +--------+----------------+--------------------+ | | | smtp | helo | HELO/EHLO value | +------------+----------+--------+----------------+--------------------+ [NOTE TO RFC EDITOR] This is a duplicate of the registry created by [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] and can be removed and simply referenced if that draft reaches publication first. 6.2. Email Authentication Result Name Registry Names of message authentication result codes supported by this specification must be registered with IANA, with the exception of experimental codes as described in Section 3.5.6. New entries are assigned only for result codes that have been Kucherawy Expires April 2, 2009 [Page 21] Internet-Draft Authentication-Results SMTP Extension September 2008 documented in a published RFC that has IETF Review, per [IANA-CONSIDERATIONS]. Each code must register a name, the document which establishes the registration, the authentication method(s) which uses it, and either a definition of the semantics of its use or a reference to the place where those semantics are defined. The initial set of entries in this registry is as follows: +-----------+----------+----------------+------------------------------+ | Code | Defined | Auth Method(s) | Meaning | +-----------+----------+----------------+------------------------------+ | none | this | dkim | section 2.4.1 | | | document | domainkeys | | | | +----------------+------------------------------+ | | | dkim-adsp | section 2.4.2 | | | +----------------+------------------------------+ | | | spf | section 2.4.3 | | | | sender-id | | | | +----------------+------------------------------+ | | | auth | section 2.4.5 | +-----------+----------+----------------+------------------------------+ | pass | this | dkim | section 2.4.1 | | | document | domainkeys | | | | +----------------+------------------------------+ | | | dkim-adsp | section 2.4.2 | | | +----------------+------------------------------+ | | | spf | section 2.4.3 | | | | sender-id | | | | +----------------+------------------------------+ | | | iprev | section 2.4.4 | | | +----------------+------------------------------+ | | | auth | section 2.4.5 | +-----------+----------+----------------+------------------------------+ | fail | this | dkim | section 2.4.1 | | | document | domainkeys | | | | +----------------+------------------------------+ | | | dkim-adsp | section 2.4.2 | | | +----------------+------------------------------+ | | | auth | section 2.4.5 | +-----------+----------+----------------+------------------------------+ | policy | this | dkim | section 2.4.1 | | | document | domainkeys | | +-----------+----------+----------------+------------------------------+ | neutral | this | dkim | section 2.4.1 | | | document | domainkeys | | | | +----------------+------------------------------+ | | | spf | section 2.4.3 | | | | sender-id | | Kucherawy Expires April 2, 2009 [Page 22] Internet-Draft Authentication-Results SMTP Extension September 2008 +-----------+----------+----------------+------------------------------+ | temperror | this | dkim | section 2.4.1 | | | document | domainkeys | | | | +----------------+------------------------------+ | | | dkim-adsp | section 2.4.2 | | | +----------------+------------------------------+ | | | spf | section 2.4.3 | | | | sender-id | | | | +----------------+------------------------------+ | | | iprev | section 2.4.4 | | | +----------------+------------------------------+ | | | auth | section 2.4.5 | +-----------+----------+----------------+------------------------------+ | permerror | this | dkim | section 2.4.1 | | | document | domainkeys | | | | +----------------+------------------------------+ | | | dkim-adsp | section 2.4.2 | | | +----------------+------------------------------+ | | | spf | section 2.4.3 | | | | sender-id | | | | +----------------+------------------------------+ | | | iprev | section 2.4.4 | | | +----------------+------------------------------+ | | | auth | section 2.4.5 | +-----------+----------+----------------+------------------------------+ | nxdomain | this | dkim-adsp | section 2.4.2 | | | document | | | +-----------+----------+----------------+------------------------------+ | signed | this | dkim-adsp | section 2.4.2 | | | document | | | +-----------+----------+----------------+------------------------------+ | unknown | this | dkim-adsp | section 2.4.2 | | | document | | | +-----------+----------+----------------+------------------------------+ | discard | this | dkim-adsp | section 2.4.2 | | | document | | | +-----------+----------+----------------+------------------------------+ | hardfail | this | spf | section 2.4.3 | | | document | sender-id | | | | +----------------+------------------------------+ | | | iprev | section 2.4.4 | +-----------+----------+----------------+------------------------------+ | softfail | this | spf | section 2.4.3 | | | document | sender-id | | | | +----------------+------------------------------+ | | | iprev | section 2.4.4 | +-----------+----------+----------------+------------------------------+ Kucherawy Expires April 2, 2009 [Page 23] Internet-Draft Authentication-Results SMTP Extension September 2008 [NOTE TO RFC EDITOR] This is a duplicate of the registry created by [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] and can be removed and simply referenced if that draft reaches publication first. Kucherawy Expires April 2, 2009 [Page 24] Internet-Draft Authentication-Results SMTP Extension September 2008 7. Security Considerations The following security considerations apply when applying or processing the Authentication-Results SMTP service extension: 7.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. 7.2. Misleading Results 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 [DKIM] by the originator of the spam, which might be a spammer or a compromised system). 7.3. Reverse IP Query Denial-Of-Service Attacks Section 5.5 of [SPF] 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. 7.4. Mitigation of Backscatter Failing to follow the instructions of Section 3.7 can result in a denial-of-service attack caused by the generation of [DSN] messages (or equivalent) to addresses which did not send the messages being Kucherawy Expires April 2, 2009 [Page 25] Internet-Draft Authentication-Results SMTP Extension September 2008 rejected. 7.5. Internal MTA Lists Section 3.2 mentions that the participating server need not offer this extension to untrusted clients. 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. 7.6. Attacks Against Authentication Methods If an attack becomes known against an authentication method, clearly then the agent verifying that method can be fooled into thinking an inauthentic message is authentic, and thus the value of this 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. 7.7. Intentionally Malformed Extension Parameters It is possible for an attacker to add AUTHRES parameter which is extraordinarily large or otherwise malformed in an attempt to discover or exploit weaknesses in parsing code. Implementors must thoroughly verify all such header fields received from MTAs and be robust against intentionally as well as unintentionally malformed data. 7.8. Compromised Internal Hosts An internal MUA or MTA which has been compromised could generate mail with forged data, eventually generating an AUTHRES parameter which endorses it. Although it is clearly a larger concern to have compromised internal machines than it is to prove the value of this extension, this risk can be mitigated by arranging that internal MTAs not relay this data field if it claims to have been added by a trusted border MTA (as described above) yet the [SMTP] connection is not coming from an internal machine known to be running an authorized MTA. However, in such a configuration, legitimate MTAs will have to add this data when legitimate internal-only messages are generated. Kucherawy Expires April 2, 2009 [Page 26] Internet-Draft Authentication-Results SMTP Extension September 2008 8. References 8.1. Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. [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. 8.2. Informative References [ANNOTATE] Daboo, C. and R. Gellens, "IMAP ANNOTATE Extension", RFC 5257, June 2008. [AUTH] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007. [DKIM] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [DNS-IP6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003. [DOMAINKEYS] Delany, M., "Domain-based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007. [DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003. [I-D.DRAFT-CROCKER-EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", I-D draft-crocker-email-arch, May 2007. [I-D.DRAFT-IETF-DKIM-SSP] Allman, E., Delany, M., and J. Fenton, "DKIM Author Signing Practices", I-D draft-ietf-dkim-ssp-06, September 2008. Kucherawy Expires April 2, 2009 [Page 27] Internet-Draft Authentication-Results SMTP Extension September 2008 [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", I-D draft-kucherawy-sender-auth-header-16, September 2008. [IANA-CONSIDERATIONS] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, October 1998. [IMAP] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 3501, March 2003. [LMTP] Meyers, J., "Local Mail Transport Protocol", RFC 2033, October 1996. [SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006. [SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. Kucherawy Expires April 2, 2009 [Page 28] Internet-Draft Authentication-Results SMTP Extension September 2008 Appendix A. Acknowledgements The author wishes to acknowledge the following for their review and constructive criticism of this proposal: (add names here) Kucherawy Expires April 2, 2009 [Page 29] Internet-Draft Authentication-Results SMTP Extension September 2008 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@foobar.example.net S: 250-ENHANCEDSTATUSCODES S: 250-SIZE S: 250-DSN S: 250-AUTHRES S: 250 HELP C: MAIL FROM: AUTHRES=dkim=pass:header.i=@example.net S: 250 Sender OK C: RCPT TO: 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 2, 2009 [Page 30] Internet-Draft Authentication-Results SMTP Extension September 2008 Appendix C. Public Discussion [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. Kucherawy Expires April 2, 2009 [Page 31] Internet-Draft Authentication-Results SMTP Extension September 2008 Author's Address Murray S. Kucherawy Sendmail, Inc. 6475 Christie Ave., Suite 350 Emeryville, CA 94608 US Phone: +1 510 594 5400 Email: msk+ietf@sendmail.com Kucherawy Expires April 2, 2009 [Page 32] Internet-Draft Authentication-Results SMTP Extension September 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kucherawy Expires April 2, 2009 [Page 33]