How to interpret multipart that’s missing a CRLF?

Question

Here’s a RFC 2046 multipart octet stream that uses a boundary of "boundary".

--boundary
Content-Type: text/plain; charset="US-ASCII"

abc

--boundary

a
--boundary


--boundary

--boundary
--boundary--

Part 1 is abc\r\n with a trailing CRLF and one header describing its content-type.

Part 2 is a with no headers and no trailing newline.

Part 3 is empty.

What is part 4? Is there a part 5?

Answer 1

Although I cannot provide a definite answer, this would be my reasoning, based on the RFC:

Following the BNF from RFC 2046, the last part of the example (i.e. OP's "part 4" and "part 5") could be summarized as

delimiter CRLF delimiter close-delimiter

where delimiter := CRLF dash-boundary. The BNF for the multipart body is defined as

multipart-body := [preamble CRLF]
                  dash-boundary transport-padding CRLF
                  body-part *encapsulation
                  close-delimiter transport-padding
                  [CRLF epilogue]

where

encapsulation := delimiter transport-padding
                 CRLF body-part

Although RFC 2046 includes two, apparently different, rules for body-part, viz. here and here, it seems body-part may be empty (also see MIME-part-headers in RFC 2045 and message in RFC 822). In addition, transport-padding should be empty.

Assuming this is the case, then encapsulation with an empty body-part would be delimiter CRLF.

I guess this would make "part 4" officially empty.

As for "part 5", based on the above, I would expect the stream to end in encapsulation close-delimiter, so that would be delimiter CRLF close-delimiter.

However, the stream ("part 5") ends in delimiter close-delimiter, without a CRLF (I assume this is the "missing a CRLF" from the question title).

Doesn't this mean the stream is simply invalid (or non-compliant)?