On Tue 29 Nov 2022 at 12:31:09 (-0500), Jeffrey Walton wrote:
> On Sat, Nov 26, 2022 at 11:02 AM 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.
> >
> > 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.
> >
> > 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.
>
> <CRLF>.<CRLF> is the end of mail data indicator. See RFC 821.
Correct, but bear in mind that no blank lines are implied by this
construct. If you type an email directly into a mail submission
system, the last few lines of the conversation will typically be:
last line of text in body. ← the email message itself
. ← your <CRLF>.<CRLF> construct
quit ← terminate the openssl session
that's handling TLS
> <Newline><Newline> is a new line and then another new line. But I am
> having trouble picking the grammar rule to handle it. If it were under
> the DATA command, it would just be another empty line. But I can't
> tell what it is when part of the MAIL command. See RFC 821 and RFC 822
> (for the grammar).
Your observations are at the level of SMTP, used to transport the
outermost body of the email. This body is indeed enclosed in the
DATA and <CRLF>.<CRLF> you mentioned. (The MAIL FROM command
comes a little earlier, at the same level.)
But this thread concerns the structure inside the outermost body,
and that consists of potentially recursive message bodies in MIME
format, for which you need RFCs 2045–9. You can see in RFC2049
appendix A that the DATA (before) and <CRLF>.<CRLF> (after) have
been stripped off as they're outside consideration here.
Cheers,
David.
