Order of body parts in Mail::Message

[mmriech]

Before describing the issue I have to admit that this topic has been discussed before at least in the following issues: #853, #706 #675 #655

But I would like to draw the attention to what the specification (rfc2046) actually says, or at least how I would interpret it. To be honest the matter is a bit ambiguous, so I did not provide a pull request yet.

What I was basically doing is assembling a message of MIME-Type "multipart/mixed". One part is a "multipart/alternative" which actually contains my "message" as text and html. The other parts are attachments (disposition-type "attachment") of type "text/plain".

When sending the message the parts are reordered using their MIME-Type type, starting with text, going over multipart to unknown types. In my message this results in the attachments being put at the beginning of the message. The message-text follows the attachments. Isn't it a bit weird to put the appendix before the main text? Would you write a book and start with the appendix?

When looking at the specification, rfc2046 says for "multipart/mixed":

The "mixed" subtype of "multipart" is intended for use when the body parts are independent and need to be bundled in a particular order.

And for "multipart/alternative":

The multipart/alternative type is syntactically identical to multipart/mixed, but the semantics are different. In particular, each of the parts is an "alternative" version of the same information. [...] In general, the best choice is the LAST part of a type supported by the recipient system's local environment.

So to me it looks like Mail::Message always sorts the body parts of multipart-messages according to the ruleset for "multipart/alternative" using the MIME-Type. But reordering "multipart/mixed" has a strong impact on the interpretation of the message as the order of the body parts controls the order in which these parts are displayed in the mail reader. Body parts of disposition-type "attachment" should follow the primary message (disposition-type "inline") not precede it. At least I haven't seen a mail composer doing it differently except Mail::Message.

For example: If you opened the mail described above in Thunderbird, you would see the attached text files above the actual message in the message-frame (as long as you activated inline-display of known types of attachments). This looks wrong. But: This is a correct interpretation of the composition by Mail::Message as the body parts are bundled in a particular order so they should be be displayed serially.

[jeremy]

Great analysis. One approach: stop sorting parts entirely, except for content types (like multipart/alternative) that demand it.

[fernandomm]

I was also experiencing this issue in Mail 2.6.6 and it looks like it happens in Mail::PartsList.get_order_value method.

I've replaced it with something like this:

    def get_order_value(part, order)
      return 10_000 if part.respond_to?(:attachment?) && part.attachment?

      if part.respond_to?(:content_type) && !part[:content_type].nil?
        order.index(part[:content_type].string.downcase) || 10_000
      else
        10_000
      end
    end

Isn't it enough to fix this issue since it keeps all attachments at the end?

So far, I haven't experienced any side effects after applying this patch.