What do the numbers in a multi-part email mean?

Question

I'm looking at the source of a multi-part message from Thunderbird (in hopes of writing my own multi-part message from C++/Javascript)

I was wondering what the follow means (the part between the text-only part and the html part of the email) and how I might calculate it for my own program to generate a multi-part email:

This is a multi-part message in MIME format.

------=_NextPart_32252.1057009685.31.001
Content-Type: multipart/alternative;
    boundary="----=_NextPart_32252.1057009685.31.002"
Content-Description: Message in alternative text and HTML forms


------=_NextPart_32252.1057009685.31.002

(as seen here)

The rest of the message code makes sense to me for the post part.

Answer 1

They don't mean anything. They are just a random string that does not occur within the body of the email. They are just used to mark where the embedded message starts and stops.

Answer 2

The numbers you are seeing within the boundary delimiters don't necessarily mean anything (although the RFC doesn't preclude an implementor from trying to include some meaning).

They must be unique and not contained within the part that they encapsulate.

From RFC 2046:

5.1. Multipart Media Type

In the case of multipart entities, in which one or more different sets of data are combined in a single body, a "multipart" media type field must appear in the entity's header. The body must then contain one or more body parts, each preceded by a boundary delimiter line...

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...

...

5.1.1. Common Syntax

The Content-Type field for multipart entities requires one parameter, "boundary". The boundary delimiter line is then defined as a line consisting entirely of two hyphen characters ("-", decimal value 45) followed by the boundary parameter value from the Content-Type header field, optional linear whitespace, and a terminating CRLF.

...

NOTE: Because boundary delimiters must not appear in the body parts being encapsulated, a user agent must exercise care to choose a unique boundary parameter value. The boundary parameter value [could be] the result of an algorithm designed to produce boundary delimiters with a very low probability of already existing in the data to be encapsulated without having to prescan the data. ... The simplest boundary delimiter line possible is something like "---", with a closing boundary delimiter line of "-----".