ietf-smtp
[Top] [All Lists]

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

2007-03-23 04:02:24

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