[Top] [All Lists]

Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]

2007-03-08 13:48:00

Hi Tony,

I'm doing this quickly with the time I have at the moment.

First the obvious:  Two items:

This 7.1 statement is not longer valid:

| 7.1.  Mail Security and Spoofing
|  ...
|  This specification does not further address the authentication
|  issues associated with SMTP other than to advocate that useful
|  functionality not be disabled in the hope of providing some
|  small margin of protection against an ignorant user who is
|  trying to fake mail.

Its no longer a "ignorant user" but a 10+ billion dollar industry. That statement should not be there as SMTP should not making "moral judgments" on operations. As it was, it was ignored anyway in practice.

The second thing, is related to:

| 3.3 Mail Transactions
|    .....
|   .............  Despite the apparent
|   scope of this requirement, there are circumstances in which the
|   acceptability of the reverse-path may not be determined until one or
|   more forward-paths (in RCPT commands) can be examined.  In those
|   cases, the server MAY reasonably accept the reverse-path (with a 250
|   reply) and then report problems after the forward-paths are received
|   and examined.  Normally, failures produce 550 or 553 replies.

This is a touchy concept, but I think we need to have a section, and I know you said NO restructuring, on MAIL FROM VALIDITY requirements as it applies to operations and/or legalities (CAN SPAM). I know we don't want to talk about the laws, etc, but I only mention it because this here is one of the most important aspect in many of the issues that is going on with SMTP today.

In the similar vain, HELO/EHLO requirements should be reviewed.

In short, the days of these fields being too RELAXED are pretty much over, and that doesn't mean that it should break the system - no, but the talk that it should be RELAXED as a old fundamental premise for the "growth of the Internet" does not apply anymore.


Tony Hansen wrote:
Let the fun begin.

Remember, we are looking for:

   1)   clarifications of the spec where there are discrepancies, and
   2)   removal of unused features.

If anyone would like to provide implementation reports, that would be
useful for reaching concensus on #2.

Please use a separate subject line for each issue you wish to raise.

Your pseudo-chair for this effort,

        Tony Hansen


I-D ACTION:draft-klensin-rfc2821bis-01.txt
Thu, 08 Mar 2007 10:50:02 -0500


A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Simple Mail Transfer Protocol
        Author(s)       : J. Klensin
        Filename        : draft-klensin-rfc2821bis-01.txt
        Pages           : 90
        Date            : 2007-3-8
This document is a largely self-contained specification of the basic
   protocol for the Internet electronic mail transport.  It
   consolidates, updates, and clarifies several previous documents,
   making all or parts of most of the obsolete.  It covers the SMTP
   extension mechanisms and best practices for the contemporary
   Internet, but does not provide details about particular extensions.
Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its
   use as a "mail submission" protocol for "split-UA" mail reading
   systems and mobile environments.

A URL for this Internet-Draft is:

To remove yourself from the I-D Announcement list, send a message to i-d-announce-request(_at_)ietf(_dot_)org with the word unsubscribe in the body of the message. You can also visit to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-klensin-rfc2821bis-01.txt".

A list of Internet-Drafts directories can be found in or

Internet-Drafts can also be obtained by e-mail.

Send a message to:
In the body type:
        "FILE /internet-drafts/draft-klensin-rfc2821bis-01.txt".
NOTE:   The mail server at can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail readers
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the


I-D-Announce mailing list