I would not recommend making emails that infrequent. Maybe 1 month, definitely not 3 or 6 months. You really increase the risk of getting bouncebacks, dead email addresses, or just angry/confused people.
we get a range of requests - but basically its that they want to be “less active” and not receive the status updates every week or two.
Many cases users don’t know how to access their preferences and just ask us - so we help them.
That brings up another question - How does discourse (or is it Mandrill) deal with bouncebacks - is there a feedback loop to stop sending to dead addresses?
You can configure Mandrill to notify a specified address of any hard bounces: http://help.mandrill.com/entries/25524828-Can-I-receive-bounce-notifications-via-email-
And you should know that Mandrill will lower your account reputation every time you get a bounced back email.
I believe Mandrill automatically handles bounced emails though, e.g. they stop emailing that address on your behalf:
After a bounce occurs for a recipient email address, Mandrill stops attempting delivery of the email. Further email to that address will be rejected temporarily.
Mandrill utilizes a set of heuristics to determine whether a bounce should be classified as a soft or hard bounce. Generally, permanent errors such as invalid mailboxes will get classified as hard bounces, while quota errors and other temporary problems are treated as soft bounces. Hard bounce rejections last longer than soft bounce rejections, and Mandrill doesn’t automatically convert soft bounces to hard bounces. If you’re seeing a lot of soft bounces to an address, it may be a sign that the address is unusable.
Ideally this information that the email is no longer valid would eventually percolate up to your app as well, of course…
If longer period options are made available for email reminders, it might be nice to have something like what Tapatalk does - a “we miss you” type of message like below:
Mandrill can forward bounce reports via email. Discourse could receive these in the same way it receives emailed replies and fetch the bounced email’s headers. You’d probably have to add a
X-Discourse-Signature header and validate the received headers, tho.
If nothing else, bounces could be logged in Discourse’s email log and shown as a statistic in
We don’t use Mandrill to send email on our hosting service though.
But that means you have full control over the
Sure, so what do you propose?
Basically the same thing as with Mandrill: include an X-Discourse header with some signed and encrypted data, control the Return-Path, have bounces delivered to the same mailbox where Discourse receives reply emails, find the X-Discourse header in the bounce mail, verify, decrypt and use the contained data to associate the bounce to a user and a particular sent email task.
One important thing to remember is that even Mandrill doesn’t necessarily permanently block future emails when a bounce is received, so it’s not wise to take any long-lasting decisions against users just because they had a bounce. See http://help.mandrill.com/entries/21751262-What-happens-if-an-email-bounces- posted earlier for details.
I hate to unbury this topic, but as a long term forum admin, dealing with dormant/inactive/dead/sleeping accounts and therefore often times dead email accounts, is a huge headache and permanent cause of worry and chore. Back in the good old days when one was just using php sendmail, all this was not much of a problem, but now I need to deal with sparkpost/etc. account reputation if bounce rate % gets too high, etc. Communities often increase to a size where patrolling it by hand becomes rather burdensome, but still deleting users by hand which are obviously dead accounts AND their email bounces might be a good practise to cut down on emails sent that just bounce for some reason. The other worry is inactive users who just have been away for too long a time and it becomes increasingly hard to reach out to them and maybe get them back on board, because they don’t read their email anymore. Yes you can have an argument whether it’s spam or not, but in the end they signed up for the forum so if they really formally want to sever ties, they can let the owner know or shut down the account themselves, until then emailing them I think is fair game from a compliance perspective. Plus, there are a myriad of reasons people haven’t logged in in ages, one might be they switched email providers and just “forget” about a community they signed up for using an old email address. In my case, I might have lost about 10 to 20% of my membership to these and related issues, also in the wake of the switch to Discourse (which doesn’t let me mass-mail as easily
So to cut a long story short, there are two options for discourse admins: a) just don’t care about the degree of activity of your userbase or b) do what you can do increase it, to revive dead accounts, to help folks log back in, to weed out dead accounts, etc…
Sadly - email is not a very effective or efficient means of reaching people any longer due to:
- Younger people using mostly texting and in-app alerts
- Overwhelming popularity of Gmail, and Gmail filtering broadcast emails into the “forum” or other folder
I don’t know about you - but I read less than 1% of the emails I get in my gmail account these days - I’m sure thats somewhat representative.
Totally correct, but what is the alternative? Deleting everyone who hasn’t logged in within the last 12 months and deal with their complaints if they decide to come back in month 13?
Probably some sort of account / email aging system that decreases email frequency based on the clicks received on them and frequency of email logins.
Personally - I’d also love to have a backup plugin of SMS contact to users using Twilio or something similar so we have a more efficient means of pulling people back to the forums.
I think this is an awesome idea to avoid these daily email notifications being sent to dormant accounts. Such a setting would be great! #feature
Users who don’t come back for a year get the digest mails stop being sent to them.
But not topic notifications, I assume…