John, Thanks for lurking and I'm sorry it hurts to do so. I just hope it
was not all in vain.
Just my opinion:
The majority of all servers tolerate the space issue for all commands. I'm
sure you don't believe this makes them non-conformant to allow for this
behavior.
I understand the legacy issues regarding the trailing spaces, been there to
during the non-interactive to interactive interfacing design world. But just
as there is exception in 2821 (but not in the STD 10), I think it is
practical to include a reason for why there exist a space tolerance in the
majority of servers on the network.
If 2821bis is about "cleaning", removing ambiguity, reaffirming consistency,
etc, this would be one of them.
It is my hope there is insight to be again, not just at the purity of SMTP
syntax, but in how it continues to evolve and interface in current and
future considerations. For one example, what can SMTP do at the
simplistic level to assist (in general) the new DNS-based or email security
proposed protocols? If you believe, nothing, then I can accept that. I
personally would not agree, but I accept it.
Thanks for your comments
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "John C Klensin" <john+smtp(_at_)jck(_dot_)com>
To: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>;
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, July 05, 2005 7:55 AM
Subject: Re: Strict RFC x821 Compliant: MAIL FROM:
--On Sunday, 03 July, 2005 03:00 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
Well, that's your opinion. My opinion is that every
relaxation leads to overhead and more code (and in the worst
case to security problems). Where do you draw the line?
I feel ya. 100%. I agree with your thinking. I'm a stickler
when it comes to comformance. But I thin,. agan, just my
opinion, I would make an exception simply because its already
burned in.
In fact, I think 2821bis should probably consider relaxing
this with a similar statement it has for the trailing space
consideration:
Technically, the spec for the MAIL command is::
MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF>
No space before <CRLF> but section 4.1.1 says:
4.1.1 Command Semantics and Syntax
.....(In the interest of improved interoperability, SMTP
receivers are encouraged to tolerate trailing white space
before the terminating <CRLF>.)
I think this should also include the space before the
reverse-path.
Hector, FWIW, these are rather different creatures. The
encouragement to tolerate trailing white space is due to a
history of machines and operating systems whose notion of "line"
is quite different from the "data stream with inline line
delimiters" approach that is assumed by the Internet. Some of
those have included variable length records with word counts and
fixed length record approaches, both with padding. On either
one, producing output without trailing white space, especially
when SMTP is simulated via telnet for testing purposes, can be
quite troublesome. We don't see a lot of those systems of late,
but they are still around. By contrast, there is no excuse
(other than plain sloppiness) on any system for putting a space
between the colon and the left pointed bracket that starts the
reverse path in the RCPT command and the similar structure in
the MAIL command.
To permit that space (just one space? an arbitrary amount of
space?) violates the principle that the syntax of SMTP commands
should be as simple, with as few variations, as possible. It
would make a certain number of server implementations that a
conforming today non-conforming. And it would accomplish what??
john