Network Working Group M. Pelletier Internet-Draft ETS Expires: November 30, 2003 June 2003 SMTP Service Extension for Trust of Reliable Origin draft-pelletier-smtp-trust-01 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 November 30, 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 November 30, 2003 [Page 1] Internet-Draft SMTP Trust of Reliable Origin 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. 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. Note, however, that limiting of the volume or rate of messages coming from uncertain origins should not be overly restrictive until such time as most messages do come from trusted origins. Pelletier Expires November 30, 2003 [Page 2] Internet-Draft SMTP Trust of Reliable Origin June 2003 It is also important to note that it is not appropriate to reject messages outright based on the lack of a certain origin. The appropriate way to limit the rate at which such messages are accepted is to return temporary failures, so that the sender may retry later. The provision for automated marking of originators as undesirable has several uses: one could block origins that generate too many messages too quickly (more than some configurable ratio over time, say). Origins that generate too many erroneous addresses could also be blocked automatically since typically, mass mailing lists contain a great deal of outdated or inexistent addresses and a legitimate sender is unlikely to send very many messages to mailboxes that never existed. It might also be conceivable to willingly disseminate poisoned addresses, so that an origin which attempts to send a message to that address can be immediately blocked. 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 November 30, 2003 [Page 3] Internet-Draft SMTP Trust of Reliable Origin 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 [1] Pelletier Expires November 30, 2003 [Page 4] Internet-Draft SMTP Trust of Reliable Origin June 2003 3. The Trust of Reliable Origin Service Extension 1. the name of the SMTP service extension is "Trust of Reliable Origin" 2. the EHLO keyword value associated with this extension is "TORO" 3. the TORO 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 "TORO" is defined 5. an new parameter using the keyword "ORIGIN" is added to the MAIL FROM command, and extends the maximum line length of the MAIL FROM command by 350 characters. 6. this extension is not appropriate for the submission protocol [3] That is, it is not appropriate for a client using the submission protocol to request establishment of trust, and the TORO EHLO keyword must not be presented to such a client. However, a server implementing this extension when forwarding a message received with the submission protocol MUST apply the procedure of Section 6 to those messages. 3.1 Interaction with the Authentication Service Extension While SMTP Authentication [4] is orthogonal with SMTP Trust of Reliable Origin, 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 TORO 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 November 30, 2003 [Page 5] Internet-Draft SMTP Trust of Reliable Origin June 2003 4. The TORO command TORO 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 TORO EHLO keyword. Restrictions: No TORO commands may be issued in a session after a TORO command has successfully completed, or after a mail transaction has begun or has been completed. A server MUST reject a TORO command with a 503 reply in those cases. Discussion: The TORO 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 TORO command with a 535 reply if the challenge-string argument is not equal to the challenge-string provided with the TORO EHLO keyword. Unless the client has been previously authenticated by another method, (such 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 through the DNS for an MX record corresponding to the domain-spec argument. If the lookup fails with no positive or negative result, the server MUST reject the TORO 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 TORO command with a 535 reply. The server MUST NOT accept the TORO command based on looking up A or AAAA records through the DNS. The server MAY reject the TORO 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 TORO 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 Pelletier Expires November 30, 2003 [Page 6] Internet-Draft SMTP Trust of Reliable Origin June 2003 explicit refusal, but otherwise MUST reject the command with a 535 reply. The server SHOULD accept a request for establishing a trust 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 TORO challenge1234567 C: TORO random.org challenge1234567 S: 535 You are not authoritative for random.org. C: TORO 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. There is, for instance, a work-in-progress [6] where such a DNS RR is discussed at length; its applicability to this extension is clear. A server MAY use information gathered from alternate channels to accept a TORO command, but MUST verify through the MX records if no other method yielded positive verification. The issue of whether a client's ORIGIN information 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. Pelletier Expires November 30, 2003 [Page 7] 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 November 30, 2003 [Page 8] Internet-Draft SMTP Trust of Reliable Origin June 2003 5. The ORIGIN parameter to the MAIL FROM command ORIGIN=identity@domain-spec Arguments: An identity and domain-spec pair corresponding to the believed origin of the message. Restrictions: The optional ORIGIN parameter to the MAIL FROM command may only be issued in a session that has successfully negotiated trust with the TORO command. A server MUST reject a MAIL FROM command including the ORIGIN parameter with a 503 reply otherwise. Discussion: The ORIGIN parameter to the MAIL FROM command allows early classification (and possible rejection) of the individual messages. It adds to the envelope information, and is retained along with the message. The server MAY refuse the message immediately at the MAIL FROM command based on the value of the ORIGIN parameter if it is specified. The server MUST NOT refuse the message outright because no ORIGIN parameter is specified, but MAY reject it temporarily with a 452 reply to reduce the number or rate at which such messages may be accepted. The server MAY reject a message permanently based on other criterion, such as other parts of the envelope, or contents analysis. The server MAY then block any message having the same origin, but SHOULD NOT do so permanently without human intervention. The client MUST supply an ORIGIN parameter if it has generated one at the original submission. See Section 6 for details on how and when to generate an origin. The server SHOULD add the value of a received or generated origin, as well as the domain of authority claimed during TORO negotiation as comments to trace headers. If the client has accepted a message with an ORIGIN parameter specified, then the client MUST supply an ORIGIN parameter whose value is identical to that received when relaying the message. The client MUST NOT supply an ORIGIN parameter if the message Pelletier Expires November 30, 2003 [Page 9] Internet-Draft SMTP Trust of Reliable Origin June 2003 originates outside the domain over which it claims authority and has not been received with an ORIGIN parameter. The format of the ORIGIN parameter is defined in Section 7. Provided that it has been received from a trusted client or has been generated 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 Examples: C: MAIL FROM: ORIGIN=opaquetoken@example.com S: 536 We decline to accept that message C: MAIL FROM: S: 452 Quota exceeded for this class of mail; try again later C: MAIL FROM: ORIGIN=othertoken@example.com S: 250 2.1.0 sender OK Pelletier Expires November 30, 2003 [Page 10] Internet-Draft SMTP Trust of Reliable Origin June 2003 6. Message submission Conceptually, an origin is part of the envelope of a message. It is generated when a message is originally submitted to the mail system and remains attached to it until it is relayed or delivered. If the server can positively identify the client that initially submitted the message, then the server MUST attach an origin to the message. The domain-spec part of the origin MUST correspond to the domain-spec that server uses when establishing trust with other servers. If the message is then relayed, then the server SHOULD attempt to establish TORO with its peer. If TORO has been established, then the server MUST transmit that origin with an ORIGIN parameter to the MAIL FROM command. While the identity part of the origin 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 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 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 and for which it would normally allow relaying. Pelletier Expires November 30, 2003 [Page 11] Internet-Draft SMTP Trust of Reliable Origin June 2003 7. Formal Grammar The following syntax specification uses the augmented Backus-Naur Form (BNF) notation as specified in [2]. 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 / %x21-%2f identity = 1#(identity-char) challenge-string = 1#(PRINTABLE) toro-command = "TORO" SPACE domain-spec SPACE challenge-string CRLF origin-param = "ORIGIN=" identity "@" domain-spec Pelletier Expires November 30, 2003 [Page 12] Internet-Draft SMTP Trust of Reliable Origin June 2003 8. Error Codes 433 Temporary verification failure This response to the TORO 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 TORO 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 TORO command indicates that the server does not recognize the client's claim of authority and refuses to establish a trust relationship. 536 Messages from that origin refused This response to the MAIL FROM command indicates that the server has been configured to refuse messages from the specified origin. Pelletier Expires November 30, 2003 [Page 13] Internet-Draft SMTP Trust of Reliable Origin 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 specify an origin 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. An open proxy running on an outgoing mail server might also be used to establish an SMTP connection, and claim authority. This is obviously a very dangerous practice in general; presumably servers who are so configured and abused would quickly find themselves on lists of untrustworthy servers and become unable to establish trust. 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 November 30, 2003 [Page 14] Internet-Draft SMTP Trust of Reliable Origin June 2003 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [4] Meyers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. Pelletier Expires November 30, 2003 [Page 15] Internet-Draft SMTP Trust of Reliable Origin June 2003 Informative References [5] Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", RFC 2505, BCP 30, Febuary 1999. [6] Danish, H., "A DNS RR for simple SMTP sender authentication", June 2003, . 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 November 30, 2003 [Page 16] Internet-Draft SMTP Trust of Reliable Origin June 2003 Appendix A. Revision History Aug 12, 2003 (01) o Moved the origin information from the message headers to the envelope. June 30, 2003 (01) o Changed the name of the extension to the more accurate "Trust of Reliable Origin" o Added discussion of possible uses of automatic blocking (Section 1). o Added requirement that the ORIGIN parameter to MAIL FROM be used only in a trusted session. June 29, 2003 (01) o Clarified methods for checking authority, added a reference to possible use of RMX RRs. o Added a caveat about open proxies being used to usurp authority. Pelletier Expires November 30, 2003 [Page 17] Internet-Draft SMTP Trust of Reliable Origin 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 November 30, 2003 [Page 18] Internet-Draft SMTP Trust of Reliable Origin 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 November 30, 2003 [Page 19]