This is a headache for most community admins: They have a site contact email like webmaster@mysite.com and they use this email in the vbulletin’s webmaster address (vbulletin admin cp/vbulletin options/Webmaster’s Email setting). This address is used by vbulletin to receive “contact us” emails of members AND also to send all automated vbulletin mailings to members like “new thread notifications”, “new private message notifications” etc.
And when the same address is used both to send automated messages and receive vbulletin contact us inqueries, you find yourself in the big problem of “bouncing emails”.
When your community gets crowded, some of your members’ emails will become unaccessible: They’ll change ISPs, dump or close their email accounts, their inboxes will get full and start returning new mails, their server will temporarily or permenantly go down etc. and in all these scenarios, the emails your forum produces for them, will bounce back to you with an error message like:
“This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:”
“SMTP error from remote mail server after RCPT TO:< @ >: host solmx03…..e.com [12.252.xxx.yyy]: 550 That e-mail address does not exist (#5.7.1)”
“SMTP error from remote mail server after RCPT TO:<….. @hotmail.com>: host mx2.hotmail.com [65.55.92.136]: 550 Requested action not taken: mailbox unavailable”
“This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: …. @otmail.com retry timeout exceeded”
“Inbox is full”
etc.
If you have a large member database, you’ll end up finding more and more of these emails in your admin mailbox everyday.
Some admins try to deal with them manually: They go to vb admin cp, search for the user who is using this email address and deletes his account or unsubscribes him from all his subscribed threads etc. so that site will not send more emails to this account anymore. Well this is a lot of work to do everyday and it will become more tedious when your board started to get more crowded and also when these members will fix their email account problems in the future and ask for a reactivation.
Some other admins try to use bounce email management hacks which are available in vbulletin.org for dealing with these bouncing member emails. Most of these hacks uses a catch-all email account which the hack monitors constantly and when its finds email in that account, it assumes the mail bounced and apply restriction to the owner of the emails you preferred (like putting him into a restricted usergroup, unsubscribing him, deleting his account etc.). This is a good approach but it does not always work with 100% efficiency because it is not easy for a script to decide whether the incoming mail is really a bounced email or something else. You’ll very frequently have members who use “auto-repliers” in their email accounts or “vacation/away notices” etc. as well as members who think they can reply these vbulletin notification mails. So these irrelevant emails will also go into the catch-all address of the bounce management hacks and most of these hacks will assume the account is bouncing although it is no. So due to their high false identification rate for bounced email detection, I personally don’t use any of these hacks.
But not using this hack, doesn’t necessarily mean we have to bear members’ bounced emails everyday in our admin accounts. My solution for this is very easy and quite effective as well:
* I create 2 separete emails in my communities as admin account. One account is an actual POP3 email account which I use for receiving site related communications. Let’s call this contact_me@mydomain.com Then I have another email account which is called post_bot@mydomain.com and I use this one for sending automated mails.
* I create post_bot@mydomain.com email address with an autoresponder tied in it. Whenever it receives an email, it returns an reply telling that this email address is not used, nor monitored and asks contacter to use contact_me@mydomain.com if she tried to reach me. This makes sure if somebody accidently emails me in this email address, she knows I didn’t get the reply and she also knows where to mail me to reach me.
* Apart from this autoresponder tied to post_bot@mydomain.com account, this account is NOT an actual postbox (with Pop3 etc.) and after it autoresponds all incoming emails, it discards them all. So I don’t have compiling bouncing mails in my mailbox. I put this email to the “Webmaster’s Email” setting in vbulletin admin cp/vbulletin options/ Site Name – URL – Contact Details. So all automated vbulletin emails are sent from this email address and all bounced mails to this address discarded with an auto-responder message in case it was not a bounced message. This means I don’t see any bounced mails anymore in my admin email
* Now we have to make sure when somebody contacts you via vbulletin’s contact us form, you receive her email without problems. I use a simple vbulletin product to achieve this:
product-log_secondwebmaster_email
(Upload the product in vb admin cp/Pluggins & Products / Manage products/ Add/Import Product)
* This pluggin will add a new option in your “vbulletin admin cp/vbulletin options/ Site Name – URL – Contact Details” section named : “WebMaster Email for Contact Us Page”. Now you have to go to that page and enter “contact_me@mydomain.com” there. This will make sure all emails sent to you via vb contact us page, comes to contact_me@mydomain.com email address which is a POP3 email that you use and monitor. But all vb automated emails will go FROM post_bot@mydomain.com address and you won’t be bothered with bouncing ones anymore.
Simple and effective. 😉
Now some notes about this configuration:
1- Vbulletin also allows you to enter specific email address for contact us page in “Contact Us Options” (vbulletin admin cp/vbulletin options/ Site Name – URL – Contact Details). So you could have entered “contact_me@mydomain.com” there as well but there is catch with this approach: Contact Us options puts a “Other” field into contact us page and this other field sends the incoming mail to default webmaster email. Since we don’t receive them anymore there we can’t allow this so this is where this hack comes handy.
2- Some might think tieing an autoresponder to an email account which gets a lot of bouncing emails creates an infinite loop but it does not. Modern mail servers easily recognizes this pattern and discards these emails so you won’t receive infinitive bounces when you send an auto-reply to a bouncing account.
3- Some admins think bouncing emails are hard on server, creating server load but it does not unless you have a huge number of them. In a large community where you receive a few hundreds to a few thousands bouncing emails everyday wouldn’t put any load into your server but I’d admit if you receive tens of thousands of such emails, this can be another story. But this is really a rare scenario for most admins if though your community is large.
4- The product I added above will work in vb versions above 3.5.x. This includes 3.5.x, 3.6.x, 3.7.x and 3.8.x (which was the most recent when this blog entry is created)
5- I personally don’t use any of the bounce email management hacks myself because I don’t believe they can effectively deal with bouncing emails. As described above, an email incoming from a member email can be a legitamate email (eg. member accidently replied to a thread new reply notification via email), temporary issue (email box full at the moment), permanent issue (email account is closed) or even irrelevant email (vacation auto-reply of the member). It is not easy for any application to intelligently analyze these emails and decide which are really bouncing and which are not so I prefer the method described above to fight bouncing emails, rather than bounce email management hacks. But if you found a stable and nice hack which deals with them fine, then you can stick with it. I don’t demote them all. ![:)](https://www.logician.org/wp-includes/images/smilies/simple-smile.png)
Share This Comment:
These icons link to social bookmarking sites where readers can share and discover new web pages.
Recent Comments