Add configurable email sending for Klaxon add-on

[eyeseast]

This lets us send emails from no-reply@klaxoncloud.org (or something else, configurable). By default, it's a no-op.

We need to set KLAXON_ADDON_ID on Heroku for this to start working.

[duckduckgrayduck]

By default, emails sent through DocumentCloud get sent from mg.documentcloud.org which is the MAILGUN_DOMAIN for DocumentCloud. For emails not to get hit with DMARC issues (the domain we are sending would be mg.documentcloud.org while the email address is from klaxoncloud.org), it will need to go through the KLAXON_MAILGUN_DOMAIN, which needs to be specified in environment variables. We also need to add a mechanism for emails to be sent thru a domain we specify, with the default being the default MAILGUN_DOMAIN

[mitchelljkotler]

By default, emails sent through DocumentCloud get sent from mg.documentcloud.org which is the MAILGUN_DOMAIN for DocumentCloud. For emails not to get hit with DMARC issues (the domain we are sending would be mg.documentcloud.org while the email address is from klaxoncloud.org), it will need to go through the KLAXON_MAILGUN_DOMAIN, which needs to be specified in environment variables. We also need to add a mechanism for emails to be sent thru a domain we specify, with the default being the default MAILGUN_DOMAIN

https://anymail.dev/en/stable/esps/mailgun/#email-sender-domain

This is the documentation for overriding the sender domain for sending an individual email.

Also, do we want the email template to be more customized then just changing the name from DocumentCloud to Klaxon?

[eyeseast]

I added the email domain override. All of the email content is set in the Add-On, so I think we can do any other customization we want there.

[mitchelljkotler]

The code looks good to me, @allanlasser do you think we need a different base template for Klaxon emails?

[duckduckgrayduck]

This overrides the envelope and by proxy the sending domain to klaxoncloud.org. The sending domain I initially had set up was mg.klaxoncloud.org (a subdomain, for reputation purposes in case we send other kinds of emails from klaxoncloud.org later). As is currently written, the envelope_sender = from_email = no-reply@klaxoncloud.org so Anymail would try to use klaxoncloud.org as the sender domain.

I tore down mg.klaxoncloud.org and setup klaxoncloud.org domain in mailgun to align with this current behavior to prevent failed email sends, but I needed to document this here.

If we wanted the email to show that it was coming from no-reply@klaxoncloud.org but actually use mg.klaxoncloud.org as the sender domain for reputation, we would need to split the from_email from the envelope_sender

[eyeseast]

@duckduckgrayduck Is one way or the other preferred? Setting the envelope looked like the right way to handle this in Anymail, since the sending domain is set site-wide.

[duckduckgrayduck]

Let's untangle this. As the code is currently written, overwriting the envelope uses from_email, which in this case is no-reply@klaxoncloud.org. Anymail uses the envelope to determine the sending domain to use. In this case, that would be klaxoncloud.org.

If we wanted to use mg.klaxoncloud.org as the sending domain (for reputation purposes) we would need to divorce these two- from_email can be one thing (no-reply@klaxoncloud.org) while the envelope is different (no-reply@mg.klaxoncloud.org).

The way you overrode the global sending domain (DocumentCloud's) via envelope is the correct, documented method. The issue is that as is currently written, anymail sees self.envelope_sender = from_email, which we have set to no-reply@klaxoncloud.org so Anymail derives the sender_domain to be klaxoncloud.org.

I've set up the root klaxoncloud.org domain now so this will work as is if we merge the code now. However, if we wanted to divorce the two so that it uses mg.klaxoncloud.org for reputation purposes, this would require some modification to the existing code.

I updated my prior comment to better reflect this too.

[duckduckgrayduck]

I should also note that unless we expect to ever send any kind of other types of emails from klaxoncloud.org that we want to keep the reputation separate for, using the root domain is fine and we can merge as is.

[eyeseast]

OK, I get it now. Thanks for bearing with me.

I expect the only emails we're sending from this domain are alert emails. Maybe we'd send other automated messages, but I think anything hand-written would come from muckrock.com.

If we did want to send with a domain of mg.klaxoncloud.org instead of klaxoncloud.org, we'd have to find a way to signal that, specific to that domain. Or we'd have to special-case mg subdomains. Either way, I think it adds complexity we don't need right now.

So I think we're all saying this is ok as-is.

[allanlasser]

It'd be nice to have some unique templates for DocumentCloud and Klaxon with logos etc., but just using the dynamic from_name is totally sufficient for now.

@duckduckgrayduck Editing the subject line or body template happens in the the add-on code, correct?

[duckduckgrayduck]

For the alert emails, Klaxon calls send_mail which is defined on the AddOn class in python-documentcloud/

In turn this posts to path("api/messages/", MessageView.as_view(), name="message-create") defined in urls.py on DocumentCloud which is handled by the MessageView set in users/views.py

documentcloud/documentcloud/users/views.py

Line 190 in 885b897

class MessageView(APIView):

The template there is the same for all Add-Ons- core/email/base.html. If we wanted to override that template for Klaxon or other Add-Ons, we would need to add code. It is probably more preferred to add a config.yaml parameter to tell the method to use a different template specified in the code base rather than letting arbitrary template passing.

The disabled emails (if an Add-On is disabled after failing 5 or more times) are handled differently. That uses send_disabled_email

documentcloud/documentcloud/addons/models.py

Line 509 in 885b897

def send_disabled_email(self):

which uses one of two disabled templates depending on if the Add-On has custom_disabled_email_footer set in it's config.yaml.

[allanlasser]

Sorry, inaccurate wording in my question. I was wondering if editing the language in the emails Klaxon sends has to happen in the add-on repo—Sanjin confirmed that it does.