About MIMEBase attachments: I propose we continue supporting them in Django, without deprecation, for now. We can investigate adding support for the equivalent in Python's modern email API later, as a separate proposal.
More details… On Wednesday, June 26, 2024 at 6:28:06 PM UTC-7 I wrote: > Tricky bits and things requiring longer discussion… > *Legacy MIMEBase attachments:* I'll post a separate message about this sometime later. Since 2007 <https://github.com/django/django/commit/2d082a34dc61a832710d98a933858fd2c0059644#diff-4e0b18b71ced270db41c958dac831e975b67548d378d09e31605179b04e8dc36R195-R196>, Django has supported and documented <https://docs.djangoproject.com/en/5.0/topics/email/#django.core.mail.EmailMessage:~:text=These%20can%20be%20either%20MIMEBase%20instances,%20or%20(filename,%20content,%20mimetype)%20triples.> using MIMEBase objects in Django's EmailMessage.attachments list. Using MIMEBase is necessary for any "complex attachment" that can't be simply expressed as filename + content data + mimetype. This includes things like text attachments with a different charset than the main message, inline images (which require Content-Disposition: inline and Content-ID MIME headers), adding params to the Content-Type header, or in general anything where you need additional control over the attachment's MIME headers and content encoding. MIMEBase is part of Python's legacy <https://docs.python.org/3/library/email.mime.html#module-email.mime> email API. The modern email replacement is add_attachment() <https://docs.python.org/3/library/email.message.html#email.message.EmailMessage.add_attachment>, which offers everything we need for simple attachments. It also supports complex attachments via "contentmanager" kwargs <https://docs.python.org/3/library/email.contentmanager.html#email.contentmanager.set_content> like `disposition` for the Content-Disposition header, `cid` for Content-ID, and `params` for Content-Type extensions. But add_attachment() doesn't support MIMEBase. So as part of this proposal, we'll handle simple filename+content+mimetype attachments through modern add_attachment(). I had originally planned to treat MIMEBase attachments as deprecated, and find a way to convert them to modern add_attachment() kwargs. And I was going to propose a way to somehow include add_attachment() kwargs directly in Django's EmailMessage.attachments, as the non-deprecated way to specify complex attachments. I still think this is the right long-term direction. But in the interests of limiting scope for the current proposal, I think we can treat that as a separate project, and just continue to support MIMEBase attachments for now: - From what I can tell, it's still possible to attach legacy MIMEBase objects to a modern Python EmailMessage, and get results that work at least as well as they did with entirely legacy APIs. - You can also opt into the modern API when creating a MIMEBase object, by passing policy=email.policy.default to its constructor. This might avoid some obscure bugs that occur with the legacy APIs. I think Django's docs should suggest this approach "for improved compatibility" or something like that. - When the time comes to support complex Django EmailMessage.attachments using Python's modern add_attachment() kwargs, I think we should also look into supporting Python EmailMessage's add_related() <https://docs.python.org/3/library/email.message.html#email.message.EmailMessage.add_related>. Right now, there's no way to get Django to send a properly constructed <https://docs.python.org/3/library/email.examples.html#:~:text=Here%E2%80%99s%20an%20example%20of%20how%20to%20create%20an%20HTML%20message%20with%20an%20alternative%20plain%20text%20version.%20To%20make%20things%20a%20bit%20more%20interesting,%20we%20include%20a%20related%20image%20in%20the%20html%20part> multipart message with html, inline images, and attachments: the inline images end up in the wrong part. Most email clients aren't that picky, and display the inlines anyway (if they handle inline images at all), but it would be helpful to have a way to generate the correct message structure. Just… later. - Mike -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9aa610dd-01de-4f98-bcfa-f982872ebdban%40googlegroups.com.
