Re: Proposal on how add configuration options to Email Backends

[Florian Apolloner]

Okay then,

some of the things like sender reputation and different bounce hooks came 
to my mind as well, but it is good to hear confirmation from others. I 
think the next steps would be to create a new ticket to add support for 
*multiple* email backends and then work from that (I would only link the 
old ticket since it's scope was mainly putting the config into a dict as 
opposed to multiple backends). Given that there are plenty of +1 here 
already I think we already have our implementors? :)

Some items that I like to see addressed in a PR:
 * Backwards compat
 * Similarity to Caches & Databases (ie so we don't invent yet another 
syntax)
 * Support for connection aliases (default/…) in send_email % friends 
(basically everything taking a connection now should probably take aliases 
as well)

Cheers,
Florian

On Sunday, January 30, 2022 at 11:07:56 PM UTC+1 Adam Johnson wrote:

> Another situation you might want multiple backends is when switching 
> providers. Rather than big-bang swap *all* email sends to a new provider, 
> you might want to move only low-value emails first, or a percentage of your 
> user base, and iterate.
>
> On Sun, 30 Jan 2022 at 20:59, Steven Mapes  wrote:
>
>> I should add I also have other instances my clients use a custom AWS SES 
>> backend I wrote used for various types of sends (bulk, newsletters) but 
>> generally sends where they need SNS notifications to trigger HTTPS 
>> postbacks for certain results from the send such as bounced mails, spam 
>> reports etc where those the requests go back to the django server to be 
>> handled whereas other mail sends may go via O365 / Google for general, 
>> often internal, notifications and emails send.
>>
>> I have another client who has two mail providers where one is the primary 
>> and if that fails due to the SMTP server being down, the platform othen 
>> fails over to re-send via the backup SMTP server.
>>
>> *Steve Mapes*
>> Steven Mapes T/A Jigsaw Tech
>> E: st...@jigsawtech.co.uk 
>> 
>> P: +44(0)7974220046
>> W: https://www.jigsawtech.co.uk/ 
>> 
>> [image: LinkedIn] 
>> [image:
>>  
>> Twitter] 
>> 
>> The entire content of this email message is confidential. This also 
>> applies to any files attached to it. This email is intended for an 
>> individual or entity to whom they are addressed. In case you are not the 
>> addressee of this email, and you have received it in error, contact the 
>> system manager immediately. The information could be very sensitive, and it 
>> is intended for the specific addressee. This email should not be 
>> disseminated, distributed or copied. If you have received this email and it 
>> was not for you, please notify the sender by email immediately and 
>> afterward delete this email from your system. Disclosing, copying, 
>> distributing, or taking any action in reliance on the email content is 
>> strictly prohibited.
>> On Jan 30 2022, at 3:38 pm, Florian Apolloner  wrote:
>>
>> I do not understand why you would need multiple email backends to send 
>> from different addresses. Can you elaborate on that?
>>
>> [image: Sent from Mailspring]
>> 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 

Re: Fellow Reports - January 2022

[Mariusz Felisiak]

Week ending January 30, 2022 

*Triaged: *
   https://code.djangoproject.com/ticket/33459 - Explain how to optimize 
full text search with SearchVectorField and GinIndex (wontfix) 
   https://code.djangoproject.com/ticket/33460 - Change SQLite backend to 
generate INSERT statements using VALUES instead of UNION. (accepted) 
   https://code.djangoproject.com/ticket/30209 - Union with group by don't 
generate correct Subquery (duplicate) 
   https://code.djangoproject.com/ticket/29482 - simplify KeyTransform to 
always use the 'nested_operator' (wontfix) 
   https://code.djangoproject.com/ticket/33463 - bulk_update() does not 
work with plain F('...') expressions. (accepted) 
   https://code.djangoproject.com/ticket/33464 - Django db expressions 
doesn't combine MOD (duplicate) 
   https://code.djangoproject.com/ticket/33465 - Introduce empty __slots__ 
protocol for SafeString & SafeData (accepted) 
   https://code.djangoproject.com/ticket/33466 - Specify the order of 
columns in the table. (invalid) 
   https://code.djangoproject.com/ticket/33467 - Small Framework to create 
Demo-Systems (wontfix) 
   https://code.djangoproject.com/ticket/33468 - aggregate() with 'default' 
after annotate() crashes. (accepted) 
   https://code.djangoproject.com/ticket/28949 - Multibyte table name or 
column name causes miscalculation of the length of index name. (wontfix) 
   https://code.djangoproject.com/ticket/33472 - slugify() don't work when 
used in model's save() method. (worksforme) 

*Reviewed/committed: *
   https://github.com/django/django/pull/15347 - Fixed #33458 -- Fixed 
