Re: Recap on mail message compatibility with RFC822 [and it's successor]
> Neither of these are problems at the moment because nobody is doing > this stuff. But if, for example, Microsoft decided to being every > mail header field name with a NUL it would be legal while breaking > lots of things. It would be legal according to RFC 822, but not according to RFC 2822. (RFC 2822 defines NUL and bare CR and LF to be obsolete, and requires that receivers must accept them but senders may not send them.)
Re: Recap on mail message compatibility with RFC822 [and it's successor]
In <[EMAIL PROTECTED]> it was written: >RFC822 [and possibly RFC2822 when I can find a copy since it's not on the ietf >web site, where does one get a copy?] allows single NL characters in header >field bodies, which are supposed to be treated as normal characters, distinct >from the CR-NL pair that indicates the end of a line. The receiving >transformation will probably preserve these, but the result on a *N[IU]X syste ftp://ftp.isi.edu/in-notes/rfc2822.txt That's linked via http://www.rfc-editor.org/go.html So, yeah, ftp.isi.edu is always the host I remember, and when I heard about 2821 a couple days ago, it served me well. Geoff -- Geoff Raye \ All irregularities will be handled by the forces [EMAIL PROTECTED]\ controlling each dimension. Transuranic heavy \ elements may not be used where there is life.
Recap on mail message compatibility with RFC822 [and it's successor]
Thanks for all the responses. Here's a recap of what I think I heard... RFC822 [and possibly RFC2822 when I can find a copy since it's not on the ietf web site, where does one get a copy?] allows single NL characters in header field bodies, which are supposed to be treated as normal characters, distinct from the CR-NL pair that indicates the end of a line. The receiving transformation will probably preserve these, but the result on a *N[IU]X system is likely to be an illegal header since the NL will start another line which is not likely to be a valid header field. Hey, this could be a great spam hack; put a NL in, for example, the subject field, followed by a legal looking but completely bogus received field. RFC822 allows NUL character in header field bodies. This probably will break most *N[IU]X mail programs. Neither of these are problems at the moment because nobody is doing this stuff. But if, for example, Microsoft decided to being every mail header field name with a NUL it would be legal while breaking lots of things. Is this a correct recap? Jon Steinhart
