On Mon, 12 Sep 2005, John C Klensin wrote:
I would only point out that no validator can distinguish or
decide between two alternatives, each of them perfectly valid
ABNF. Both the 2821bis form of the relevant productions and the
2821 form are valid; they just have slightly different
implications.
Its not exactly good when you have next version of standard that
redefines ABNF and what is compatible with new version is not
compatible in the old one. The only cases I think are acceptable
without a lot more careful review of the issue is when the original
ABNF is considered have had a bug (and the actual use of the standard
is inconsistent with ABNF because of this bug) that needs to be fixed.
That said Received header fields are one of the worst cases of email
(non)standardized use. At some point I've attempted to find how many
of the Received seen in the email and how many MTAs/MUAs actually do
it right and was astonished how small the number was (Received are fully
correct per standard in about 1 out of 5 emails). There are numerous
things that are done wrong from various comment-type additions where
comment is not allows (how do you like comments after timestamp?
apparently one major MTA vendor really likes doing it) to using incorrect
values in VIA and WITH (really strange values sometimes that makes me
wonder if author of software bothered to read standard to understand
what these are for). BTW - check out Received in this email that came
through this email list for fun exercise and count number of errors.
So changing of standard for this header field is probably not going to
make things any worse (hard to do that...), but I think it might be
better if separate document is written exclusively about Received field
and its use and values that go in there and that document is sent to IESG
review as "update" to RFC2821 (with appropriate last call within IETF).
In some cases it's a question of "what's less harmful",
you can't allow crap like bare-CR and forbid it at the
same time. If absolutely necessary there's that MUST
accept + MUST NOT generate option.
Yes. But please go review the robustness principle and remember
that implementers will do whatever they consider morally and/or
commercially necessary. If the standard tells them to do
otherwise, the standard will be ignored. Every single time.
In case of Received it really is not "commercial necessary" in any
of the mistakes I've seen MUAs and MTAs (it takes same amount of
effort for programmer to use different & correct values for output,
appropriate order or placement of comments). It really is the case of
not reading enough about the standard use, which makes me think we
don't have it defined well enough for implementation compatibility.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net