--On Tuesday, 05 July, 2005 13:22 -0400 Hector Santos
<hsantos(_at_)santronics(_dot_)com> wrote:
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.
Of course not. 2821 is clear about not requiring rejection of
anything it does not specify, only that such things are outside
the standard. And a reasonable person might argue that the
robustness principle requires tolerance of the space if that is
reasonable for the server. The difference between that and
putting it into 2821bis as a requirement is that, as soon as
2821 requires that servers support it, we've all got one less
way to flag incompetently-constructed clients. When I've had
to negotiate with the authors of such clients, a list titled "50
ways your client is broken" has been an important tool. I don't
see any reason to give in to sloppy and/or incompetent behavior
by formally declaring what those implementations to be the norm,
no matter who supports it.
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.
I think we disagree. See above. 2821/ 2821bis are not about
giving in to the lowest competency level commonly encountered
among clients and servers. To state that again, there is no
reason to permit or require this. The server implementers who
decide, for market reasons, that they want to support MAIL and
RCPT commands with the space after the colon (or with no pointed
brackets at all, which we have all seen) can do so as a
robustness extension outside the standard. But let's not
require anyone to do so -- a few strictly-conformant
implementations are probably good for the network.
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.
See my previous note. To the extent to which these things are
useful, they may make reasonable extensions to SMTP, using the
established extension model. Such extensions will either
survive and thrive in practice or they won't. But they should
impact the base standard only if either:
(i) they demonstrate a need for changes that are _required_ to
support them, i.e., that the current extension model is
inadequate in some important way. So far, the attempts to make
that case have been rather weak, at least IMO. Or,
(ii) they are widely deployed and proven at substantially the
level SMTP itself is. No theories about things that might
work, especially theories that require flag days or wide
deployment to be useful at all, are welcome in the SMTP spec, at
least as far as I'm concerned.
john