encoding of messages with empty string as extra_tags. 
   https://github.com/django/django/pull/15348 - Fixed #33457 -- Fixed 
"Local vars" scrolling in technical 500 debug page. 
   https://github.com/django/django/pull/15354 - Fixed #33460 -- Used 
VALUES clause for insert in bulk on SQLite. 
   https://github.com/django/django/pull/15334 - Fixed #29984 -- Added 
QuerySet.iterator() support for prefetching related objects. 
   https://github.com/django/django/pull/15203 - Refs #20349 -- Avoided 
loading testing libraries when not needed. 
   https://github.com/django/django/pull/15159 - Fixed #33048 -- Doc'd that 
DEBUG static files requests don't use middleware chain. 
   https://github.com/django/django/pull/15355 - Used GitHub actions for 
Windows tests. 
   https://github.com/django/django/pull/15362 - Adjusted CBV 
resolver_match example in testing tools docs. 
   https://github.com/django/django/pull/15368 - Fixed #33463 -- Fixed 
QuerySet.bulk_update() with F() expressions. 
   https://github.com/django/django/pull/14725 - Fixed #26142 -- Allowed 
model formsets to prevent new object creation. 
   https://github.com/django/django/pull/15371 - Fixed #33459 -- Clarified 
index type in full text search docs. 
   https://github.com/django/django/pull/15361 - Fixed #33461 -- Escaped 
template errors in the technical 500 debug page. 
   https://github.com/django/django/pull/15370 - Fixed #33465 -- Added 
empty __slots__ to SafeString and SafeData. 
   https://github.com/django/django/pull/15376 - [4.0.x] Updated 
translations from Transifex. 

*Reviewed: *
   https://github.com/django/django/pull/15333 - Fixed #33407 -- Fixed 
.radiolist admin CSS. 

*Authored: *
   https://github.com/django/django/pull/15351 - Fixed wrapping of long 
values in technical 500 debug page. 
   https://github.com/django/django/pull/15359 - Fixed wrapping of long 
messages in the admin. 
   https://github.com/django/django/pull/15360 - Increased test coverage 
for django.contrib.gis.gdal.layer.Layer. 
   https://github.com/django/django/pull/15364 - Fixed #33462 -- Fixed 
migration crash when altering type of primary key with MTI and foreign key. 
   https://github.com/django/django/pull/15373 - Fixed #33452 -- Fixed 
admin change-form layout for submit buttons on mid-sized displays. 
   https://github.com/django/django/pull/15375 - Fixed #33468 -- Fixed 
QuerySet.aggregate() after annotate() crash on aggregates with default.

Best,
Mariusz

-- 
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/3c41fb47-8572-4a3f-8603-608d2c6126f6n%40googlegroups.com.

Re: Fellow Reports - January 2022

[Mariusz Felisiak]

Week ending January 23, 2022 

*Triaged: *
   https://code.djangoproject.com/ticket/33444 - Add an option with default 
answer for makemigrations questions. (wontfix) 
   https://code.djangoproject.com/ticket/33443 - Conditions when 
PasswordResetView sends email should be listed more clearly (accepted) 
   https://code.djangoproject.com/ticket/33445 - MultiWidget doesn't call 
subwidgets' render() methods. (needsinfo) 
   https://code.djangoproject.com/ticket/23816 - Ability to defer model 
field by default (wontfix) 
   https://code.djangoproject.com/ticket/33446 - ManifestStaticFilesStorage 
doesn't update CSS source map references (accepted) 
   https://code.djangoproject.com/ticket/33448 - timezone difference causes 
problem with admin panel time (needsinfo) 
   https://code.djangoproject.com/ticket/33449 - Migration autodetector 
crashes on models with field named _order, but not using 
order_with_respect_to. (accepted) 
   https://code.djangoproject.com/ticket/33451 - queryset_object.query 
results does not add quotes around string values (duplicate) 
   https://code.djangoproject.com/ticket/33452 - Save buttons in admin are 
too close together on medium screen sizes (accepted) 
   https://code.djangoproject.com/ticket/33450 - Integer primary key is 
wrongly casted to UUID when filtering GenericRelation on model with UUID 
primary key. (accepted) 
   https://code.djangoproject.com/ticket/33453 - Drop support for GDAL 2.1. 
(created) 
   https://code.djangoproject.com/ticket/33455 - Missleading error message 
when running selenium tests without selenium. (accepted) 
   https://code.djangoproject.com/ticket/33456 - Make underscore in 
hostname error more explicit (wontfix) 
   https://code.djangoproject.com/ticket/33454 - Django4 does not pick up 
tests according to tags. (invalid) 
   https://code.djangoproject.com/ticket/32088 - Django Database Sessions - 
