[Top] [All Lists]

RFC2821bis-01 Issue 0b: Deferred action on MAIL command argument (was: Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt])

2007-03-23 08:48:00


This is fine with me, but I want to note, as editor, that the topic (deferred reports of problems with backward-pointing addresses) now being referred to as 0b was, I believe, the subject of considerable discussion and a consensus in DRUMS. Unless either I can be persuaded that my memory is faulty or that a new consensus has really emerged, they will not be changed.


--On Friday, March 23, 2007 06:49 -0400 Tony Hansen <tony(_at_)att(_dot_)com> wrote:

In my "issue tracker" for 2821bis, I've placed these two items
as #0a and #0b. As there has been no further discussion on
them, I've also categorized them as "Editorial", to be handled
by the Editor at his discretion.

        Tony Hansen

Hector Santos wrote on March 8, 2007:
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

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

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 Internet-Draft.


I-D-Announce mailing list

<Prev in Thread] Current Thread [Next in Thread>