[Inbound] Apple Mail inline attachments not taken into account about django-anymail HOT 5 CLOSED

Would you want some help to refactor?

Yes, please! If you want to open a PR with any or all of the above, that would be much appreciated.

from django-anymail.

Thanks for investigating, and for including a full raw email demonstrating the problem.

My initial reaction was, Apple Mail is doing something weird, so yeah, whatever workaround makes sense. But the more I investigated, Apple Mail's use of multipart/mixed to interleave text/plain and inline image parts is a valid approach. The inline images don't need content-ids, because they're not being referenced elsewhere, and multipart/mixed is defined to present its parts in sequential order. (See RFC 2046 section 5.1.3—and W3C's older version that clarifies multipart/mixed children are "intended to be displayed serially." Also RFC 2183 sections 2.1-2.2 which specify content-disposition.)

Arguably, Gmail is doing the wrong thing by presenting the inline images at the end of the message as attachments.

I think the bug here is that Anymail's inline_attachments doesn't include these inline images that don't have content-ids, even though they are inline content. (And in fact, it can't, because inline_attachments is actually a dict mapping content-id to MIMEPart.)

The underlying problem is that Anymail's inline_attachments dict doesn't parallel its attachments list, leading to understandable confusion. (Something similar came up in #229.) Also "inline attachment" isn't really a thing—a MIMEPart is either inline or an attachment (or neither), never both.

Proposal:

• Rename Anymail's inline_attachments to content_id_map (or cid_map?), reflecting what it actually implements. (Keep inline_attachments as a deprecated alias for content_id_map, issuing a warning on use.)
• Rename Anymail's is_inline_attachment() to is_inline(). (And keep the original as a deprecated alias.)
• Add a new inlines list property that returns a sequence of parts that are inline (paralleling the behavior of attachments).
• Derive AnymailInboundMessage from Python's email.message.EmailMessage, rather than email.message.Message. (Current implementation is a holdover from Python 2.7 support.) Since EmailMessage already implements is_attachment() (via MIMEPart), get rid of the AnymailInboundMessage version.

from django-anymail.

Thanks for the follow up @medmunds.

I was not sure what was the intended behaviour between displaying images inline or consider it as raw attachments, so thanks for clarifying this. 🙂

Your proposal works for me! Would you want some help to refactor?

from django-anymail.

@medmunds Here is a start #330 ;)

from django-anymail.

Resolved by #330.

from django-anymail.