Can't Retrieve expire_date from request.session (SessionStore) (wontfix) 
   https://code.djangoproject.com/ticket/33458 - Messages framework 
incorrectly serializes/deserializes extra_tags when it's an empty string 
(accepted) 
   https://code.djangoproject.com/ticket/33457 - Expanding local vars in 
technical 500 causes horizontal scrolling (accepted) 

*Reviewed/committed: *
   https://github.com/django/django/pull/14847 - Fixed #33443 -- Clarified 
when PasswordResetView sends an email. 
   https://github.com/django/django/pull/15320 - Fixed #33435 -- Fixed 
invalid SQL generatered by Subquery.as_sql(). 
   https://github.com/django/django/pull/15329 - Fixed #33446 -- Added CSS 
source map support to ManifestStaticFilesStorage. 
   https://github.com/django/django/pull/15325 - Updated GEOS/GDAL links in 
docs and comments. 
   https://github.com/django/django/pull/13065 - Fixed #31685 -- Added 
support for updating conflicts to QuerySet.bulk_create(). 
   https://github.com/django/django/pull/15324 - Fixed #33062 -- Made 
MultiPartParser remove non-printable chars from file names. 
   https://github.com/django/django/pull/15335 - Improved wording in 
running Django’s test suite in contributing tutorial. 
   https://github.com/django/django/pull/15339 - Fixed #33449 -- Fixed 
makemigrations crash on models without Meta.order_with_respect_to but with 
_order field. 
   https://github.com/django/django/pull/15240 - Fixed #26760 -- Added 
--prune option to migrate command. 
   https://github.com/django/django/pull/15338 - Fixed #33455 -- Improved 
error message when selenium is not installed. 

*Reviewed: *
   https://github.com/django/django/pull/15344 - Stopped including 
type="text/css" attributes for CSS link tags. 

*Authored: *
   https://github.com/django/django/pull/11692 - Fixed #29338 -- Allowed 
using combined queryset in Subquery. 
   https://github.com/django/django/pull/15332 - Added tests for 
SpatialReference.to_esri()/from_esri(). 
   https://github.com/django/django/pull/15337 - Fixed #33453 -- Dropped 
support for GDAL 2.1. 

Best,
Mariusz

-- 
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/4964cc58-ded6-4f0c-a0ba-9d34a6be09ban%40googlegroups.com.

Re: Preparing Django code for the Black stable release

[Mariusz Felisiak]

Thanks. We will work on it later this week.

-- 
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/fa88d938-fc24-488c-9fc8-ce4aa9e5ae54n%40googlegroups.com.

Re: Proposal on how add configuration options to Email Backends

['Adam Johnson' via Django developers (Contributions to Django itself)]

Another situation you might want multiple backends is when switching
providers. Rather than big-bang swap *all* email sends to a new provider,
you might want to move only low-value emails first, or a percentage of your
user base, and iterate.

On Sun, 30 Jan 2022 at 20:59, Steven Mapes  wrote:

> I should add I also have other instances my clients use a custom AWS SES
> backend I wrote used for various types of sends (bulk, newsletters) but
> generally sends where they need SNS notifications to trigger HTTPS
> postbacks for certain results from the send such as bounced mails, spam
> reports etc where those the requests go back to the django server to be
> handled whereas other mail sends may go via O365 / Google for general,
> often internal, notifications and emails send.
>
> I have another client who has two mail providers where one is the primary
> and if that fails due to the SMTP server being down, the platform othen
> fails over to re-send via the backup SMTP server.
>
> *Steve Mapes*
> Steven Mapes T/A Jigsaw Tech
> E: st...@jigsawtech.co.uk
> 
> P: +44(0)7974220046
> W: https://www.jigsawtech.co.uk/
> 
> [image: LinkedIn]
> [image:
> Twitter]
> 
> The entire content of this email message is confidential. This also
> applies to any files attached to it. This email is intended for an
> individual or entity to whom they are addressed. In case you are not the
> addressee of this email, and you have received it in error, contact the
> system manager immediately. The information could be very sensitive, and it
> is intended for the specific addressee. This email should not be
> disseminated, distributed or copied. If you have received this email and it
> was not for you, please notify the sender by email immediately and
> afterward delete this email from your system. Disclosing, copying,
> distributing, or taking any action in reliance on the email content is
> strictly prohibited.
> On Jan 30 2022, at 3:38 pm, Florian Apolloner 
> wrote:
>
> I do not understand why you would need multiple email backends to send
> from different addresses. Can you elaborate on that?
>
> [image: Sent from Mailspring]
> 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
>  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 

Re: Proposal on how add configuration options to Email Backends

[Steven Mapes]

