go-pop3 | Package pop3 provides an implementation of the Post Office | Encryption library

E-mail messages are formatted using basically one of the following two formats.

The oldest one is defined by RFC 5322 (originally it was RFC 822 but it has been updated since then).

This format does not support messages using non-ASCII character encodings and neither does it support what general public calls "attachments".

To rectify the situation, the set of standards commonly known as MIME was invented. The standards in this set define:

• Ways to use non-ASCII character encodings.
• Ways to compose multi-part messages.

The two most interesting MIME standards are RFC 2045 and RFC 2046.

The standards incorporated by MIME were specifically devised in a way to make MIME-encoded stuff still compatible with RFC 822—this, among other things, allowed not to change MTAs to support the new message format.

Libraries implemented in various programming lanugages to deal with various bits defined by MIME usually follow the trend of the MIME itself and are able to transparently handle "plain" RFC 822-formatted mails and MIME-formatted.

To handle MIME-formatted messages, Go offers in its standard library the three packages:

• mime
• mime/multipart
• mime/quotedprintable

and another one, net/textproto, to deal with MIME-style headers (also used in HTTP, IMAP/POP3 etc).

Together, these packages cover most (or all) of what you need to read and write MIME-formatted e-mail messages.

The basic approach to parsing an e-mail message is as follows:

1. Create an instance of bufio.Reader from an io.Reader supplying the data of the e-mail message to be parsed.

2. Create an instance of net/textproto.Reader from the bufio.Reader made on the previous step.

3. Use its ReadMIMEHeader() method to read and parse the message's header block.

4. Check to see whether it contains the MIME-Version field mandated by RFC 2045 to indicate a MIME-formatted content.

   1. If it contains one, verify its value is literally "1.0". If it isn't, this is some MIME format from the future you won't be able to cope with. Barf accordingly; otherwise proceed to the next step.
   2. If there is no such field, the message is a plain old e-mail consisting of a single part. Consider its whole contents as if it were a single MIME-message part (this is oversimplified but would mostly work).

5. If you have verified you're dealing with a MIME 1.0 message, then

   1. Read the Content-Type header field then use mime.ParseMediaType() to parse it.
      • If the resulting mediatype value will start with the "multipart/" prefix, literally, then be prepared to deal with multiple parts, which require recursive processing as each part is formatted almost like the top-level message—that is, contains the header and the body (see below).
      • Otherwise the content type will indicate some kind of "direct" payload (such as "text/plain" or "text/html" or whatever). In this case, a special "parameter" of such media type (see below) indicates the character encoding used for the part's content, if it's textual. (Also note that it may be "message/rfc822" which actually indicates the payload is another e-mail message which might need to be parsed according to the same rules as the encloding one.)

An importand header field to read next is Content-Transfer-Encoding which defines how the part is physically encoded to be transferred over the wire.

Most of the time it will be "base64" but it also may be "quoted-printable".

First, be prepared to properly deal with the different aspects of what "multi part" is: the parts might be either alternatives to each other—that is, the program which is to render a message to the user might pick any of them—whatever suits the user's preference best, or ask them or something else,—or they may be entities sort-of equal to each other. The former scheme is indicated by the "multipart/alternative" media type and is typically used by MUAs which allow the user to compose a mail message using markup and then encode the result so that it contains two alternative parts—one marked as "text/html" and another one marked as "text/plain" and containing the source content stripped of that markup nonsense. The latter is indicated by "multipart/mixed" and is typically used for attachments: with this scheme the first part is typically (but it's not required to be that) is the message's text in whatever format and the rest of the parts are attachments.

To be able to pick out the individual parts from the message's encoding, the "multipart/whatever" media type most of the time contains a so-called "parameter" named "boundary" and containing a unique string which is used to delimit the parts. The mime.ParseMediaType() function returns the media type's parameters in the form of a map as its second result value.

After extracting that "boundary" media type's parameter, you can use it to create an instance of mime/multipart.Reader from the bufio.Reader instance made on the very first step. You can then read the message parts one-by one and act on them.

Note that, as already indicated, a message part might have the content type "message/rfc822" which means it contains another complete mail message (and it itself might be multi-part and contain other mail messages, and so on).