+1 from our side as well. Another common scenario for us is mail server reputation: We use different providers for transactional and newsletter emails as well as different servers depending on the users plan (enterprise customers have a more reliable but more expensive mail server opposed to basic customers).
Matthias Kestenholz <m...@feinheit.ch> schrieb am So. 30. Jan. 2022 um 17:09: > Maybe we're doing something stupid or there's a misunderstanding but we > had a recent use case for this: The same website runs on several domains, > one domain per language and each domain has its own email address. We were > using an email relay (Mailgun in this case but the same will probably be > true for Sendgrid, SES etc.) with different authentication parameters for > each sender address. > > It wasn't that hard to instantiate one EmailBackend per domain/language > but it would definitely be nice if something like this was supported out of > the box. > > Best regards, > Matthias > > > > On Sun, Jan 30, 2022 at 4:39 PM Florian Apolloner <f.apollo...@gmail.com> > wrote: > >> I do not understand why you would need multiple email backends to send >> from different addresses. Can you elaborate on that? >> >> On Sunday, January 30, 2022 at 1:18:48 PM UTC+1 st...@jigsawtech.co.uk >> wrote: >> >>> I've a big +1 on changing email config to a dictionary to support >>> multiple backends as it's very much a common occurrence for both clients of >>> mine and for my own businesses. Most of the use cases are when they main >>> site sends emails from no-reply@ such as for password resets but then >>> when alternative email are required for sales and/or customer service email >>> address where it's handled via the website. Currently I end up creating a >>> custom settings.py dictionary to store the settings so I can then refer to >>> that using the connection for swapping the backend to send from. >>> >>> On Sunday, 30 January 2022 at 11:14:54 UTC f.apo...@gmail.com wrote: >>> >>>> Hi Jacob, >>>> >>>> I wouldn't be opposed to move email configuration into a dictionary >>>> (somewhere between -0 and +0). Although if we plan to do that we should >>>> rethink all the existing session variables and other as well I guess and >>>> figure out if we should move more settings to dictionaries. >>>> >>>> > why shouldn't it makes sense to have different email backends? If you >>>> have a staging system you may want to use you local SMTP-relay, while in >>>> production >>>> you may for instance use AWSs SES >>>> <https://docs.aws.amazon.com/ses/latest/dg/Welcome.html> service. >>>> >>>> This specific example at hand is imo not a good motivator to add >>>> support for multiple backends because the settings would imo be different. >>>> Take databases as an example: You also don't have staging/production in >>>> there but switch the actual values in the default database. >>>> >>>> > `EMAIL = [...]` >>>> >>>> I am not sure a list makes sense here and would go for similarity with >>>> CACHES & DATABASES since you'd usually identify the backend via a unique >>>> name or so. Also DATABASES & CACHES have an OPTIONS dict which is the >>>> passed on to the backend, I think we should follow suit here. >>>> >>>> > Personally, I would prefer SMTP = {...} >>>> >>>> I do not think SMTP would be a good fit because many services allow >>>> HTTP submission, so what we are sending is actually an email and smtp is >>>> just a protocol implementation in the backend of AWS SES or so. >>>> >>>> As for other email backends that do require different options: I do not >>>> see an issue when they simply take `EMAIL_AWS_SES_KEY` and document it as >>>> such; this doesn't require us to add more flexibility to email backends… >>>> >>>> So I guess it boils down to the following questions: >>>> >>>> * Do we want to support multiple (at the same time) email backends, if >>>> yes we would move to a settings dict anyways… >>>> * If the answer to the above is no, what value does putting it into a >>>> single dict give us? >>>> >>>> In the past I think I have argued for a SECURITY_HEADERS (or similar) >>>> dict because it allows us to check the dictionary keys easily for typos; >>>> emails probably don't suffer from that problem as badly as security related >>>> settings. >>>> >>>> I hope this can get the discussion going. >>>> >>>> Cheers, >>>> Florian >>>> On Sunday, January 30, 2022 at 9:29:27 AM UTC+1 jacob...@gmail.com >>>> wrote: >>>> >>>>> Well, that ticket is 8 years old and in the meantime other email >>>>> backends have emerged, requiring different configuration options. >>>>> I made this proposal after attempting to fix a 14 year old open ticket >>>>> #6989 but this was ultimately postponed, see comment by >>>>> Carlton Gibson on >>>>> https://github.com/django/django/pull/13728#issuecomment-987762791 >>>>> >>>>> To summarize the discussion from 7 years ago >>>>> >>>>> Collin Anderson wrote: >>>>> >>>>>> I don't see any benefit to moving email settings to a dictionary. It >>>>>> is helpful for databases and caches because there can be multiple >>>>>> backends. >>>>> >>>>> It makes the popular "from local_settings import *" convention harder >>>>>> to use. What's wrong with 6 individual settings? If the goal is to allow >>>>> >>>>> multiple email backends, then let's make that the ticket goal. >>>>> >>>>> >>>>> and Carl Meyer replied: >>>>> >>>>>> I agree with Collin; unless we are adding new capabilities (i.e. >>>>>> multiple configured email backends, which it seems nobody really wants), >>>>>> it's hard >>>>> >>>>> to find any actual benefit from this change to justify the churn (and >>>>>> the additional complexities of working with dictionary settings in >>>>>> partial-override scenarios). >>>>> >>>>> >>>>> why shouldn't it makes sense to have different email backends? If you >>>>> have a staging system you may want to use you local SMTP-relay, while in >>>>> production >>>>> you may for instance use AWSs SES >>>>> <https://docs.aws.amazon.com/ses/latest/dg/Welcome.html> service. >>>>> That service may require additional configuration settings not available >>>>> in >>>>> the local smtp backend. >>>>> I can also imagine that in some situations it may make sense to have >>>>> two email backends concurrently. We maybe should rethink about that. >>>>> >>>>> -- >> 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/aec69c4e-a7c2-4002-bb24-21ab11d89343n%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/aec69c4e-a7c2-4002-bb24-21ab11d89343n%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/CANvPqgDhevLyPGfXi6R0EgDxDb%2B-cCXOVgzVOX2xAyNDcPiUBQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CANvPqgDhevLyPGfXi6R0EgDxDb%2B-cCXOVgzVOX2xAyNDcPiUBQ%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/CAD%2BLtenvwiJctW_F5NUVmKvhvfXzc61GmYEpCE53LC2stpkCvg%40mail.gmail.com.
