Discourse Priority Action Mailer Plugin

Repo: Discourse Priority Action Mailer Plugin

What Does This Plugin Do?

This plugin adds two new SMTP "channels" in addition to the standard Discourse default SMTP channel. One channel is for "high priority" emails; which are (subjectively) notifications emails when a user requests to login via email, signs up, or requests a password reset. The other channel is for digests (summary) email. If either of these new SMTP channels are not configured (more on that later), the new channels will default to the standard Discourse SMTP channel.

Why Should Anyone Care or Install this Plugin?

Having one SMTP channel where the "high priority" emails to users such as login by email requests in the same SMTP channel as the digests (for example) creates a potential "availability"Footnote 1 problem, especially if the default SMTP channel has limits set.

We experienced this issue directly when we first migrated to Discourse from our legacy forum and we used a Google Workspace account (formerly known as G Suite). Because Google limits this account, that particular email account was "locked" for a few days. That was not really a serious problem because we just created another account and turned off digests; but for a short while, members were not able to login by email or signup.

My experience in cybersecurity and system engineering in general noted this single email channel as a "single point of failure" and so I made a note to fix this; and this plugin does fix this by moving all digest email to a different SMTP channel.

Actually, it is quite easy to do this as you can see from how simple this plugin code is.

How Do You Install this Plugin?

It is simple to install this plugin.

  • Install the plugin just like you would install any Discourse plugin.
  • Define your additional SMTP credentials in your container building files (your .yml file(s))

The following additional Discourse container environment vars are used, unless you want the default values. These SMTP environmental variable are basically the same as the Discourse default SMTP environmental variables with the _PRIORITY and _DIGEST added to each one:

PRIORITY CHANNEL ENVIRONMENTALS

env:
  DISCOURSE_SMTP_ADDRESS_PRIORITY:                     
  DISCOURSE_SMTP_PORT_PRIORITY: 
  DISCOURSE_SMTP_USER_NAME_PRIORITY: 
  DISCOURSE_SMTP_PASSWORD_PRIORITY: 
  DISCOURSE_SMTP_AUTHENTICATION_PRIORITY:               # normally set to plain
  DISCOURSE_SMTP_ENABLE_START_TLS_PRIORITY:             # normally set to true

DIGEST CHANNEL ENVIRONMENTALS

env:
  DISCOURSE_SMTP_ADDRESS_DIGEST:                     
  DISCOURSE_SMTP_PORT_DIGEST: 
  DISCOURSE_SMTP_USER_NAME_DIGEST: 
  DISCOURSE_SMTP_PASSWORD_DIGEST: 
  DISCOURSE_SMTP_AUTHENTICATION_DIGEST:               # normally set to plain
  DISCOURSE_SMTP_ENABLE_START_TLS_DIGEST:             # normally set to true

The plugin will default each of the channels above to the Discourse standard channel if you do not specify one.

Notes for Developers

This Discourse plugin creates new a "high priority" SMTP "channel" for "higher priority" SMTP messages and a new "digest" channel only for digests sent to users, including the AdminConfirmationMailer and the following methods in the UserNotifications mailer:

PRIORITY CHANNEL ACTIONS

  • :email_login,
  • :signup,
  • :forgot_password,
  • :admin_login

DIGEST CHANNEL ACTION

  • :digest

This new "high priority" SMTP channel should be different than your standard channel where Discourse sends out digests, etc.

The choices above for "high priority" was completely subjective (on my part) and can be easily changed by modifying the plugin.

You can easily check your configuration in the container using the rails console, for example, to show your SMTP settings for your "priority channel" you can:

rails c
Rails.application.config.priority_smtp_settings

Ditto for the the "digest" channels:

rails c
Rails.application.config.digest_smtp_settings

Ditto for the "default" OOTB SMTP settings:

rails c
Rails.application.config.action_mailer.smtp_settings

If you install the plugin and do not set the ENV vars in the container build file; you can easily check to see that they are all defaulted to Rails.application.config.action_mailer.smtp_settings

In addition, you can easily check the Discourse admin panels:

  • /admin/email/sent
  • /sidekiq

and confirm all is working well.

TESTING

This version (v0.1) has been live tested over many days and so far, works flawlessly.

FOR SYS ADMINS: OUR CONFIGURATION

In our setup, we currently are configured as follows:

  • DIGEST CHANNEL: sendgrid, "api: blah_blah_blah_11111_blah_bla"
  • DEFAULT CHANNEL: sendgrid, "api: blah_blah_blah_2222_blah_blah"
  • PRIORITY CHANNEL: Google Workspace account

The reason for this is that we get a lot of important statistics with sendgrid and we are on the basic (not free) plan for around $15 USD per month and so we can send up to 40,000 messages a month, which we manage by turning digests on-and-off to insure we stay below the 40K limit.

We use two different sendgrid APIs for tracking purposes. I was going to set the "DEFAULT CHANNEL" to another provider like "MailGun", just for fun, but have not done so.

We use our Google Workspace account because our Discourse forum does not get a lot of users signing in via email and the signup volume is low enough that Google does not complain; and so we can easily see what is going on for "high priority" email notifications:

I recommend that sites with a lot of signups, requests to login via email, and other "priority email notification traffic" NOT use Google Workspace (or any Google account) and use other SMTP bulk email providers like Sendgrid, MailGun, etc. As mentioned, we are on the basic (not free) sendgrid plan.

Having said that, your SMTP configuration is "up to you" and not "up to me" :slight_smile: so please configure as you think "best for you".

FUTURE ENHANCEMENTS

There are also fun things we can do like adding a "round robin" using a random number generator to load balance digest emails (for example) across a number of providers. By easily modifying this plugin we can have 3 or even 30 email channels and so we can be very creative!

In addition, we could look at the Jobs exceptions for our mailers and if there is a problem we could flag that mailer (channel) and stop sending email to any "flagged" channel, etc.

The sky is the limit really; but for now, I have no immediate plans to add "round robin" or "disabling faulty channel" features to this plugin as I'm busy on other tasks.

Frankly (my bad), I'm not into EmberJS programming (in 2020, not sure about 2021, but I doubt it... ), so I did not add any new UI features in this release, sorry about that. I'm more into server-side programming, system admin and cybersecurity related features (server side), as a general rule; but that is just me. Feel free to PR some new Ember UI code or fork and modify! If I decide to add a new route to display these new SMTP channels, I would more than likely do it using Bootstrap and jQuery, since (as mentioned), I'm not currently excited about EmberJS programming.

CHANGING OR ADDING ADDITIONAL METHODS

The current plugin configuration for "priority channels" is completely subjective, and I'm open to changing these by adding other mailer class methods to the "priority channels". I'm easy to find on the net :slight_smile:

SEE ALSO

FOOTNOTES

  1. The three core domains of cybersecurity are as follows:

    1. Availability
    2. Confidentiality
    3. Integrity

This plugin is designed to improve the "availability" domain of Discourse cybersecurity by moving low priority digest SMTP traffic out of the default SMTP channel; and to move "higher priority" SMTP traffic to an SMTP channel with low traffic (no digests, no causal user notifications).

PLUGIN ANNOUNCEMENT AT META DISCOURSE

SEE ALSO

1 Like

FLUSH REDIS

Please note that you should flush the existing jobs in REDIS after installing, to clear the prior mailer jobs out of the job queue. You can run this from inside your DB container:

redis-cli flushall

The command about will flush REDIS and remove the prior action mailer jobs before this plugin was installed

Otherwise, you will still have jobs in REDIS with the old SMTP credentials.