vBouncer: reduce server load by unsubscribing bouncing members from threads

vBouncer is a handy tool for busy forums (or those that do not require email verification) to control the amounts of bogus emails sent from and to your server.

What vBouncer does: vBouncer monitors your mail spool file, and identifies members responsible for large amounts of bounced emails. It then issues a PM warning, and when the unsubscribe threshold is met, it will will unsubscribe them for all threads, and sets them to the "no email" subscription level.

After a couple of runs, this should significantly reduce your server load.

Features:
o Manual or auto processing option
o Collect logs via IMAP/POP or mail spool file
o Custom filters to match patterns in bounced emails
o Uses vB's cron files (Scheduled tasks)
o Uses encrypted header for authentication (suggested by Paul M).
o Stats on members with bouncing emails, and error codes
o Tuning options
o Verbose cron logs for diagnostics
o Option to send PM warning prior to reaching the limit
o Option to send PM notifications after reaching the limit
o Option to change the member's subscription default
o Option to all thread subscriptions to "no email"
o Option to all forum subscriptions to "no email"
o Option to move offenders to a different primary usergroup
o Option to process 5.0.0/550 errors (email unknown) upon a single email, isntead of observing the bounce limit

Installation:
1. Extract the files into the corresponding directories (admincp => admincp, includes => includes)
2. Run the installation script in the admincp
3. Fill out the settings menu in the vBouncer section of the admin panel (see the how-to post below)
4. Import and activate the plugin file through the plugin manager.
5. Once ready, add the cron scripts to your scheduled tasks: vbouncer-collect.php (should be run daily, or more frequently) and vbouncer-clean.php (weekly, equal to Bounce limit period)
6. If you are using vB's SMTP email option, make sure to also enable the "-f" option.

Change log:

- August 12, 2005 v1.3 Update to the cron files to match new changes in vB's cron/tasks. To upgrade, just re-upload the contents of includes/cron.

- July 11, 2005 v1.2 Bug fix for some server/PHP setups; resolve aliases for return keys, otherwise some aliases would be considered forged.

- July 5, 2005 v1.1 Bug fix in standard report pattern matching

- July 4, 2005 v1.0 Added encrypted header for authentication (suggested by Paul M).

- July 3, 2005 v0.9.1 fixed a bug preventing IMAP/POP log collection.

- July 2, 2005 v0.9 added IMAP/POP option and custom filters file vbouncer.ini

- June 27, 2005 v0.5 Added custom header setting option, for re-written headers.

- June 26, 2005 v0.4 Found a way to make it work as a plugin, without code edits (thanks to Paul M)

- June 26, 2005 v0.3 No changes, just removed the plugin

- June 25, 2005 v0.2 Added NDR/Reply code errors to stats, and option to act upon 5.0.0/550 (user unknown)

- June 21, 2005: v 0.1 Initial release. Marked beta, but it's working fine on PostFix and SendMail. Need to hear from those who tried on QMail and Exim

[kmike]

Looks like this hack is not supported anymore. Here are a few bug fixes for those who still care.

1. There's a bug in the regular expressions: all occurences of

RFC822;[ ]*[<]*(\S+@\S+)[>]?

should be replaced with

RFC822; *<?(\S+?@\S+?)>?\s*$

otherwise an email address scraped from this line: "Final-Recipient: RFC822; <xxxx@test.sg>" will include the final ">" ("xxx@test.sg>"). Apparently it affects all addresses at charter.net.

2. Next thing, sometimes members fill out their email in capital letters, but reporting MTA rewrites them in lower case, such as: "Final-Recipient: RFC822; USER@aol.com" for the user provided "USER@AOL.COM", so md5 check of USER@aol.com will be against md5-encoded USER@AOL.COM and a bounce will be reported as forged when it's in fact not.
The solution: strtolower() member email address before sending and also strtolower() before checking them against X-Return-ID.

3. Finally, the recipient email address may be an alias for the different account. In this case "Final-Recipient" line will include that another email address instead, and the check for the forged bounces will fail. This one is tough to correct. It is amended by adding another custom header with an original email address and checking md5 against it and not the one scraped from a "Final-Recipient" line. But obviously this is a bit more prone to the errors and the possible forging though.

[GNDI]

Where are this line located: RFC822;[ ]*[<]*(\S+@\S+)[>]?

[Freezerator]

Originally Posted by kmike

Looks like this hack is not supported anymore. Here are a few bug fixes for those who still care.

1. There's a bug in the regular expressions: all occurences of

RFC822;[ ]*[<]*(\S+@\S+)[>]?

should be replaced with

RFC822; *<?(\S+?@\S+?)>?\s*$

otherwise an email address scraped from this line: "Final-Recipient: RFC822; <xxxx@test.sg>" will include the final ">" ("xxx@test.sg>"). Apparently it affects all addresses at charter.net.

2. Next thing, sometimes members fill out their email in capital letters, but reporting MTA rewrites them in lower case, such as: "Final-Recipient: RFC822; USER@aol.com" for the user provided "USER@AOL.COM", so md5 check of USER@aol.com will be against md5-encoded USER@AOL.COM and a bounce will be reported as forged when it's in fact not.
The solution: strtolower() member email address before sending and also strtolower() before checking them against X-Return-ID.

3. Finally, the recipient email address may be an alias for the different account. In this case "Final-Recipient" line will include that another email address instead, and the check for the forged bounces will fail. This one is tough to correct. It is amended by adding another custom header with an original email address and checking md5 against it and not the one scraped from a "Final-Recipient" line. But obviously this is a bit more prone to the errors and the possible forging though.

Thanks, but can you please englihten this more? Or post an updated file.

[alfaowner]

Hi all,

Need some advice if you can, I uninstalled vbouncer for various reasons, I used the uninstall script to do so but my members that had previously bounced emails are still not recieving subscription emails or normal vbulletin sent emails, can anyone advise why or how to make it so they can recieve emails. BTW - I logged into theor account and checked all of their settings and they are ok / correct.

Please help

AO

[Eagle Creek]

Is there a 3.6.3?

[Eagle Creek]

I made a new E-mail address (notificaty@) but the mails are still send from webmaster@. Did I do something wrong?

[GNDI]

running a new version of Vb, that's all

[Eagle Creek]

You're joking right?
So it doesn't work?

[ebasement.org]

I'm interested in this for the latest version as well.

[GNDI]

Originally Posted by Eagle Creek

You're joking right?
So it doesn't work?

Not at all

Originally Posted by ebasement.org

I'm interested in this for the latest version as well.

it is working when you manually use your "fake" e-mail address as sender, ex. when you use the "Send e-mail to users" function under "users" in admincp, then it is a powerful tool