MyBB Community Forums

Maybe a "bounce/returned/failed log" could be added to Mybb 2.0 that would list any undelivered mass emails.

+1 .....

Good idea

There's really no easy way to do this... I'm no dev, but I see the easiest way as having to check the inbox of the email you sent from for any emails, read the emails, use regex to get the email that bounced, etc. Not easy at all.

(2012-04-27, 07:15 PM)Paul H. Wrote: [ -> ]There's really no easy way to do this... I'm no dev, but I see the easiest way as having to check the inbox of the email you sent from for any emails, read the emails, use regex to get the email that bounced, etc.  Not easy at all.

+1

How do other mass mail systems handle bounces and unsubscription requests ?
Can Mybb not follow suit?

Most un-subscribe requests these days are done via webpage rather than email return, so it's a quick easy change this control to update a database value rather than an email communication (not sure what this functionality has to do with subscription requests though)...

For the devs, One could actually write validation that checks if a users email address actually exists prior to allowing them to sign up with it or change it. This same validation code can be used to see if the address is available at the time that a mass email is sent, and if not skip processing and put it in a "failed queue". Of course, it could become kind of cumbersome to check thousands of emails prior to sending the email to them. :p If you care about time, checking the server and address of each email in a mass email is a little gruesome. Most cases of non-existent emails would be caught on registration. You'd just have a couple of cases for when someones email server is down, or possibly email account deleted.

https://www.webdigi.co.uk/blog/2009/how-...-an-email/

(2015-03-09, 07:47 PM)HolyPhoenix Wrote: [ -> ]Most un-subscribe requests these days are done via webpage rather than email return, so it's a quick easy change this control to update a database value rather than an email communication (not sure what this functionality has to do with subscription requests though)...

For the devs, One could actually write validation that checks if a users email address actually exists prior to allowing them to sign up with it or change it. This same validation code can be used to see if the address is available at the time that a mass email is sent, and if not skip processing and put it in a "failed queue". Of course, it could become kind of cumbersome to check thousands of emails prior to sending the email to them.  :p If you care about time, checking the server and address of each email in a mass email is a little gruesome.  Most cases of non-existent emails would be caught on registration.  You'd just have a couple of cases for when someones email server is down, or possibly email account deleted.      

https://www.webdigi.co.uk/blog/2009/how-...-an-email/

Hi one problem is with existing users whose email addresses become defunct.  This happens a lot - users often change employers or ISPs etc, with corresponding email address changes - and there is currently no way for the administrator to quickly suspend e-mail to those addresses - must go through the gruesome process of manually searching for each of potentially hundreds of users via address, un-ticking every setting that could result in email (including settings added by 3rd party plugins), then reversing the process when a disgruntled user wants his settings back.  Needs to be an instant 'suspend all email' option that preserves user email preferences, for when a valid address is substituted, and prompts any user logging in that their email address is bouncing and should be replaced

Another problem is that no user who just wants to unsubscribe for a while should have to go through the whole rigmarole of requesting a new password (which nearly always entails user submitting two password resets, and then responding only to the second email the forum sends back , which procedure of course requires contacting the admin to even find out about! - another long standing bug that is well documented elsewhere), then for the user to learn their way around the forum sufficiently to even find their UserCP, and then to know each and every place within UserCP that can trigger email - including the places added by plugins. 

Not one part of that is reasonable to expect of casual forum users - who may only have signed up to ask or answer a single question years earlier.

If there is no direct 'unsubscribe' replyto: link in unwanted forum messages, or at least no single-click way to unsubscribe without needing to log in and visit UserCP, it is far more logical for most users to simply mark unwanted forum messages as spam, than to jump through all these hoops.

This of course taints the whole forum's reputation, and as more people do it, the forum ends up on email blacklists etc - making life generally harder for admins and other users, as ISP spam filters start preemptively blocking forum email.

Really, the current situation is just not ok

Bounce detection is possible but only really with enterprise email services such as Amazon SES or Mandrill which use web hooks to trigger bounce detection.

MyBB could not ship with bounce detection by default, but it could make it possible to switch MyBB's email to use one of these services and then you could use those services for bounce detection.

(2015-03-25, 09:54 PM)Will P Wrote: [ -> ]Bounce detection is possible but only really with enterprise email services such as Amazon SES or Mandrill which use web hooks to trigger bounce detection.

MyBB could not ship with bounce detection by default, but it could make it possible to switch MyBB's email to use one of these services and then you could use those services for bounce detection.

Probably my other suggestion is more practical:?

A manual single click 'bouncing' / unsubscribe link that can be found at the foot of every email generated by any plugin or subscriber notification (and is thus visible to admins in any bounced emails returned) to deactivate the mail send function for that user .

I.e admin sees a bounced email => Clicks the link in that email => a very simple unsubscribe/bouncing email web page opens in which to insert the offending user's current email address =>clicks 'submit'.  That user is then switched off for email of all types, until he or an admin toggles email back on. 
This should not need any user (in password protected forums) to request a new password if his old one is lost, so should be able to occur outside UserCP or AdminCP.

Even better, if that unsubscribe/bouncing link placed in every forum email could be tailored to auto populate the user email address field in the unsubscribe/bouncing page linked to - so only user or administrator action required is  to click the 'submit' or 'are you sure?' button.

Perhaps a 'reason' field would allow administrator to record 'invalid email address' vs ' forum messages rejected as spam' vs 'user request'

Users who have had email deactivated, could switch it back on from UserCP / Admin CP, and perhaps should see a blinking 'Email is currently disabled for your account - please go to UserCP to reactivate"   There, the reason for deactivation would display, so they are prompted to update email address or address spam issue with their mail host.

check your email address is up to date, and untick the 'stop all email' button.   add the forum address to your email client address book, and then click reactivate" if they ever log in to forum again.

How does the admin see the bounced email? How does the admin know the email has bounced so they can click the link?