On Sat 26 Nov 2022, at 16:01, David Wright <[email protected]> wrote: > On Sat 19 Nov 2022 at 20:38:46 (+0000), Gareth Evans wrote: >> On Sat 19 Nov 2022, at 20:15, Gareth Evans <[email protected]> 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. Hi David, 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 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 <[email protected]> To: Ned Freed <[email protected]> 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* [...] --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. 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. Best wishes, Gareth > > 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.
