[Top] [All Lists]

Re: "More-stuff" in Received fields

2005-09-12 22:36:55

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

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