I should add I also have other instances my clients use a custom AWS SES 
backend I wrote used for various types of sends (bulk, newsletters) but 
generally sends where they need SNS notifications to trigger HTTPS postbacks 
for certain results from the send such as bounced mails, spam reports etc where 
those the requests go back to the django server to be handled whereas other 
mail sends may go via O365 / Google for general, often internal, notifications 
and emails send.

I have another client who has two mail providers where one is the primary and 
if that fails due to the SMTP server being down, the platform othen fails over 
to re-send via the backup SMTP server.
Steve Mapes
Steven Mapes T/A Jigsaw Tech

E: st...@jigsawtech.co.uk 
(https://link.getmailspring.com/link/cf847694-1156-4ba3-bc92-5f42d434b...@getmailspring.com/0?redirect=mailto%3Asteve%40jigsawtech.co.uk=ZGphbmdvLWRldmVsb3BlcnNAZ29vZ2xlZ3JvdXBzLmNvbQ%3D%3D)
P: +44(0)7974220046 (tel:+44(0)7974220046)
W: https://www.jigsawtech.co.uk/ 
(https://link.getmailspring.com/link/cf847694-1156-4ba3-bc92-5f42d434b...@getmailspring.com/1?redirect=https%3A%2F%2Fwww.jigsawtech.co.uk%2F=ZGphbmdvLWRldmVsb3BlcnNAZ29vZ2xlZ3JvdXBzLmNvbQ%3D%3D)

The entire content of this email message is confidential. This also applies to 
any files attached to it. This email is intended for an individual or entity to 
whom they are addressed. In case you are not the addressee of this email, and 
you have received it in error, contact the system manager immediately. The 
information could be very sensitive, and it is intended for the specific 
addressee. This email should not be disseminated, distributed or copied. If you 
have received this email and it was not for you, please notify the sender by 
email immediately and afterward delete this email from your system. Disclosing, 
copying, distributing, or taking any action in reliance on the email content is 
strictly prohibited.

On Jan 30 2022, at 3:38 pm, Florian Apolloner  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 

Re: Proposal on how add configuration options to Email Backends

[Steven Mapes]

I have clients that use different mailboxes sometimes with totally different 
providers (O365, Google, their own mailservers) so they need different SMTP 
settings. In some cases they also read from the mailboxes, granted this isn't 
from Django builtin functionality but in those cases it uses the same 
credentials.

Steve Mapes
Steven Mapes T/A Jigsaw Tech

E: st...@jigsawtech.co.uk 
(https://link.getmailspring.com/link/e32a2c46-7b3e-441e-ab1b-879d066cf...@getmailspring.com/0?redirect=mailto%3Asteve%40jigsawtech.co.uk=ZGphbmdvLWRldmVsb3BlcnNAZ29vZ2xlZ3JvdXBzLmNvbQ%3D%3D)
P: +44(0)7974220046 (tel:+44(0)7974220046)
W: https://www.jigsawtech.co.uk/ 
(https://link.getmailspring.com/link/e32a2c46-7b3e-441e-ab1b-879d066cf...@getmailspring.com/1?redirect=https%3A%2F%2Fwww.jigsawtech.co.uk%2F=ZGphbmdvLWRldmVsb3BlcnNAZ29vZ2xlZ3JvdXBzLmNvbQ%3D%3D)

The entire content of this email message is confidential. This also applies to 
any files attached to it. This email is intended for an individual or entity to 
whom they are addressed. In case you are not the addressee of this email, and 
you have received it in error, contact the system manager immediately. The 
information could be very sensitive, and it is intended for the specific 
addressee. This email should not be disseminated, distributed or copied. If you 
have received this email and it was not for you, please notify the sender by 
email immediately and afterward delete this email from your system. Disclosing, 
copying, distributing, or taking any action in reliance on the email content is 
strictly prohibited.

On Jan 30 2022, at 3:38 pm, Florian Apolloner  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
> > >
> 

Re: Proposal on how add configuration options to Email Backends

[Alexander Schulze]

+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  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 
> 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
  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 

Re: Proposal on how add configuration options to Email Backends

[Matthias Kestenholz]

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 
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
>>>  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),
> 

Re: Proposal on how add configuration options to Email Backends

[Florian Apolloner]

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 
>>  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 
>>>  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 

Re: Proposal on how add configuration options to Email Backends

[st...@jigsawtech.co.uk]

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 
>  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 
>>  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.

Re: Proposal on how add configuration options to Email Backends

[Florian Apolloner]

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 
 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 
>  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/27c2ed9d-92f4-49e3-b770-a74e37cff368n%40googlegroups.com.

Re: Proposal on how add configuration options to Email Backends

[Jacob Rief]

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 
 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/bcbd308a-217c-44eb-b96a-3a487683a345n%40googlegroups.com.