Unable to parse nested MIME boundaries with the same ids

[alexk307]

If a message contains nested MIME boundaries, and the inner boundary contains a nested boundary with the same name as the outer boundary, the parser will stop reading when that boundary is closed, regardless if there is more to read.

This is explicitly called out in the RFC:

As stated previously, each body part is preceded by a boundary
delimiter line that contains the boundary delimiter. The boundary
delimiter MUST NOT appear inside any of the encapsulated parts, on a
line by itself or as the prefix of any line. This implies that it is
crucial that the composing agent be able to choose and specify a
unique boundary parameter value that does not contain the boundary
parameter value of an enclosing multipart as a prefix.

However, I think that the parser should not trust that the composing agent has followed this rule, since you can craft emails without the use of clients that enforce these standards. The parser should maintain context about which boundary its currently in, rather than just the initial boundary, so that they are nested properly, and no data is dropped.

Example:

MIME-Version: 1.0

--boundary_outer
Content-Type: multipart/alternative;

  --boundary_inner
  Content-Type: multipart/alternative;

  <Message Body Here>

  boundary="boundary_outer" <-- creates a boundary within the `boundary_inner` with the same name as the outer boundary.
  type="text/html"

  --boundary_outer--  <-- closes the nested boundary with same name, but the parser thinks that the message is over now

  --boundary_inner--

   <Message content that is not parsed>

--boundary_outer--