Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA26336; Tue, 16 Sep 1997 10:40:40 -0400 (EDT) Received: by CS.UTK.EDU (bulk_mailer v1.7); Tue, 16 Sep 1997 10:39:14 -0400 Received: by CS.UTK.EDU (cf v2.9s-UTK) id KAA26263; Tue, 16 Sep 1997 10:39:13 -0400 (EDT) Received: from ns.research.att.com (ns.research.att.com [192.20.225.4]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id KAA26253; Tue, 16 Sep 1997 10:39:05 -0400 (EDT) Received: from research.att.com ([135.205.32.20]) by ns; Tue Sep 16 10:38:40 EDT 1997 Received: from raptor.research.att.com ([135.207.23.32]) by research; Tue Sep 16 10:35:30 EDT 1997 Received: (from tscola@localhost) by raptor.research.att.com (8.8.5/8.7) id KAA27861; Tue, 16 Sep 1997 10:35:29 -0400 (EDT) Date: Tue, 16 Sep 1997 10:35:29 -0400 (EDT) Message-Id: <199709161435.KAA27861@raptor.research.att.com> From: Tom Scola To: drums@cs.utk.edu Subject: Semantics of Folding white-space inside quoted-string We have been receiving mail with attachments from Microsoft Exchange users with the following structure: X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: multipart/mixed; boundary="---- =_NextPart_000_01BCC279.9FFB9E30" ------ =_NextPart_000_01BCC279.9FFB9E30 Content-Type: text/plain Which most of our UAs fail to parse. The question is whether or not the FWS inside the quoted-string gets interpreted as a single space or not. RFC822 was decidedly ambiguous on the subject (from Section 3.4.5): Therefore, the official semantics do not "see" any bare CRLFs that are in quoted-strings; however particular parsing programs may wish to note their presence. For such programs, it would be rea- sonable to interpret a "CRLF LWSP-char" as being a CRLF which is part of the quoted-string; i.e., the CRLF is kept and the LWSP-char is discarded. However, draft-ietf-drums-msg-fmt-02 has nothing to say on the subject, other than that the normal folding rules apply (Section 3.2.6): Since a quoted-string is allowed to contain FWS, folding is permitted. So I take that as meaning that the above header *might* be illegal under RFC822, but it is definitely legal under RFC822bis. Right?