After my comment in the steering council vote and in-person conversation with Jake, I believe the SMTP backend will not be implemented for DEP 14 : https://forum.djangoproject.com/t/steering-council-vote-on-background-tasks-dep-14/31131/20
On Tue, 25 Jun 2024, at 10:27, Arthur Pemberton wrote: > > The background workers proposal will implement a new background SMTP > > EmailBackend (in django.core.mail.backends). > > I had missed that fact. Thanks for the explanation. > > I for one think that this is a good proposal -- this would modern > transactional email sending. > > - Arthur > > > On Mon, Jun 24, 2024 at 3:14 PM Mike Edmunds <medmu...@gmail.com> wrote: >> > Would this be designed to be compatible with "Proposal 14: Background >> > Workers"? >> >> I wouldn't expect this to impact background workers one way or the other. >> The same goes for the async email proposal(s) floating around. >> >> Virtually all of this work would occur in django.core.mail.message, where >> Python's `email` APIs are used. A goal is to avoid changes that would break >> existing email backends (Django or third-party). >> >> The background workers proposal will implement a new background SMTP >> EmailBackend (in django.core.mail.backends). The existing SMTP EmailBackend >> doesn't directly use Python's `email` APIs, and there should be no reason >> for background SMTP to be any different. (It might be helpful to know that >> Python's `email` library isn't involved in *sending* email; that's handled >> by Python's `smtplib`, which Django uses only in the SMTP EmailBackend.) >> >> The existing SMTP EmailBackend *does* use one function I expect will become >> deprecated: django.core.mail.message.sanitize_address(). I haven't yet >> investigated whether that use is still necessary, or whether it's there to >> get around past bugs/limitations in Python's smtplib. If any of it is still >> needed for SMTP, I'd probably want to move that code into the SMTP >> EmailBackend(s). >> >> - Mike >> On Sunday, June 23, 2024 at 10:22:03 PM UTC-7 Arthur Pemberton wrote: >>> Would this be designed to be compatible with "Proposal 14: Background >>> Workers"? >>> >>> >>> >>> >>> On Sun, Jun 23, 2024 at 10:46 PM Mike Edmunds <medm...@gmail.com> wrote: >>>> I want to propose updating django.core.mail to replace use of Python's >>>> legacy email.message.Message (and other legacy email APIs) with >>>> email.message.EmailMessage (and other modern APIs). >>>> >>>> If there's interest, I can put together a more detailed proposal and/or >>>> ticket, but was hoping to get some initial feedback first. (I searched for >>>> relevant discussions in django-developers and the issue tracker, and >>>> didn't find any. Apologies if this has come up before.) >>>> >>>> [Note: I maintain django-anymail >>>> <https://github.com/anymail/django-anymail>, which implements Django >>>> integration with several transactional email service providers.] >>>> >>>> >>>> >>>> *Background* >>>> >>>> Since Python ~3.6, Python's email package has included two largely >>>> separate implementations: >>>> >>>> • a "modern (unicode friendly) API" based on email.message.EmailMessage >>>> and email.policy.default >>>> • a "legacy API" providing compatibility with older Python versions, >>>> based on email.message.Message and email.policy.compat32 >>>> (See https://docs.python.org/3/library/email.html, especially toward the >>>> end.) >>>> >>>> django.core.mail currently uses the legacy API. >>>> >>>> >>>> >>>> *Why switch?* >>>> >>>> There are no plans to deprecate Python's legacy email API, and it's >>>> working, so why change Django? >>>> >>>> • *Fewer bugs:* The modern API fixes a *lot* of bugs in the legacy API. >>>> My understanding is legacy bugs will generally not be fixed. (And in fact, >>>> there are some cases where the legacy API deliberately replicates earlier >>>> buggy behavior.) >>>> >>>> Django #35497 <https://code.djangoproject.com/ticket/35497> is an example >>>> of a legacy bug (with a problematic proposed workaround) which is just >>>> fixed in the modern API. >>>> >>>> • *Simpler, safer code:* A substantial portion >>>> <https://github.com/django/django/blob/stable/5.1.x/django/core/mail/message.py#L32-L190> >>>> of django.core.mail's internals implements workarounds and security fixes >>>> for problems in the legacy API. This would be greatly simplified—maybe >>>> eliminated completely—using the modern API. >>>> >>>> Examples: the modern API prevents CR/NL injections in message headers. It >>>> serializes and folds address headers properly—even ones with unicode >>>> names. It enforces single-instance headers where appropriate. >>>> >>>> • *Easier to work with:* The modern API adds some nice conveniences for >>>> developers working in django.core.mail, third-party library developers, >>>> and (depending on what we choose to expose) users of Django's mail APIs. >>>> >>>> Examples: populating the "Date" header with a datetime or an address >>>> header with Address >>>> <https://docs.python.org/3/library/email.headerregistry.html#email.headerregistry.Address> >>>> objects—without needing intricate knowledge of email header formats. >>>> Using email.policy to generate a 7-bit clean serialization (without having >>>> to muck about with the MIME parts >>>> <https://github.com/anymail/django-anymail/blob/v11.0/anymail/backends/amazon_ses.py#L168-L179>). >>>> >>>> ** >>>> >>>> *Concerns & risks* >>>> >>>> Compatibility and security, of course… >>>> >>>> • *Backwards compatibility (for API users):* django.core.mail largely >>>> insulates callers from the underlying Python email package. There are a >>>> few places where this leaks (e.g., attachments >>>> <https://docs.djangoproject.com/en/5.0/topics/email/#django.core.mail.EmailMessage:~:text=send()%20is%20called.-,attachments,-%3A%20A%20list%20of> >>>> allows legacy email MIMEBase >>>> <https://docs.python.org/3/library/email.mime.html> objects), but in >>>> general the switch should be transparent. (And I have some ideas for >>>> supporting the other cases.) >>>> >>>> • *Backwards compatibility (for third-party libraries):* Some libraries >>>> may use internals I'd propose removing (e.g., SafeMIME and friends); we'd >>>> handle this through deprecation. >>>> >>>> • *Backwards compatibility (bug-level):* There's probably some code out >>>> there that unintentionally depends on legacy email bugs (or the specific >>>> ways Django works around them). I don't have any examples, but I also >>>> don't have a good solution for when they surface. Plus, while Python's >>>> modern email API is pretty mature at this point, there are still new bugs >>>> being reported against it. Email is complicated. >>>> >>>> • *Security:* As noted above, the modern API should be more secure than >>>> the legacy one. But we also have a nice collection of email security >>>> tests—which *mostly* don't depend on internal implementation. We'd keep >>>> these. >>>> >>>> >>>> >>>> -- >>>> 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-develop...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/f410ad79-a034-4275-88a7-22e7626c06fdn%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/django-developers/f410ad79-a034-4275-88a7-22e7626c06fdn%40googlegroups.com?utm_medium=email&utm_source=footer>. >> >> >> -- >> 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/8f4716b9-0856-46bd-af16-0ce715f195b2n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/django-developers/8f4716b9-0856-46bd-af16-0ce715f195b2n%40googlegroups.com?utm_medium=email&utm_source=footer>. > > > -- > 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/CA%2BX4dQSCwndDFcOid0Lyi4PtUJw264DTZK-r6vSNNoRh%2B4gBTQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/django-developers/CA%2BX4dQSCwndDFcOid0Lyi4PtUJw264DTZK-r6vSNNoRh%2B4gBTQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/bd7ea5b8-f145-49ee-b99a-6cd0200c8c87%40app.fastmail.com.
