Email notifications incorrectly assign attachments into multipart/alternative

When sending email notifications along with attachments, the resulting multipart MIME structure is malformed. Attachments are included as an “alternative” part, rather than as a “mixed” part. As a result, some email clients, like Thunderbird, do not display these attachments because they’re interpreted as merely an alternative format of the email’s content, as with text vs HTML.

[Following quote is from an essentially identical bug report against Mailer which also relies on the Mail module.]

what i’m expecting the email to be structured like:

multipart/mixed
  multipart/alternative
    text/plain
    text/html
  application/pdf (i.e. in case of pdf attachment)

what i’m receiving:

multipart/alternative
  text/plain
  text/html
  application/pdf (i.e. in case of pdf attachment)

the practical effect:
thunderbird renders the right text body, depending on user preference (txt or html), but does not show the attachment as an attached file (it is however in the email source code as a bas63-encoded block) ios mail shows an empty email body, and only the pdf attachment as a file, since it is the last entry, and apparently the mail client then only renders this.

There are a handful of possibly-related bug reports against the Mail module Discourse relies on. Some of these reports are closed with an unstated implication that feeding the parts in a particular way solves the issue. I’m not sure which is the case here, but several of those reports are linked from the report I quoted and linked above.

8 Likes

Thanks for reporting this and for providing a clear description of the problem!

This should now be fixed as of https://github.com/discourse/discourse/commit/59578dfc5b9c7c445170b55614419362ba08a44b.

7 Likes

This topic was automatically closed after 4 days. New replies are no longer allowed.