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]