Deal intelligently with bouncing email addresses

[pauamma]

Title:
Deal intelligently with bouncing email addresses

Area:
email notifications, email address validation, not spamming users

Summary:
When an email sent to a user is rejected or bounces, do something intelligent instead of just ignoring it.

Description:
Currently, when emails Dreamwidth sends to one of its users start bouncing (being rejected, or undeliverable because that email address no longer exists), the Dreamwidth email servers just ignore this, instead of using it as a hint not to deliver more emails to that email address. This behavior was inherited from LiveJournal, and has caused in the past much distress to users, ops people, support volunteers, and email providers, and occasionally drastic reactions by email providers, such as refusing or silently discarding all emails from LiveJournal, thus making the problem worse. LiveJournal recently committed a code change (http://community.livejournal.com/changelog/8801455.html) that changes that, but its approach may no be the best (http://bugs.dwscoalition.org/show_bug.cgi?id=2759). (Specifically, it makes that email address unconfirmed for all user accounts associated with it - http://www.dreamwidth.org/support/faqbrowse?faqid=3.)

Other, less drastic ways to deal with delivery problems include notifying the user via their inbox instead of disabling delivery, only acting on the specific account for which the email was sent, only acting if more than a threshold number of emails bounced, or only stopping emails to that address temporarily, instead of until the user takes action. (Or of course, keeping the current approach of ignoring all such reports.)

Poll #3747 Deal intelligently with bouncing email addresses

Open to: Registered Users, detailed results viewable to: All, participants: 41

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
31 (75.6%)

Should be implemented with changes. (please comment)
7 (17.1%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
2 (4.9%)

(Other: please comment)
1 (2.4%)

Comments

[matgb]

I ticked 'as is' because I don't have a change to suggest, even though you're not actually proposing a solution. Ignoring it is definitely a bad idea, especially given the irregular havoc LJs failed notifications have caused.

[cesy]

I'd vote for doing all of your less drastic ways at once, so it's lowest impact to users who've just slipped over their mailbox limit, but still protects Dreamwidth.

[aithine]

I think disabling the email (stop sending emails from Dreamwidth to that email and the user needs to reconfirm that address) and also contacting the person via their inbox to let them know they're having email issues would work. Probably needs a threshold, though--after three bounces or whatever, so that it's not immediate when it's just the person's email server having issues that day. :)

[thorfinn]

Investigate the methods that Mailman uses to handle mail bounces. Copy those. They are excellent.

[azurelunatic]

Actually, I do have a few ideas.

1) When a bounce is detected, put the address on automatic timeout -- queue all emails to be sent to that address (for all associated accounts), for a system-determined amount of time. This prevents loss. Retry later.
2) Notify via inbox and to all other previously-validated addresses (if still on account) that the validated address on the account is bouncing (without specifying the address in case of compromise on the old addresses).
3) Test with a single email to the bouncing address before sending the queued mail.
4) If it keeps bouncing after a certain amount of time and number of trials, declare that address Stopped Until User Action.
5) Create the ability for a user to create a fallback address, to which email will be sent as normal, in case of primary email bouncing. (This is different than sending a notification to a previously validated email address, in that a previously validated address not specified for fallback would not get the other regular notifs).