Allow me to suggest another not-sufficiently-uncommon problem:
Attempting to end the headers of a message with a line consisting of a
single blank. Ie, CR LF SPACE CR LF instead of CR LF CR LF.
Yes. It's a common problem.
Ned's right that it's *very* common on BITNET. But I must
confess to being guilty of introducing it in a completely non-BITNET
situation. Yes, the gateways should "clean that up", but yes,
the user agents should give a little more room.
I've argued a number of times that trailing white space
should not be significant. Upon reflection, I find that I wrote
some code where leading white space was significant and required.
And this was in a configuration file. Shame on me. Bad planning.
There was a reason for it, but in trying to practice what I have preached
(even though I specifically addressed TRAILING, not LEADING, white space),
I'm on the move to stamp out surrounding white space in my lifetime. :-)
The space keeps the headers from ending, and the poor recepient mailer
proceeds to try to digest the body of the mail as though it were more
I wrote to one vendor who's mail UA had a real problem with this.
They wouldn't "fix" the program. I had to complicate the lives of a
number of my users. It would be nice if the spec(s) addressed this
in the future. What's clearly implied in one reader's eyes is not
even permitted in another reader's eyes. [sigh]
Trailing white space should NOT be significant.
Leading white space should not be significant, though I could
generate examples where it's programatically desired. Neither
should be intentionally stripped from an object in transport.
(a gateway from/to a problem environment being an exception)
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."
Rick Troth <troth(_at_)ua1vm(_dot_)ua(_dot_)edu>, Houston, Texas, USA