[prev in list] [next in list] [prev in thread] [next in thread] 

List:       debian-user
Subject:    Re: tbird AND javamail both broken
From:       "Gareth Evans" <donotspam () fastmail ! fm>
Date:       2022-11-30 22:58:40
Message-ID: 81C4F83B-443B-4A27-9FEA-C535AFD804E1 () fastmail ! fm
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]