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

[Spinball]

tamarian, yes, that sounds great provided the error codes can be 100% identified for emails which have bounced. A '550 Invalid recipient' would require the user to be moved to requiring email activation (with ideally a PM sent to the person but email notification of that PM not) whereas a '552 5.2.2 Over quota' would need to be processed as per your quota system.
The big problem I have is when we send out an email to all our users (40,000 ish recipients). We get something like 1,000 or 2,000 bounced emails, with a lot of those being from AOL (it must detect a lot of emails from a single source and block them all), and maybe 300 or 400 which require the user's account to be deactivated.
This plugin could potentially save me 2 or 3 hours every time we send out the mailshot.

[Edit - just had a thought. What about people who mistakenly reply to thread notifications, as they sometimes do? They think they are replying to the thread. It's usually less experienced users doing it.
Ideally they need an email back saying that they have mistakenly replied to the forum mailer.

[tamarian]

Looks like we now have QMail covered, thanks to Merc. I've updated post #3 with the details. We've already had Sendmail and Postfix covered. So only Exim information is missing (I'm assuming Windows servers use Sendmail).

[tamarian]

Originally Posted by Spinball

[Edit - just had a thought. What about people who mistakenly reply to thread notifications, as they sometimes do? They think they are replying to the thread. It's usually less experienced users doing it.
Ideally they need an email back saying that they have mistakenly replied to the forum mailer.

This should not affect them, and they will not be considered bouncers. vBouncer only processes emails coming from MTA's directly, with a Final-Recipent header tag. A normal email would not have that tag.

[merk]

In your instructions above, you mention

touch /var/spool/subscriber_notify

while, the path you mention before that is /var/spool/mail/subscriber_notify

Hopefully I will install and use vBouncer sooner rather than later, its definatly a feature I need!!

[tamarian]

Thanks for the correction Tim :up:

I have just released a 3.0.7 version, similar in features to this one. For those who don't plan to upgrade soon, you can use it instead:

https://vborg.vbsupport.ru/showthrea...threadid=91119

[Paul M]

Originally Posted by tamarian

Looks like we now have QMail covered, thanks to Merc. I've updated post #3 with the details. We've already had Sendmail and Postfix covered. So only Exim information is missing (I'm assuming Windows servers use Sendmail).

I have this installed on our test (cpanel) server - which uses exim.

Problems so far ;

1. The mail spool file is located at /home/<cp account>/mail/<mail domain>/<mail account>/inbox - however, we have a php security setting which prevents apache from breaking out of the /home/<account>/html_docs/ to read it. I got round this by writing a little cron job to copy the inbox file to a folder within html_docs once a day.

2. The problem I haven't got round yet is that something (probably exim) appears to be rewriting the Return-Path to "nobody@<server-domain>" before sending the mails. I'm not sure how to stop this yet, but there must be a way because our live server doesn't do it.

[ImportPassion]

Originally Posted by Paul M

1. The mail spool file is located at /home/<cp account>/mail/<mail domain>/<mail account>/inbox - however, we have a php security setting which prevents apache from breaking out of the /home/<account>/html_docs/ to read it. I got round this by writing a little cron job to copy the inbox file to a folder within html_docs once a day.

But doesn't vbouncer either 0 out the file or delete it when it's done with? they way you are doing it, would you not get dupes since the real file is not getting truncated?

[tamarian]

Originally Posted by Paul M

1. The mail spool file is located at /home/<cp account>/mail/<mail domain>/<mail account>/inbox - however, we have a php security setting which prevents apache from breaking out of the /home/<account>/html_docs/ to read it. I got round this by writing a little cron job to copy the inbox file to a folder within html_docs once a day.

Would a sym link bypass this restriction?

2. The problem I haven't got round yet is that something (probably exim) appears to be rewriting the Return-Path to "nobody@<server-domain>" before sending the mails. I'm not sure how to stop this yet, but there must be a way because our live server doesn't do it.

Yes, some settings seem to re-write soem headers. Are you using PHP mail or SMTP? This is usually SMTP. Did you apply the seconf file edit? (It was just added today)

[tamarian]

Originally Posted by 7thgenCivic.Com

But doesn't vbouncer either 0 out the file or delete it when it's done with? they way you are doing it, would you not get dupes since the real file is not getting truncated?

Good point. Yes, vBouncer needs write access to the file, to act like it has downloaded the emails, so they won't be recorded more than once.

Maybe Paul wrote a script to copy it first, then empty it.

But I think a sym link should work. I don't have a control panel, so I can't test this case. Give th sym link a try, and let m know how it goes.

[Paul M]

Originally Posted by 7thgenCivic.Com

But doesn't vbouncer either 0 out the file or delete it when it's done with? they way you are doing it, would you not get dupes since the real file is not getting truncated?

Okay, to be more accurate - I do this once every 24 hours ;

1. Delete the old inbox file from the temp location
2. Move the proper inbox file to the temp location.
3. Process the temp file (I disabled the code that emptied the file).

Any mails after the move simply create a new "proper" inbox, ready to be moved 24 hours later.

Originally Posted by tamarian

Would a sym link bypass this restriction?

I have no idea what a sym link is.

Originally Posted by tamarian

Yes, some settings seem to re-write soem headers. Are you using PHP mail or SMTP? This is usually SMTP. Did you apply the seconf file edit? (It was just added today)

PHP Mail, I have not downloaded it since the beginning of the week. However, I got round the problem with a couple of extra lines in the plugin. No file edit needed.