SMTP Driver does not offer text/html multipart as preferred content for MIME enabled email clients

[chris-fewtrell]

Branch/Environment/Version

• master

Describe the bug
Emails send out using SMTP backend result in a non ideal arrangement where the text/plain version of content is preferred over the HTML.

Reproduction steps

1. Setup Dashboard with SMTP backend with email notifications enabled
2. Trigger Email event (signup new developer or similar)
3. Mail produced will have mime parts of text/html content followed by text/plain content.

Actual behaviour
Clients that accept and handle MIME Multi-parts are processing the them and displaying the last one included that it can process accepting it as the preferred, in this case it is the text/plain multi-part, even if client is text/html capable.

Expected behaviour
text/html mail body should be attached as a multi-part after the text/plain, ensuring any html enabled client will prefer that over the text/plain content (as implied by ordering) The body perhaps should be text/plain as well to ensure non-MIME clients will get suitable content.

Additional context
Taken from RFC2064

In general, user agents that compose "multipart/alternative" entities must place the body parts in increasing order of preference, that is, with the preferred format last. For fancy text, the sending user agent should put the plainest format first and the richest format last.

This was drawn from ticket 5370