All this has to be clearly documented.

This was a newsletter issue, but I think really it represents a broader need in Composr. Repeatedly sending emails to addresses known to bounce is likely to get us banned on particular email vendors (e.g. Apple, https://support.apple.com/en-us/HT204137).

We should have a Cron hook that scans for email bounces based on a set of rules specified in this issue. Bounces should then be passed to a new bounce hook type, which will unsubscribe from whatever that hook is dealing with. Hooks to implement:
1) Newsletter
2) Notifications
3) Mantis tracker

1- Simple removal of record
2- Explicitly turn off all notifications in the database (so they don't default back to on).
3- Turn off notifications in the preferences, which is this query: UPDATE mantis_user_pref_table SET email_on_new=0,email_on_assigned=0,email_on_feedback=0,email_on_resolved=0,email_on_closed=0,email_on_reopened=0,email_on_bugnote=0,email_on_status=0,email_on_priority=0 WHERE user_id=xxx; (these settings work as a filter AFTER whatever can trigger a notification, so they take precedence)

Additionally we should not email users who have not logged in for a long time. See https://support.apple.com/en-us/HT204137 - "Periodically remove inactive subscribers from your list."

We should have a Cron hook that finds stale accounts, as defined by a config option specifying inactive timeout

This can also then call the bounce hooks, with a parameter specifying it's of a stale type rather than a bounce type.

And lastly, we should implement a button on the notifications screen to reset notifications to default settings. This allows a user to restore notifications to how they would normally be if they come back.

A couple of additional feedback:

1) I think bounce detection should be integrated into the account registration process as well (if e-mail verification is on). Best practices are to keep your site from ending up on a blacklist. Unfortunately, some poorly-maintained webservers (including mine) get themselves on level 3 network-wide blacklists for failing to handle spammers. This might cause legitimate sites that happen to be on a blacklisted network to get blocked by e-mail providers (AT&T is especially strict about this). There are a couple ways we could go about this:
- a) A registration status link. Upon registering, members are given a link with a unique / secure code to check the status of their registration at any time. This page could tell them when the site's attempt to send them an e-mail verification failed. It could also provide them status of accounts needing to be manually verified by staff.
- b) If a user who just registered and is pending e-mail verification has an e-mail bounced, then we could perhaps have a config option on what to do: Do nothing, remove the e-mail address associated, delete the account, ban the account, or ban the account and IP address.

2) To be more compliant with the GDPR, we should separate the functionality of erasing the e-mail address / not e-mailing stale accounts into a different configuration, and allow for the ability to delete stale accounts automatically. This configuration allows us to pick what to do for accounts that have not logged in for x days:
- Do nothing
- Stop e-mailing the member
- Stop e-mailing the member and unsubscribe from all newsletters and notifications
- Delete the member's account
- Delete the member's account and anonymise all data associated with the member
We should also have a config option allowing to specify an automatic reminder e-mail to members x days before their account is considered stale and will have this action performed.