Re: [Fwd: I-D ACTION:draft-klensin-rfc2821bis-01.txt]
Regarding your zero based consideration 0a, (Don't know why you even
bothered, I could care less), but how can anyone still believe that the
"ignorant user" is not an billion dollar industry? At the very least,
the text should be removed. It simply isn't true any more and
furthermore, subjective editorials should not be part of local policy
Regarding 0b, what you do mean its not being discussed? You guys are
spending an awful lot of time of the semantics of the TLD! Its all
related to the general issue and concern of compliance. John, also just
touch based with it as well in his recent post and questions. And yes, I
am suprise people like Frank and Scott and others having chimed in as
Return Path validity is become a fundamental part of all the new email
validation/authorization efforts in the past 3-4 years, from SPF,
SENDER-ID, the growth of CBV, and CRS to DKIM.
Maybe I wasn't clear, but my suggestion was about summarizing what the
technical requirements for validity to help the new generation for
acception/rejection critirias and in addition, I can only hope, this
becomes the new basis to work from. I don't see that as "Editorial."
That's that last thing I would hate to see done left undone and
subjective to one's man opinion. Please, don't do me the favor. Leave
it out if you don't care for it. Oa? Ob? Pleeze. I'm not basing my
product future directions designs on your guys anyway. You would like
to, but geez, that isn't reality.
Tony Hansen 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
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.
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,
Thu, 08 Mar 2007 10:50:02 -0500
A New Internet-Draft is available from the on-line Internet-Drafts
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
the message. You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
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
A list of Internet-Drafts directories can be found in
Internet-Drafts can also be obtained by e-mail.
Send a message to:
In the body type:
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
I-D-Announce mailing list