Re: tbird AND javamail both broken
On Tue 29 Nov 2022, at 16:52, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Sat 26 Nov 2022 at 19:45:37 (+0000), Gareth Evans wrote:
>> On Sat 26 Nov 2022, at 16:01, David Wright <deblis@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 <donotspam@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.
Sorry, the point I was getting at didn't quite emerge!
I meant the fact that there are blank lines in the example
https://www.rfc-editor.org/rfc/rfc2049#page-15
before each boundary, as well as after all of the part field headers, it being a conformance example, initially suggested requirement to me. But I now realise that the example's blank lines before the part boundaries are there for readability purposes, and form part of the sections including the text preceding them. So the example leaves that at least for the reader to interpret correctly.
I discovered last night that the BNF for the formal definitions, which you have to string together to generate a blank line from concatenating CRLFs, appears in RFC 2046. This isn't named or linked to in 2049's Abstract, as the other docs in the latest MIME "set" are. I was skimming a bit and didn't see the other references to 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
>> [...]
>> --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).
>> 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 ...
That quote was from 1521:
>> RFC1521, obsoleted by 2049, includes:
>> " 7.2 ... Each part ..."
- whereas afaics, 2049 only offers the note in Appendix A, from which the necessity for a blank line following part headers can be deduced, but you have to think about it, and know that it needs to be thought about. I thought the idea of RFCs was at least partly to explain things as well as specify. If so, I don't think RFC2049 does this as well as 1521.
> (presumably that's your *emphasis* added).
Yes, I should have noted it.
>> 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:
Thank you.
> 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.
Nifty :)
Many thanks,
Gareth
Reply to: