RFC2821bis-01 Issue 0b: Deferred action on MAIL command argument (was:

Tony,

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.
  john

--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
>         tony(_at_)att(_dot_)com
>
> 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
> > 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.
> >
> > --
> > HLS
> >
> >
> > 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
> > >     tony(_at_)att(_dot_)com
> > >
> > >
> > > ------------------------------------------------------------
> > > ------------
> > >
> > > Subject:
> > > I-D ACTION:draft-klensin-rfc2821bis-01.txt
> > > From:
> > > Internet-Drafts(_at_)ietf(_dot_)org
> > > Date:
> > > Thu, 08 Mar 2007 10:50:02 -0500
> > > To:
> > > i-d-announce(_at_)ietf(_dot_)org
> > >
> > > To:
> > > i-d-announce(_at_)ietf(_dot_)org
> > > CC:
> > >
> > >
> > > 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:
> > > http://www.ietf.org/internet-drafts/draft-klensin-rfc2821bis
> > > -01.txt
> > >
> > > 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
> > > https://www1.ietf.org/mailman/listinfo/I-D-announce 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
> > > http://www.ietf.org/shadow.html or
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >
> > > Internet-Drafts can also be obtained by e-mail.
> > >
> > > Send a message to:
> > >     mailserv(_at_)ietf(_dot_)org(_dot_)
> > > In the body type:
> > >     "FILE /internet-drafts/draft-klensin-rfc2821bis-01.txt".
> > >
> > > NOTE:    The mail server at ietf.org 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
> > > I-D-Announce(_at_)ietf(_dot_)org
> > > https://www1.ietf.org/mailman/listinfo/i-d-announce