But there are some issues with elastic email as well Add IsTransactional:true to SMTP Mail Headers to satisfy ElasticEmail
5 Likes
Jay, thanks for bringing that up. Let me understand that better:
What you are drawing attention to is: when people get email delivered from Elastic Email, they are provided with a very prominent link and can unilaterally unsubscribe from email delivery and Discourse will not know about it? You as the SA will be none the wiser?
1 Like
I do not have first hand experience.
It sounds like they insert an unsubscribe link and that a special header is required to make it go away. I donāt know if there is a way to have elastic email but a webhook to notify discourse of unsubscribes,but they are not listed in Handling bouncing e-mails.
I think that if you can make aws work, itās probably the best solution, but thatās not a good solution for people who come here to learn how to make email work.
Mailgun is really easy.
7 Likes
Thanks.
This is kind of moot for me, and Iāll tell you why: SparkPost did exactly the same thing - though admittedly I never checked to see if there were any hooks I could have used (stupid me, because there are and its 2019 FGS).
In that instance I only found out because the site affected serves my local community so I bumped into the guy who had inadvertently clicked the unsubscribe link on the SparkPost delivered mail and was grumbling he wasnāt get any of the password reset emails. SparkPost has an audit trail for this though and an ability for admins to re-subscribe someone (obviously you need to use this sparingly!), so once I learned of the issue it was an easy fix. I will know to configure my email better next time.
You are swinging me towards Mailgun now, though, thanks!
5 Likes
I do wish there were a more āgenericā way of Discourse handling webhook email bounces. Our preferred provider (Postmark) is also not on the list which means we keep sending emails to people whose address has bounced.
Some sort of magical generic incoming JSON webhook parser for bounced email webhooks would be awesome!
1 Like
What you mean is that some āmagical standard for JSON webhooksā would be awesome. As it is, each mail service makes up their own, so a separate webhook parser is needed. Creating a plugin that would do it wouldnāt be that hard and could probably be had in the marketplace (and might be accepted as a PR) for something on the order of $500.
6 Likes
Yeah, I was just thinking that assuming +90% of the incoming bounce data is in JSON or some other regex-able format, it might be possible to indicate via a setting to indicate the JSON āfieldā that represents the bounced email address and possibly the other field that would represent the bounce type (hard, soft, etc.).
It could be listed as a āgeneric incoming bounce email webhook regex parser.ā The name rolls right off the tongue 
It could possibly help with the constant churn weāre likely to continue to see for this particular type of service.
Weāre a pretty low volume employee intranet site, so weāll probably just live with it for now.
3 Likes
From another thread, you can also make the extra ElasticMail unsubscribe link go away by telling them where Discourseās is: annotating it specially as {unsubscribe:{https://.....}} (Iād recommend confirming with support before sending a pull request).
This could probably be accomplished by editing translations?
3 Likes
I also was using sparkpost for my discourse instances and recently received this notification from sparkpost.
So I went searching for an alternative.
I set up sendgrid and that seems to work well so far. I am using the Basic plan for 15$/month.
2 Likes