I’m working with a user to troubleshoot non-receipt of email and stumbled on the “revoke email” action logged for their account. How can I cancel or undo this action?
Also: if a user’s email is revoked, is this reflected in the Email Sent or Email Skipped logs? Or only in the Revoke Email action?
Continuing the discussion from What does 'revoke email' action mean in Logs?:
The revoke email action is triggered when multiple emails sent to a user bounce (fail to be delivered.) Each time an email bounces, the user’s ‘bounce score’ is incremented either by the value set by your site’s soft bounce score or hard bounce score setting. Once a user’s bounce score reaches the value of your site’s bounce score threshold setting (defaults to 4), the revoke email action will be triggered.
You can undo this action by going to the user’s admin page and clicking the ‘Reset’ button that is in the ‘Bounce Score’ row near the top of the page.
If you do not click the Reset button, Discourse will automatically clear the user’s bounce score after the period of time set by the reset bounce score after days has passed. This setting defaults to 30 days. After that period of time, Discourse will attempt to send emails to the user again.
If an email is not sent to a user who has exceeded the site’s bounce score threshold, an entry will be added to the Skipped logs. The Skip Reason will be set to ‘Exceeded bounce_score_threshold’.
Thanks. So if I see “Exceeded bounce_score_threshold” in the Skipped log for a recent email message to User X, I can assume there was a “revoke email” action for that user earlier, and vice-versa?
The context is that one of my users is not getting email from our Discourse instance. He’s quite competent, so I trust his reports that he’s checked his spam folder, etc. I’d reset his bounce score a while ago, but only stumbled on the Revoke Email in the log for him today.
This is interesting. I had assumed the bounce score would be reset for those whose emails had not yet been disabled (like how Mailman works). I guess the closest would be to have this setting at 10 years or so!
As far as I can tell, Discourse always resets a user’s bounce score and then attempts to resend emails to the user. The only difference between how temporary and permanent bounces are handled is that permanent bounces increment the bounce score by a default value of 2 (set by the hard bounce score site setting) instead of by a default value of 1 (set by the soft bounce score site setting.)
That would do it, but could have unintended consequences. For example, users who exceeded the bounce score threshold due to the recent Gmail outage would have to wait 10 years for their bounce score to be automatically reset.
Mailman 2 has higher defaults for the bounce settings/threshold, but once you hit it you get unsubscribed. I can see the argument either way. Edit: I can’t remember the details but think at some point you are offered the opportunity to reply to an administrative email which would reset your bounce score and keep you on the list.
Many people self hosting Discourse probably use Mailgun, which will keep the email address on their suppression list after a single “permanent fail” and so will ignore Discourse’s more lenient approach.
Apparently it’s possible to obtain that suppression list using the Mailgun API and I guess it might also be possible to synchronise it with Discourse’s settings.
I got an email from Google today saying unambiguously that someone had obtained my password — “Google has become aware that someone else knows your password” — so I wonder if that is linked with the “outage”…
I have just noticed this: Configure VERP to handle bouncing e-mails - #166
It is about the removal of the bounce_score_threshold_deactivate setting. I wonder whether that was a mistake. If the default setting was hard to reach then the answer was to lower it.
An unintended consequence of that removal for a large forum seems to be trying to send emails to an increasing number of invalid addresses regularly over the course of many years. Either that could lead to trouble with an external service (like Mailgun, which suppresses an address after a single permanent fail bounce) or IP reputation.
As it is, unless I’ve misunderstood, Discourse thinks it’s sending emails that Mailgun is just refusing to send because of its suppression list - and it is not possible to synchronise Discourse’s approach with Mailgun’s.
I’d forgotten about that. I’m not sure that the bounce_score_threshold_deactivate setting was working to prevent Discourse from attempting to send emails to invalid addresses though. The problem is that once a user reaches the bounce score threshold, Discourse will stop sending them emails until the time period set by the reset bounce score after days setting has passed. At that time, the user’s bounce score will be reset and the process will start over again.
I’m not sure what the best solution for this would be. If I’m understanding things correctly, it does seem that over time a Discourse site will be attempting to send emails to an increasing number of invalid addresses.
There are at least two sides to this. One is what’s a good policy for Discourse, assuming the email sender (eg localhost) will go along with this. The other is how to synchronise things with an email sending service that won’t go along with it (eg Mailgun).
I think there’s already a message in Discourse along the lines of: “Please check your email address as we’ve had trouble with sending to it.” Perhaps Discourse needs a more aggressive approach to disabling bouncing emails combined with a non-dismissible site notice about lack of email sending.
Synchronisation with external senders would be harder. Mailgun say it’s possible to get their suppression list from their API but I don’t know yet whether it’s possible also to remove addresses via the API. If it’s possible to do both then Discourse could disable an address as soon as it enters the suppression list, and remove it from the suppression list when a manual step is taken within Discourse by the admin or user (eg replying to a confirmation email). The other problem linked with this is that every provider likely has different rules.
Edit: Strikethrough above added because it is possible to remove an email address from the Mailgun suppression list using the API: Suppressions — Mailgun API documentation