hello, this happened yesterday (ghost 3.40.1)
a bunch of gmail addresses had delivery issues, had to cleanup & resend manually from mailgun
but in addition, ghost chose to unsubscribe those folks (silently, only noticed today)
i don’t think that should be the behavior, should it?
thanks!
Hi @os72. That was an unfortunate incident 
The auto-unsubscribes on permanent failures are standard behaviour for list management because repeatedly sending to known-bad addresses costs you money and can damage your sender reputation score meaning your emails can fail to get to the good addresses!
Ghost’s unsubscribe issue was not an isolated incident as can be seen from the discussion here https://news.ycombinator.com/item?id=25435916.
It appears Mailgun has worked to keep it from being a problem on their side by stopping these users ending up on their suppression lists. On Ghost’s side there needs to be some manual intervention to re-subscribe the failed members, I’ve detailed the steps below (if you’re a Ghost(Pro) customer this has already been done for you):
If you view the details for one of the failed sends in Mailgun you will be able to see an email-id like this:
Make a note of it then connect to your Ghost instances database. From there you can query to make sure there is correlation between the selected members and the failed members in Mailgun (replacing <email-id> with the value noted above):
select
email, subscribed
from members
left join email_recipients on members.id = email_recipients.member_id
where email_recipients.email_id = "<email-id>"
and email_recipients.failed_at is not null;
If that correlates then you can re-subscribe the members that failed for that email:
update members
left join email_recipients on members.id = email_recipients.member_id
set subscribed = true
where email_recipients.email_id = "<email-id>"
and email_recipients.failed_at is not null;
Shouldn’t this be handled on mailgun side? Like you said, they manage suppression lists, etc
Why should Ghost repeat the same thing? At least it should be optional…
I use a provider so I cannot directly run DB queries
There was another bug that prevented me from re-enabling via admin, so I did it via impersonation and the portal button
I think maybe the admin UI should have some mass-operation capability…
Ghost is responding to events from Mailgun. This was an unfortunate occurrence where Gmail was responding with completely inappropriate error messages indicating permanent failure for many addresses for a protracted time period. It was completely outside of normal/expected behaviour.
Your mailing list is not stored on Mailgun, it’s stored in Ghost. This lets you export and import your data, sync your members list with other mailing providers or systems, and switch CMS at any point. It’s important to own your own data in all of those situations which is why list maintenance is done at the source.
Re what should ghost manage vs mailgun, yeah maybe. I can’t say I have enough experience
But I think these state transitions must be made visible to the admin, some notification or log. Right now it’s completely invisible
User signup, subscription change, plan change, etc
Agree with you on the state changes being “invisible” at the moment. Don’t know if/when/how this would be addressed. That said, a nice work around for tracking unsubscibes at the moment could be using Zapier integration for member’s subscribed value updates.
Agh! Just noticed this as well. I wondered why there was a mass unsubscribe event some time in the last few weeks. It assumed it was because of new year resolutions (“In 2021, I will renounce all email newsletters…”). But now I see that a bunch of people were automatically unsubscribed because of the Google glitch. Heading over the Zapier now to set up a zap which will notify me of such things in future… 