0

With JavaMail, I am building messages with the following format

+------------------------------------------------+
| multipart/related                              |
| +---------------------------+  +-------------+ |
| |multipart/alternative      |  | attachments | |
| | +-----------+ +---------+ |  |             | |
| | |text/plain | |text/html| |  |             | |
| | +-----------+ +---------+ |  |             | |
| +---------------------------+  +-------------+ |
+------------------------------------------------+ 

ASCII art attributed to the OP of this question: http://www.coderanch.com/t/503380/java/java/Java-Mail-text-html-attachment

I felt that this would be the correct format, since the attachments (image/gif, application/pdf, etc.) are important in understanding the message as a whole. However, I've been doing some researching and have found that oftentimes multipart/mixed is used.

Should I replace the multipart/related section with multipart/mixed? If so, why?

An example message in this format would be as follows:

Content-Type: multipart/related; 
    boundary="----=_Part_6818257_562311419.1408632937947"

------=_Part_6818257_562311419.1408632937947
Content-Type: multipart/alternative; 
    boundary="----=_Part_6818256_1953685207.1408632937947"

------=_Part_6818256_1953685207.1408632937947
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

This is my message!
------=_Part_6818256_1953685207.1408632937947
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<html><strong>This is my message!</strong></html>
------=_Part_6818256_1953685207.1408632937947--

------=_Part_6818257_562311419.1408632937947
Content-Type: application/pdf;name="document.pdf"
Content-Transfer-Encoding: base64
Content-ID: <attachment0>
X-Attachment-Id: attachment0

< insert lots of base64 encoding here >
------=_Part_6818257_562311419.1408632937947--
Wesley Porter
  • 1,401
  • 2
  • 13
  • 15

1 Answers1

2

After doing some more searching, I found this post, which practically matches my concern here.

According to the RFC spec, it appears that the best way to structure email messages is in the following format:

+-----------------------------------------------------------+
| multipart/mixed                                           |
| +--------------------------------------+  +-------------+ |
| | multipart/alternative                |  | attachments | |
| | +------------+ +-------------------+ |  |             | |
| | | text/plain | | multipart/related | |  |             | |
| | |            | | +---------------+ | |  |             | |
| | |            | | | text/html     | | |  |             | |
| | |            | | | image/gif     | | |  |             | |
| | |            | | +---------------+ | |  |             | |
| | +------------+ +-------------------+ |  |             | |
| +--------------------------------------+  +-------------+ |
+-----------------------------------------------------------+ 

With this configuration of messages, email clients can decide on the alternative type of message to display. In addition, multipart/related constitutes what is related to the message portion of the email, not including attachments.

For more clarification on multipart/related comes from Wikipedia:

A multipart/related is used to indicate that each message part is a component of an aggregate whole. It is for compound objects consisting of several inter-related components - proper display cannot be achieved by individually displaying the constituent parts. The message consists of a root part (by default, the first) which reference other parts inline, which may in turn reference other parts. Message parts are commonly referenced by the "Content-ID" part header. The syntax of a reference is unspecified and is instead dictated by the encoding or protocol used in the part.

One common usage of this subtype is to send a web page complete with images in a single message. The root part would contain the HTML document, and use image tags to reference images stored in the latter parts.

Defined in RFC 2387

Another great article referencing solutions by Microsoft Exchange.

Community
  • 1
  • 1
Wesley Porter
  • 1,401
  • 2
  • 13
  • 15