Rick Troth <TROTH(_at_)ua1vm(_dot_)ua(_dot_)edu> writes:
No it doesn't. That is, given the sample sets I've had,
there has not been on "hit", not one instance of (as you note yourself)
a legit mail item that would have been broken by said non-compliance.
This is not a compelling argument for violating the standard. It is,
at best, a supporting argument for changing the standard.
fundamental difference in thinking. Mail, even STMP (that is, on the
wire) isn't a stream of bytes, it's a sequence of records, sometimes
"continued", and we find that one of the rules for continuation is
difficult to implement reliably across all Internet-connected platforms.
I tell you, this would be to everyone's advantage in the long run.
The significance of leading whitespace in header parsing is carved in
stone. It cannot be changed.
RFC 822 and its variantes are used in environments other than
traditional mail. The problem with thinking too much in terms of
"lines" is that you end up having arbitrary line length limitations,
which are inappropriate in some environments.
The rules can be fiddled with in minor ways to make things less
sensitive to trailing whitespace, but if these definitions are done
incorrectly, one ends up having to write parsers with large or
arbitrary amounts of lookahead.
Steve Dorner <sdorner(_at_)qualcomm(_dot_)com> writes:
I'd feel a lot better about the "fix" if there was somewhere some advice
for composers that CR LF SPACE CR LF, even though legal in headers, be
avoided. The mailproblems RFC seems to me like a good place for that
I would feel better if the fix was to amend RFC 822 to make a line
containing a single space character illegal in headers. That would
give parsers the freedom to treat "CR LF SPACE CR LF" as a separation
line or not.
The appropriate place for this would be the upcoming 822 AS.
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU