Network Working Group J. Klensin Internet-Draft January 21, 2004 Expires: July 21, 2004 A Cleaner SMTP Envelope for Internet Mail draft-klensin-email-envelope-00.txt 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 July 21, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract During the last few years, a number of proposals for extensions or improvements to email have run into trouble with a side-effect of mail relaying. In the current Internet Mail model, every SMTP server is required to break strict layering by inserting one or more additional "trace" headers into the message headers which are actually part of the SMTP payload. Since the headers are altered in transit, header-signing is not an available option, various anti-spam and internationalization strategies are infeasible or much more complex, and so on. This document proposes to change the Internet mail model to place the in-transit trace information in the envelope, removing the requirement that relaying systems modify the message payload. Klensin Expires July 21, 2004 [Page 1] Internet-Draft A Cleaner SMTP Envelope for Internet Mail January 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Proposal Overview . . . . . . . . . . . . . . . . . . . . . . . 3 3. The SMTP Extended Envelope Service Extension . . . . . . . . . . 4 4. Enhanced Status Codes . . . . . . . . . . . . . . . . . . . . . 5 5. Protocol open questions . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations and Associated Work . . . . . . . . . . . . 6 7. Security considerations . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 Normative References . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . 8 Klensin Expires July 21, 2004 [Page 2] Internet-Draft A Cleaner SMTP Envelope for Internet Mail January 2004 1. Introduction During the last few years, a number of proposals for extensions or improvements to email have run into trouble with a side-effect of mail relaying. In the current Internet Mail model, every SMTP server is required to break strict layering by inserting one or more additional "trace" headers into the message headers which are actually part of the SMTP payload. As specified in RFC 2821 [RFC2821], every SMTP receiver must prepend one or more "Received" fields, which specify its receipt of the message and actions on it, to the headers, and the delivery SMTP Server must also prepend a "Return-path" field. All of these go into what is, as far as SMTP is otherwise concerned, the message body, i.e., the text that follows "DATA" or the equivalent. Since the headers are altered in transit, header-signing has not been a practical option, various anti-spam and internationalization strategies have been rendered infeasible or much more complex, and so on. A BOF at IETF 58 (Minneapolis, November 2003) demonstrated some support for radical changes to the Internet Mail environment, especially if such changes would eliminate long-standing problems and result in significant improvements in services. This document proposes one such change that would appear to have several significant advantages. It is also intended to act as a sanity check on the notion that the community is really ready for such changes -- one that stops short of discarding the current email environment and starting over, but that involves a fairly significant change in the way things have worked for many years. 2. Proposal Overview An SMTP extension is introduced called "ENVL" (for "envelope"). If the client and server agree to use that extension, the client sends the ENVL command before it would normally send DATA. That command is immediately followed (i.e., there is no delay for a 3yz response) by the trace information that would normally be prepended to the headers by the client, followed by any trace information received by the client in EVNL commands received by it. In a fashion identical to DATA, the ENVL command is terminated by CRLF.CRLF. Unless it has negotiated other arrangements with the target mail store or MUA(s), the delivery MTA will downgrade all trace information received in ENVL commands back into the headers before prepending the Return-Path field, and SMTP clients that encounter a server that does not support ENVL are expected to do similar downgrading. Because of the downgrading requirement, this extension will not have a significant impact until it is widely deployed. But such wide deployment may accompany SMTP extensions for other new and innovative Klensin Expires July 21, 2004 [Page 3] Internet-Draft A Cleaner SMTP Envelope for Internet Mail January 2004 services that utilize the email infrastructure and which would benefit from a clearer envelope-header separation. For paths in which all components have been upgraded, trace fields will never appear in the message headers. Per-message upgrading, e.g., having an intermediate MTA copy trace information from headers into the envelope, is not permitted except under a narrow reading of RFC 2821's rules about gateways and their transformations. Such upgrading simply introduces too much potential for errors, confusion, and other problems. The impact will increase further if and as message stores, message retrieval protocols, and MUAs are upgraded to take advantage of trace fields that have been separated into the envelope rather than intermixed in the headers. That upgrade may be easier than would appear on first glance, since most of these protocols and products treat the trace fields only as supplemental information to be shown to the user on request, rather than as critical header information -- e.g., they will not notice if they do not receive such information, but will need to be modified to retrieve it if requested. 3. The SMTP Extended Envelope Service Extension The following service extension is defined: 1. the name of the SMTP service extension is "Extended Envelope"; 2. the EHLO keyword value associated with this extension is "ENVL"; 3. No parameter values are defined for this EHLO keyword value. In order to permit future (although unanticipated) extensions, the EHLO response MUST NOT contain any parameters. If a parameter appears, the SMTP client that is conformant to this version of this specification MUST treat the ESMTP response as if the ENVL keyword did not appear. 4. no parameters are added to any SMTP command. 5. One additional SMTP verb, ENVL, is defined by this extension. If the server permits the use of the extension, and the client chooses to take advantage of it, the client will send the ENVL command (without parameters), followed immediately and without awaiting an acknowledgement, a sequence of lines terminated by CRLF (as defined in RFC 2821). Those lines will consist of the trace fields it would ordinarily insert in the headers as RFC 2821 specifies. When it complete sending the trace fields it would insert, it then sends, on subsequent lines, all trace fields from any ENVL command received by it. After all trace fields have been transmitted, the client will send CRLF.CRLF (as specified in RFC 2821 for the termination of the DATA command). 6. The SMTP server will acknowledge successful receipt of the ENVL command (and the associated data) with a "250" response code, and suggested text "ok". The server MAY detect syntax errors in the Klensin Expires July 21, 2004 [Page 4] Internet-Draft A Cleaner SMTP Envelope for Internet Mail January 2004 trace fields, in which case it should return a 501 code, with suggested text "Error in trace field - NNN", where NNN is the sequential number of the trace field, starting with 1 as the first field transmitted to it. Other syntax errors, such as the appearance of parameters to the ENVL command, should also receive a 501 "invalid syntax" response, as specified in RFC 2821. Serious problems in downgrading trace fields should be reported with a 550 code. Implementations of this extension SHOULD use of enhanced error codes [RFC3463], using codes as specified in the next section. 4. Enhanced Status Codes This document updates [[is intended to update]] the list of enhanced codes specified in RFC 3463 to include: A new subject code, X.8.XXX Denoting an envelope syntax error, and the specific detail codes 5.5.2 for errors in the parameters to ENVL (i.e., having any such parameters present). This is the standard enhanced code for command syntax errors. X.8.0 Other or undefined envelope error A syntax error or other problem was encountered in the body of an ENVL command that could not be otherwise identified. X.8.1 Unrecognized field name in envelope body A field was encountered in the envelope body other than a trace field as specified in RFC 2821, or not recognized by the server as an updated version of that protocol. X.8.3 Conversion required but not supported The envelope information must be downgraded in order to be forwarded but such downgrading is not possible for some reason. Servers that are fully compliant with this protocol SHOULD NOT return this code, but it might arise in some gateway situations. X.8.10 Received trace field error Errors were detected in "Received:" trace field syntax, Codes X.8.4 through X.8.9 are explicitly reserved for future extensions and codes of X.8.11 and above are expected to be used for errors associated with trace fields to be defined in the future (if any). While, in theory, non-fatal errors might be associated with these extended codes, only fatal errors (i.e., class code =5) are anticipated. 5. Protocol open questions 1. If we are going to do this, there is a strong case to be made for permitting the trace fields to be in UTF-8. I haven't done it above because of (i) the downgrading complexity it would imply, (ii) If we have any "protocol", rather than "intended for users" Klensin Expires July 21, 2004 [Page 5] Internet-Draft A Cleaner SMTP Envelope for Internet Mail January 2004 information in mail headers, Received fields are almost certainly the best example and the "protocol identifier in ASCII" principle seems to apply strongly here. (iii) It seems to me that this is lots easier to define and think about if the syntax rule is "just exactly what 2821 specifies, only put the data somewhere else". 2. The text above is carefully written in terms of "trace fields" and the protocol is not bound to "Received:" and "Return-path:", which are the only such fields defined in 2821 (or 821). If we are going to do this to ourselves, it might be sensible to think carefully about whether other trace information (e.g., mail server identity traces) would be sensible. If anyone cares about the question, it might be helpful to go back and review what X.400 tried to do in this area -- they may not have gotten it right, but they certainly thought more about the issue than we have since 1980 or 1981. 6. IANA Considerations and Associated Work If IANA is maintaining a registry of enhanced reply codes as specified in RFC 3463, the codes specified in Section 4 should be added to it. If not, IESG should consider such a registry, and the RFC Editor should note that this document, if approved, updates RFC 3463. 7. Security considerations Since the information content of a message transported with this type of envelope is unchanged from that of a message transported with conventional SMTP, the immediate security differences should be slight or none. However, to the extent to which this extension permits, e.g., stronger integrity checks on message headers, it may have a marginal beneficial effect on overall security. 8. Acknowledgements The conclusion that it was time to refine some of the details and turn this idea from a vague concept into a proposal arose during a conversation with Paul Hoffman. He of course bears none of the blame for the specification above. Normative References [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC3463] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003. Klensin Expires July 21, 2004 [Page 6] Internet-Draft A Cleaner SMTP Envelope for Internet Mail January 2004 Author's Address John C Klensin 1770 Massachusetts Ave, #322 Cambridge, MA 02140 USA Phone: +1 617 491 5735 EMail: john-ietf@jck.com Klensin Expires July 21, 2004 [Page 7] Internet-Draft A Cleaner SMTP Envelope for Internet Mail January 2004 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 (2004). 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 Klensin Expires July 21, 2004 [Page 8] Internet-Draft A Cleaner SMTP Envelope for Internet Mail January 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Klensin Expires July 21, 2004 [Page 9]