On Sat 26 Nov 2022 at 19:45:37 (+0000), Gareth Evans wrote: > On Sat 26 Nov 2022, at 16:01, David Wright <deb...@lionunicorn.co.uk> wrote: > > On Sat 19 Nov 2022 at 20:38:46 (+0000), Gareth Evans wrote: > >> On Sat 19 Nov 2022, at 20:15, Gareth Evans <donots...@fastmail.fm> wrote: > >> [...] > >> > I'm not sure this is a Tb bug, just perhaps a "purist" way of doing > >> > things ... > >> > >> I had assumed no blank line preceding a boundary was required as Tb still > >> processes the boundary without one, but > >> > > >> https://www.rfc-editor.org/rfc/rfc2049.html#page-15 > >> > >> suggests this is in fact a requirement. So perhaps a bug. > > > I don't see where the RFC talks about blank lines. > > It doesn't, save for one mention in the appendix, and that was sort of my > point... > > > The text part of my emails (where they include an attachment) end > > as usual with the characters "David.<Newline>", and that Newline > > is the last character of mine. It's then followed by another > > Newline which is the start of the Unique Boundary Marker. > > > > David.<Newline><Newline>BOUNDARY MARKER > > ↑ ↑ ↑ ↑ > > mine marker's > > > > > That pair of Newlines give the appearance of a blank line, which > > you assume is necessary. > > Well... I meant "suggests" literally, because... > > At the time of writing the message you refer to above, I had taken the > Appendix A example in RFC2049 ("[MIME] ... Conformance criteria and > examples") to be prescriptive by example (a "conformance example"!), given > blank line requirements are less than definitively spelt out there. > > RFC1521, obsoleted by 2049, includes: > > " 7.2 ... Each part > starts with an encapsulation boundary, and then contains a body part > consisting of header area, *a blank line*, and a body area ... > NO header fields are actually required in body parts. A body part that > starts with a blank line, therefore, is allowed ..." > > https://www.rfc-editor.org/rfc/rfc1521
Yes, but my post responded to, and only concerned, what lies between the end of the body area and the next boundary marker, whereas your quotation here from RFC1521 (which I haven't consulted) is about the beginning of the body area and any header preceding it. > but this text does not appear in RFC2049, where the notion is merely implied > in a bracketed note in an example in an appendix, which also contains the > only appearance of "blank". > > "Appendx A -- A Complex Multipart Example > > [...] > > MIME-Version: 1.0 > From: Nathaniel Borenstein <n...@nsb.fv.com> > To: Ned Freed <n...@innosoft.com> > Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT) > Subject: A multipart example > Content-Type: multipart/mixed; > boundary=unique-boundary-1 > > This is the preamble area of a multipart message. > Mail readers that understand multipart format > should ignore this preamble. > > If you are reading this text, you might want to > consider changing to a mail reader that understands > how to properly display multipart messages. > > --unique-boundary-1 > > ... Some text appears here ... > > *[Note that the blank between the boundary and the start > of the text in this part means no header fields were > given* [...] Yes, there must be a blank line there because it either terminates this part's header fields (as shown next), or indicates that there are no header fields for this part (as shown above). > > --unique-boundary-1 > Content-type: text/enriched > > This is <bold><italic>enriched.</italic></bold> > <smaller>as defined in RFC 1896</smaller>" > > https://www.rfc-editor.org/rfc/rfc2049.html#page-15 > > There are blank lines between part header fields and content - but this > requirement is implied rather than specified in terms, as it is in 1521. But surely you just quoted the specification: > " 7.2 ... > and then contains a body part > consisting of header area, *a blank line*, and a body area ... (presumably that's your *emphasis* added). > There are blank lines between content and following boundaries - this may be > for readability purposes, but at the time, I thought this suggestive of > requirement. > > I read somewhere else (which I now can't find) that a boundary must be > preceded by a CRLF, which is considered part of the boundary - but not > necessarily a blank line. It's in the next appendix: Appendix B -- Changes from RFC 1521, 1522, and 1590 These documents are a revision of RFC 1521, 1522, and 1590. For the convenience of those familiar with the earlier documents, the changes from those documents are summarized in this appendix. [ … ] [ … ] (7) The BNF for the multipart media type has been rearranged to make it clear that the CRLF preceeding the boundary marker is actually part of the marker itself rather than the preceeding body part. An effect of this is that it ensures the boundary marker must start in column 1, which in turn means that it's easy to quote in the conventional manner, because the "> " negates that. > > If there were only one Newline, it would belong to the marker, > > and my text would finish at the Period. You can sometimes > > observe this with non-text parts because, for example, HTML > > parsers don't necessarily care whether </html> is followed > > by Newline. Cheers, David.
