A Cleaner SMTP Envelope for Internet Mail
draft-klensin-email-envelope-00

Versions: 00                                                            
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]