Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu> writes:
Ideally, the gateways from such environments to the Internet should
change the CRLF 1*SPACE CRLF following a header back to CRLF CRLF, but
I'm not holding my breath until this happens.
Such messages don't necessarily leave such environments through mail
gateways. In a case reported to me, the user saved the message to a
file inside such an environment, transferred the file to a PC, then
tried to use my MIME reader, munpack, to extract the Pine attachment.
It just so happens that mpack 1.5 can decode Pine messages which have
been damaged in this way. This was a complete surprise to me, I had
to step through the program with a debugger to figure out why it was
working. But that's a saga in itself.
I think this falls in the same category as SPACEs after MIME boundary
markers: they shouldn't be emitted by mail composers, but mail readers
need to be able do to deal with them.
However, a space on a line by itself is defined by RFC822 as being a
header continuation line. In order for mail readers to be permitted
to deal with them as separating headers from the body, they have to be
specifically declared as not being legal header continuation lines.
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up