Network Working Group M. Pelletier Internet-Draft ETS Expires: December 27, 2003 June 28, 2003 SMTP Service Extension for Trust of Addressing Information draft-pelletier-smtp-trust-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 December 27, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document defines an SMTP service extension [ESMTP] whereby an SMTP client may establish a trust relationship with the server attesting its confidence in the validity of the originator of a message. This confidence, or its absence, can then be used to mitigate the cost of undesirable messages (primarily spam) without disrupting operations between, or with, SMTP implementations not supporting the extension. Pelletier Expires December 27, 2003 [Page 1] Internet-Draft SMTP Trust of Addressing June 2003 1. Introduction The problem of undesirable email messages, spam in particular, is already well-known and understood. Several measures have been discussed at length in [5] to reduce the impact of spam, with some success. However, many mail administrators faced with the increasing problem of large volumes of undesirable messages have resorted to fairly broad measures, such as refusing mail delivery completely for large blocks of addresses or from dynamically allocated IP addresses in order to curtail the problem. In addition of being politically charged, those measures pose a difficult technical problem because they tend to generate a great deal of false positives. I.e. they may reject large number of legitimate messages because they come from certain addresses which have, in the past, generated undesirable messages. It would seem the greatest problem in separating legitimate messages from spam is the inherent difficulty in attributing the messages to a specific originator. This memo describes an extension to SMTP that allows increased confidence and accuracy in determining who the originator of a message is, thus facilitating that separation. The primary usefulness of this extension is to supplement other countermeasures in place against undesirable messages. For instance, a server that has been configured to, by default, reject mail coming from certain ranges of addresses may allow messages when they come from a trusted server. Additionally, the increased confidence in the identity of the originator of a message makes filtering more reliable by reducing the impact of forged headers. Thus, this extension may reduce the rate of false positives when detecting undesirable messages, increasing the usefulness of the filters it supplements. Also, it may be reasonable for a server implementing this extension to severely restrict the resources devoted to storing and forwarding messages coming from untrusted sources, so that while best-effort can still be made to deliver messages from uncertain origins, they can be prevented from overloading the server or denying service to legitimate messages coming from trusted sources. Pelletier Expires December 27, 2003 [Page 2] Internet-Draft SMTP Trust of Addressing June 2003 Widespread adoption of this extension would increase its general usefulness, especially for attributing misbehavior to specific originators. While no mechanism can possibly eliminate all cases of undesirable messages, the ability to find with greater confidence the actual originator of such messages allow for easier and more reliable enforcement of policies against them. Pelletier Expires December 27, 2003 [Page 3] Internet-Draft SMTP Trust of Addressing June 2003 2. Conventions Used in this Document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as defined in [2] Pelletier Expires December 27, 2003 [Page 4] Internet-Draft SMTP Trust of Addressing June 2003 3. The Trust of Addressing Information Service Extension 1. the name of the SMTP service extension is "Trust of Addressing Information" 2. the EHLO keyword value associated with this extension is "TOAI" 3. the TOAI EHLO keyword contains as a parameter a challenge-string used during negotiation. To prevent spoofing of the source IP address of the client in order to fraudulently establish a trust relationship, the challenge-string should be generated randomly for each session in a manner that makes it impossible to guess without having actually received it. 4. a new SMTP verb "TOAI" is defined 5. a new message header "Origin:" is defined 6. this extension is not appropriate for the submission protocol [4] 3.1 Interaction with the Authentication Service Extension While SMTP Authentication [6] is orthogonal with SMTP Trust of Addressing, it can be used collaboratively during the process of establishing the trust relationship. Specifically, if the client has been authenticated, the server MAY accept the TOAI command regardless of the actual IP address of the client or the domain of authority it claims. Indeed, the server MAY require authentication before it accepts to establish a trust relationship with any or all clients. Pelletier Expires December 27, 2003 [Page 5] Internet-Draft SMTP Trust of Addressing June 2003 4. The TOAI command TOAI domain-spec challenge-string Arguments: a domain-spec identifying the scope of authority claimed by the client. a challenge-string response identical to the challenge-string provided by the server with the TOAI EHLO keyword. Restrictions: No TOAI commands may be issued in a session after a TOAI command has successfully completed, or after a mail transaction has begun or has been completed. A server MUST reject a TOAI command with a 503 reply in those cases. Discussion: The TOAI command indicates that the client claims authority over a domain, and wishes to establish a trust relationship with the server about the reliability of the origin of messages it wants to transmit. The server MUST reject the TOAI command with a 535 reply if the challenge-string argument is not equal to the challenge-string provided with the TOAI EHLO keyword. Unless the client has been previously authenticated as in Section 3.1, the server MUST verify the domain of authority claimed by the client by matching the source IP address of the client with one of the address returned by looking up the MX records corresponding to the domain-spec argument. If the lookup fails with no positive or negative result, the server MUST reject the TOAI command with a 433 reply. If the lookup returns no result, or the results do not match the source IP address of the client, the server MUST reject the TOAI command with a 535 reply. The server MAY reject the TOAI command with a 534 reply if it the client is not authenticated and the server has been configured to reject trust relationship with this or all clients without authentication. The server MAY reject the TOAI command for any domain of authority it has been configured to refuse. The server MAY be configured to reject the command with a 534 reply to avoid disclosing the explicit refusal, but otherwise MUST reject the command with a 535 reply. The server SHOULD accept a request for establishing a trust Pelletier Expires December 27, 2003 [Page 6] Internet-Draft SMTP Trust of Addressing June 2003 relationship from a client whose domain of authority is not previously known, but has been verified through a DNS lookup. Examples: S: 220 smtp.example.org ESMTP server ready C: EHLO smtp.trusted.org S: 250-smtp.example.org S: 250 TOAI challenge1234567 C: TOAI random.org challenge1234567 S: 535 You are not authoritative for random.org. C: TOAI trusted.org challenge1234567 S: 230 We trust you, trusted.org. Commentary: By specifying its domain-spec, the client is basically stating "I am an official mail exchange for this (sub)domain". The lookup performed by the server for the MX record of that domain simply verifies that claim. In the case where the address of the MTA for outgoing mail for a domain is not also a valid MX for incoming mail, as some organizations might configure their mail system, validation can still be provided for with an MX for a specific sub-domain. For instance, the outgoing MTA of 'foo.net' may claim authority over 'outgoing.foo.net' and provide MX records that point back to those clients without disrupting the flow of mail to the incoming MTA. It might be worthwhile to look into using a DNS record type distinct from MX for verification of outgoing authority; or indeed using a service other than DNS altogether rather than overload it with additional semantics. The issue of whether a client's "Origin:" headers can be trusted or not is distinct, and not addressed by this memo. Presumably, a MTA administrator will maintain a list of untrustworthy clients or refer to such a list maintained by other administrators. The obvious solution may be to combine verification of authority over a domain with relative trust in some globally accessible database other than DNS, but this opens up questions about who has authority over, and responsibility of, that database as well as defining a protocol to make such queries. This memo does not look into those issues. Pelletier Expires December 27, 2003 [Page 7] Internet-Draft SMTP Trust of Addressing June 2003 5. The "Origin:" header This extension defines a new header that may be inserted into, or removed from, received messages by the server. The format of the header is detailed in Section 7. Provided that the header is part of a message that has been received from a trusted client or has been constructed by the server itself, it has unambiguous semantics: 1. the domain-spec part is the domain who has created the header. I.e.: looking up the MX DNS record for the domain-spec will return a list of addresses of which one corresponds to the server that created the header 2. the identity part is opaque, and needs have meaning only to the server that created it 3. two messages whose "Origin:" header have identical domain-spec and identity parts are considered to have the same origin 4. conversely, two message who have differing domain-spec or identity parts MUST be presumed to have different origins Because a MTA that does not support this extension should pass any "Origin:" header intact, it is critical that the directives in Section 5.1 are followed so that the existence of an "Origin:" header implies an unbroken chain of trust between the originator of the message and the server. 5.1 Behavior with untrusted client In all cases, the server MUST delete any "Origin:" header present in the message as received. If the server can positively identify the client, then the server SHOULD insert an "Origin:" header in the message. In that case, the domain-spec part of the header MUST correspond to the domain-spec that server uses when establishing trust with other servers. While the identity part of the "Origin:" header is defined as opaque and having meaning only to the server that created it, a server SHOULD attempt to insure that a specific user, or identifiable client be given the same identity over time and that no two distinct users or clients be given the same identity. For instance, the server of an Internet Service Provider might statically assign a specific identity to the IP addresses associated Pelletier Expires December 27, 2003 [Page 8] Internet-Draft SMTP Trust of Addressing June 2003 with a dedicated connection, and match dynamically assigned addresses with login information of the user it was assigned to in order to generate user-specific identity. This may prove prohibitive for very large installations where login information is unaccessible or expensive to retrieve by the server, in which case it is quite permissible for the server to generate an identity based on the IP address of the client alone. While the usefulness of such an identity is somewhat diminished for filtering purposes, they remain useful at least for post-incident identification of the originator. The server MUST NOT generate an "Origin:" header at all unless the client has been identified positively either through authentication or by the IP address of the client. An identity based on IP addresses is considered positive if and only if it falls within the ranges of addresses over which the server claims authority. 5.2 Behavior with trusted client If the client has successfully established a trust relationship with the server, then the server MUST NOT delete or alter any "Origin:" header present in the message, and MUST NOT add one of its own. Pelletier Expires December 27, 2003 [Page 9] Internet-Draft SMTP Trust of Addressing June 2003 6. Disposal of messages The "Origin:" header, when present, can be used to classify messages as either desirable or undesirable according to their originators. Since the confidence in the precision and accuracy of the originator is considerably higher, fine grained decisions can be made. A server MAY classify a message as desirable or undesirable according to factors other than just the originator. For instance a server implementation might base the classification on a per-user list for local deliveries, and use a different scheme for messages that are to be relayed. A server also MAY change the classification of an originator to undesirable under automated processes, such as traffic or contents analysis, but SHOULD NOT do so permanently without human intervention. The server SHOULD attempt to send a message to the originator whose classification has been automatically changed to undesirable in such cases, so that in case of false positives the originator is notified and can take corrective measures. A server SHOULD NOT change the classification of all originators sharing an identical domain-spec part without human intervention. When a message has been accepted and does not contain an "Origin:" header, then the originator of the message is deemed uncertain. The server MAY apply alternate classification techniques to the message (such as, for instance, content filters or so-called "black lists" of senders) to further qualify the originator as desirable or undesirable. A server SHOULD make best effort attempt to deliver messages whose originator is uncertain, but MAY limit resources dedicated to those messages. For instance, limiting the rate at which such messages can be delivered or forwarded, or placing them in a lower priority queue. A server MAY refuse to deliver or forward messages from undesirable originators. To prevent bounce messages from consuming network resources, the server MAY omit sending an error message back to the undesirable originator. In all cases, if the message is delivered or forwarded at all, then the server MUST include the "Origin:" header without modification. Pelletier Expires December 27, 2003 [Page 10] Internet-Draft SMTP Trust of Addressing June 2003 7. Formal Grammar The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [3]. All alphabetic characters are case-insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. UPALPHA = %x41-5A LOALPHA = %x61-7A ALPHA = UPALPHA / LOALPHA DIGIT = %x30-39 PRINTABLE = %x21-7E domain-char = DIGIT / ALPHA / %x2D sub-domain = 1#(domain-char) domain-spec = sub-domain *("." sub-domain) identity-char = DIGIT / ALPHA identity = 1#(identity-char) challenge-string = 1#(PRINTABLE) toai-command = "TOAI" SPACE domain-spec SPACE challenge-string CRLF Note that the complete form of the "Origin:" header is defined according to the interpretation rules for fields, specifically of an extension-field, found in [1]. origin-field = "Origin" ":" identity "@" domain-spec Pelletier Expires December 27, 2003 [Page 11] Internet-Draft SMTP Trust of Addressing June 2003 8. Error Codes 433 Temporary verification failure This response to the TOAI command indicates that the attempt to establish trust failed due to a temporary server failure, and may be retried. 534 Authentication mechanism is too weak This response to the TOAI command indicates that trust cannot be established under the current authentication. Either the claimed authority domain cannot be verified or the server has been configured to require authentication for this or all authority domain. 535 Authority domain rejected This response to the TOAI command indicates that the server does not recognize the client's claim of authority and refuses to establish a trust relationship. Pelletier Expires December 27, 2003 [Page 12] Internet-Draft SMTP Trust of Addressing June 2003 9. Security Considerations Security issues are discussed throughout this memo. It is important to note that the concept of trust that this extension provides is, by nature, limited. Essentially, the extension provides an SMTP client with the opportunity to claim that it is authoritative over a certain domain, and that messages it will transmit that contain an "Origin:" header are either generated by it, or received from systems it, in turn, believes were authoritative. All it can achieve is increase the confidence in the accuracy of the identification of the originator of a message, but cannot perform authentication over that identity. In order to be truly useful, this system should be supplemented with a list of systems that have proven untrustworthy despite their claim. This list can be local to the server, maintained by its administrator or might be a central directory of untrustworthy systems (possibly one of many). It is also important to note that the default verification of authority through the DNS, combined with the challenge to prevent IP spoofing makes it hard, but not impossible, to falsely claim authority. Therefore, the information provided by using this extension can be used to prioritize allocation of resources to mail distribution, or to supplement other methods of detecting and dealing with undesirable messages, but must not be used as an authentication or authorization mechanism. Pelletier Expires December 27, 2003 [Page 13] Internet-Draft SMTP Trust of Addressing June 2003 References [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, STD 11, August 1982. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [4] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [5] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", RFC 2505, BCP 30, Febuary 1999. [6] Meyers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. Author's Address Marc-Andre Pelletier Ecole de Technologie Superieure 40 de l'Anse Bleue Montreal, Quebec H7N 4B1 CA Phone: +1 450 668 2677 Fax: +1 450 668 2677 EMail: marc@ctrl-alt-del.ca Pelletier Expires December 27, 2003 [Page 14] Internet-Draft SMTP Trust of Addressing June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Pelletier Expires December 27, 2003 [Page 15] Internet-Draft SMTP Trust of Addressing June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Pelletier Expires December 27, 2003 [Page 16]