vBulletin Mods

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 :)

This post will be used for an updated FAQ and How-To's

How it works
1. vBouncer makes your forum send emails with a modified "Return-Path" header including the vBouncer emaila ddress, so most ISP's will send bounce notices to that email (instead of the webmaster email).
2. When ISP's send the bounced notices, those notice emails are stored in the mail spool of vBouncer. Most will tag those notices with a "Final-Destination" header stating the email address that bounced.
3. The vBouncer cron task (vBouncer-collect.php) checks the spool file and extracts all email adresses that are bouncing, and store them into a database table, if they belong to a forum member. It wil then empty the spool file.
4. If you selected auto processing, the vBouncer cron task (vBouncer-clean.php) reads the table and stats, and executes the options you chose to apply in your vBouncer settings. The database table will pruned from any old data.

Email setup: For vBouncer to work, you need to:
1. Create a new email account on your server, and that email account has to be unique, and only used for this purpose, collecting bounced emails.
2. This account should not be POP'ed or deleted by any user, only vBouncer should delete them.
3. The vBouncer emails should be in a regular spool file (text file). This is standard on SendMail and PostFix. Not sure about Qmail, Exim or Windows, but they should able to do it. (Anyone with experience in those systems, please let me know)
Please check with your server admin how to accomplish this.

Tips:
If you can't make your mail server spool to a single text file, you may want to try the (dot)forward file method:
http://publib16.boulder.ibm.com/pser...es/forward.htm
See post #3 below for further details on mail servers.

IMAP settings
You may need to add "notls" in the IMAP string, if you encounter problems:vBouncer Settings The comments on the vBouncer settings page are verbose, but here are the important ones with additional comments.

Post notification sender email
This is the email vBouncer will use to send new reply notification. You need to create a unique email address for this. Bounced emails will be returned to this email address on your site/server domain. This email account should not be downloaded, and must be left waiting, vBouncer will pick it up.
Example: [email protected]

Full path to email spool file
This is the full path to where the mail spool file resides. This is where bounced email notifications are sent back to the post notification email.
Example: /var/spool/mail/subscriber_notify
(Use the diagnostics option to sure the file is readable and writable)

Maximum unique members to process per run
Processing the mail log file will stop when this limit is reached. If your logs repeatedly excede this number, it is better to run the scheduled vBouncer collect task more frequently, instead of making this limit too high, for performance reasons. Example 100

Auto processing mode?
You have the option to either let vBouncer automaticly change subscription levels for members with bouncing emails, or choose no if you prefer to simply decide based on the stats of bouncing emails.
Yes No
(Choose no, if you just want to monitor the stats)

Bounce limit
If you selected auto-processing, how many bounced email notices should be acted upon?. (Only works in auto mode) Example: 50

Bounce limit period
Enter the number of days in which the bounce limit set above will be applied. (Only works in auto mode) Example: 7

The above two options results in setting a limit of X email bouncer per Y days period.

Send Notification PM
PM Sender ID
PM Sender Username
Send PM warning
Warning Limit
Change default subscription level to no email
Change subscribed threads to no emails
Change subscribed forums to no emails
Change usergroup for bouncing members?
Destination usergroup
Protected usergroups
Untouchable usergroups
These options control what actions to do with members who excede the set limits.

Note: If you use vBouncer's IMAP/POP method, you do not need to follow the instructions here. This is only for those who prefer to use mail spool files.

Spool files How-To

This post addresses the location and setup of spool files on different mail server software. You will only need it if you can't find your mail spool file, or don't have one.

Sendmail: Sendmail by default spools the emails for each email address into a text file. Usually found in /var/spool/mail/account_name (account_name is the account in the email address, like subscriber_notify, for example)


Postfix: Postfix, like Sendmail, spools the emails for each email address into a text file. Usually found in /var/spool/mail/account_name (account_name is the account in the email address, like subscriber_notify, for example)

QMail: (Thanks to Merk for testing and providing the information) QMail, by default stores emails in Maildir format, new file for each email. In order to spool emails to a single file, you need to do the following steps:

In the home directory of the user account (subscriber_notify), create a file called .qmail the content of that file should be a single line indicating the file path where you want the emails to be stored:

/var/spool/mail/subscriber_notify

Or any path you choose. The file needs to exist, so we can first create it by using the touch command:

touch /var/spool/mail/subscriber_notify

And it needs be readable and writable by PHP, so use the chmod command:

chmod 666 /var/spool/mail/subscriber_notify


Vpopmail+QMail: (Thanks to Merk for testing and providing the information) For vpopmail, a user doesnt have a home directory, and it dosent go into the users virtual mail directory either, it sits just below that in the domain's "root" directory. /home/vpopmail may be different for some users.

/home/vpopmail/domains/domain.com/.qmail-subscriber_notify for [email protected] (contents as above)

The contents of the .qmail file are still the same described above for QMail. You just need to follow the same steps to create .qmail file and the file to spool the emails too.



Exim+cPanel: (thanks to Paul M for this tip)

Note, before you do this, check this post:

http://www.vbulletin.org/forum/showp...&postcount=101

It may be best to avoid changing the config of Exim, and just use the IMAP/POP option in vBouncer.

In the exim config file ( /etc/exim.conf ), near the bottom is a section that begins with virtual_userdelivery: - in that section is a line which says mode = 0660 - change this to mode = 0666

In your cpanel account, for address [email protected]

The path needs to be " /home/<cpaccount>/mail/domain.com/rejects/inbox "

The mail, domain.com & rejects folders all need chmod'ing to 755.

The mailbox file can then be set to 666, and it will work.


Windows Mail Servers: Still waiting for testers and information


----------------------------

If your server is running Exim or a Windows mail server, please post here:

http://www.vbulletin.org/forum/showthread.php?t=83407

Once the information is provided (in that thread), and we get you up and running, the instructions for those specific mail servers will be posted here.

Note that it may actually work out of the box even if you don't have SendMail or PostFix. If you have a text file on your server that can store the emails for a specific account, then you're all set. It's just that I have no experience with those systems, so I don't know.

This looks quite interesting, I might put this on our test server, we run exim, but I'm not sure how it works ....

A new zip has been uploaded, there was a bug in the user group demotion option (hardcoded 1, instead of the chosen destination groupid)

Paul, I look forward to some good news :) It would be nice to know how to setup Exim, Qmail or Windows, so this would work for all.

coool :D - just what i mod requested for ;)

I will be using this on a live system when a qmail system has been tested.

I am willing to provide a server to test it on, if needs be.

Great work. :D

Good idea.

Seems like this saves on resources like bandwidth and storage, rather than server load...


Also this does not seem too applicable to users who are in a shared hosting enviroment...

will give it a shot. Nice hack

We need a QMail system with someone who knows how to admin it :) Check this thread for more details:

http://www.vbulletin.org/forum/showthread.php?t=83407

Both actually. But server load problems are harder to solve than bandwidth. Consider having many threads with thousands of subscribers in the instant email mode. This will spike your server on new replies. But it doesn't hurt that it also saves bandwidth :)

Correct. As stated, it is for busy forums. However, it can run in a shared/virtual environment, if the host can move your mail storage to your space (some control panels do that). For Sendmail and PostFix, this is as easy as a symlink.

Hmm, thats what I thought, I'll be checking into it for cpanel, as I already got a request from one of my custers for it :p

Please post any tips and hints from your experience here:

http://www.vbulletin.org/forum/showthread.php?t=83407

My plan is to compile a list of steps on the various setups to spool emails of one account to a file, and update post #3 with it.

could I use this so if I send out emails to users awaiting confirmation any bounces would go to the same account so they can be moved deleted etc with vBouncer.

Well done tamarian - it's on the way to answering the request in this thread
http://www.vbulletin.com/forum/showthread.php?t=91176
May I suggest the possibility of analysing the emails to determine those with permanent errors so those members can be moved to the 'awaiting email activation' group after just 1 bounced email?

You mean from the admin panel email form? That email form asks you to enter the "From" field, and it fills it with the webmaster email by default. If you enter the vBouncer email instead, then it should work, as this will automatically form the "Return-Path" with the vBouncer email address.

So it seems to work by accedent :) as I have not thought of this when I wrote it.

You mean:

1. identify and store the error codes/status of the bounces
2. Allow specific actions to be taken against emails generating specific error codes, regardless of not reaching the allowed bounce tolerance limit

I like your ideas :D

yes thats what I mean! I guess thats a extra free feature.

Because some users register thinking they don't have to confirm, so they never validate the account. This could solve the issue where much.

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.

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).

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.

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!!

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:

http://www.vbulletin.org/forum/showt...threadid=91119

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.

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?

Would a sym link bypass this restriction?

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)

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.

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.

I have no idea what a sym link is.

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.

ln -fs /home/example/mail/example.com/subscription_bounces/inbox /path/to/admincp/subscriber_notify

Now you should be able to use /path/to/admincp/subscriber_notify as the file location (also make it chmod 666

It's not in the zip file. There are file edits in class_mail.php ( vBouncer is no longer a plugin) due to code needed for the header re-writes.

sym link no work either.

also, I added a clearstatscache() before the diagnostics happen

can you post the cron job you have that copies the file etc?

Use the -f flag within PHP mail function to declare the sender address.

What didn't work? The diagnostic, or the log collection cron task? Was the link and the target both 666?

The "-f " is added by the code edit, so it's on regardless of the vB settings :)

Nope - the shortcut is created correctly, but it doesn't bypass the security, php still cannot read it.

So I see, but as I said - I got round it by changing the plugin to this ;

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

The pregreplace is not actually required by myself, but I left it in.

Sure;

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

zmail is a folder I created just for this system. I put the above in a file which is run via cron once a day.

:)

My next problem is that it's failed to detect the bounced e-mail message.

Was there any bounced emails in the file? Check the scheduled tasks log to see the output summary. Once you have bounced emails in the box, save me a copy and send it, so I can check the headers. :)

As to why the symlink doesn't work, I'm not sure, as I don't use cpanel. Check the apache error log, there might be some clues.

Paul, buro9 and 7thgen:

Are you guys on similar setups? CPanel+Exim?

If so, there might be an alternative solution. Exim allows forwarding through .forward file and can use pipe the emails to the shell. So if the symlink for some reason doesn't work, you might be able to capture the emails to an alternative file within your public_html space.

Well that's basically what I'm doing anyway by moving the spool once per day. I'm quite happy to process the rejects daily. That bit works now.

To answer your other question - yes, the file had exactly one rejected e-mail in it that i did as a test.

The reject headers are ;

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

(Some addresses changed obviously)

Yeah, Cpanel + Exim here :)

Paul, I'd like you to do a little test for me. Send several test emails from the vB diagnostics in the admin panel. Send them to bogus83y4ds (something not likely to be a real email) @ aol, comcast and hotmail, and show me the full content of the bounce file afterward, including the attachments (by PM if you prefer).

The header you showed will not be picked up by vBouncer since it's not RFC compliant, I think. Exim maybe re-writing them. If AOL, Comcast and hotmail result are in the same format, then Exim on your server might be intefering, since those ISP's do send (most of the time) RFC compliant non-delivery.

Sure - I'll PM you the results.

vBouncer 0.4 now works as a plugin, without code changes. (Thanks to Paul M)

To upgrade from 0.2 or 0.3, simply delete the old plugin and replace with the new one.

Thanks tamarian!

I am also on cPanel/Exim. Will be upgrading my server to a new box this month, but I anticipate that will be the same as I believe this is core cPanel behaviour on mail handling -- I don't think it is an option?

I will gladly help with testing as well. Just let me know what you would like done.

Well, with a few bits of suitably placed sticky tape - I have a working system on cpanel / exim. I think tamarian will be producing an update later.

For now, there's a temporary solution to access the mail spool file, which Paul has posted. A cron script to copy the file to the public_html area, then reset the original.

A better solution, IMHO, is to use the dot-forward file method (a feature available on all these mail packages, including Exim) to directly pipe the file to another in the public_html area. I'm still looking for the correct format, but if anyone knows, please share.

Another problem with Exim, is re-writing the headers for the bounced files, which will be missed by the current log collector. I'll release an updated version to capture those.

Does the CPanel/Exim show an option to forward to a file?

The PHP restriction you speak of, would it happen to be open_basedir?

I use this extensivly across my enviroment.

All you have to do is add a single path to the directory block of the vBouncer files that allows php to access the path to the spool file.

If it isnt open_basedir, im not sure :)

What do you mean by "add a single path to the directory block"?

I suspect CPanel might be chrooting the seperate systems, but I'm not sure, since I don't use it. But I can try to override the php.ini to see if that helps.

PHP has a "safe mode" system called open_basedir, it restricts PHP from going areas it isnt allowed to go into. It is controlled via php.ini, httpd.conf or .htaccess.

I do my modifications for each virtual site on my system in httpd.conf (using php_admin_value so that it cant be overridden by .htaccess).

Something like the following will allow PHP scripts to access /www/sitename, /tmp and /var/spool/mail (and outside of these paths will result in an error):

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

Now, you'd have to be careful, and probably put subscriber_notify in its own directory.

Oh, and this wont help you if you're in a chroot enviroment :)

Good tip, Tim. Let's see if any of our CPanel+Exim users can test it. Should be fine security-wise since the spool has it's own directory:

/home/example/mail/example.com/subscription_bounces/inbox

The only issue is if cpanel is adding its own directories to the variable. Youll need /tmp or your equivilant temp directory otherwise attachments/avatars wont work.

I'd already disabled open_basedir so I don't think this is the problem.

I had disabled it ages ago because I needed a Wiki to use the system DIFF utility.

I'll give it a whirl and let you know though (the htaccess segment that is).

The default open_basedir on cpanel is roughly:

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

It's applied per domain within the httpd.conf file.

I've added /home/EXAMPLE/mail to the value and will shortly check it :)

Nope... diagnostics still fail all three file tests.

It's not open_basedir :)

version 0.5 released: Option to use custom header strings to identify bouncers. (Example, some Exim users may need to enter 'X-Failed-Recipients:'.

To upgrade: uninstall, then re-install :)

I would like someone using Exim+Cpanel to test the .forward (dot-forward) file method :)

Here's how it works:

1. Create a file somewhere in your public_html directory /path/to/forum/admincp/subscriber_notify
this file should be readable/writable (666)

2.In your (subscriebr_notify) user home directory, create a .forward file. The .forward file should have one line in it:
/path/to/forum/admincp/subscriber_notify

The theory is that Exim will start forwarding emails to that file.

Not sure what Exim considers "home" directory, so you may need to try creating it in different directories for that user account (subscriber_notify) to test which directory is the right place for .forward

Send an email to subscriber_notify, and check if it was copied to that file. Exim manual states that this should work, so let's keep our fingers crossed. :)

Another request for Cpanel+Exim users. I'm writing a POP maodule as an option instead of reading files. I'll need to test my code (from my home server) with your bouncer email box. If you'd like to volunteer :) please PM me the new account's (subscriber_notify) POP username and password.

The next version will have a POP/IMAP option. This will be useful to those in chroot environments, or those on multiple servers, or using external mail servers.

I have it working, but I need some test volunteers. If you have a POP account for the subscriber_notify account, send me the POP access info by PM. (The worst I can do is delete a couple of bounced emails!) :)

I can't install Exim on my system, since I never used it, and would be time consuming for me.

Great :)

Does PHP need to be compiled with some extra support to connect to POP mailboxes?

Yes, it needs "--with-IMAP". The good news is that control panel configurations (who mostly would need the POP method) usually compile a lot of stuff into PHP.

For those who need to check: See vB's control panel under the phpinfo part in the maintenance/diagnostic section. If you have IMAP compiled, it would have a section titled IMAP and show status as "enabled".

I like the idea, but there might be some kind of security problem: How do you make sure that the bounce is valid? I think this system could be abused to annoy users by selectively sending fake bounces resulting in account deactivation.

That is true.

What I do is enabple a PM warning first, which means the member has 7 days to contact me if these are not really bounced emails.

I don't use the option to change user group, it was only added by request (I also made a warning under that option in the setting :) )


On my forums, the worst that can happen is to change subscription from instant email to "no email". Which means they can still see subscribed threads from the userCP.

A random number/hash could be generated for each email sent and stored so that the system knows its a legimitate email?

Im much worse about bounced email, if it bounces once they get moved to awaiting email confirmation (and a big red warning appears on every page in that group).

I gave this some thought, and concluded that it's best not to do that. Here's why: vBouncer is optimized not to do anything unless a bounced email is found. To implement a hash method, vBouncer will need to run an insert query for every email sent. The hash number will need to be stored in the database for every single thread notification sent. vBulletin will send multiple thread notifications for each new post, relative to the number of members subscribed to that thread, plus an extra qury when a bounced email is received, to match with the hash number sent. This is a huge number of queries, and will defeat the purpose of reducing the server load.

That's why I don't like that option :) I much prefer to let vBouncer run it's course. Send a warning on the first run, and take action on the second run (defult run period is 7 days).

Fair enough, though the system is open to abuse if you think about it. I wonder if there is another solution to either make it harder or impossible to abuse.

I think the abuse would require all the following conditions:

1. Enabling auto processing option
2. And enabling usergroupid change option
3. And allowing members to see other members email addressess (or them finding out the email addresses from the members themselves)
4. And being able to forge emails with correct bounce syntax.

But an alternative would be to ignore forged email headers. I may write some pre-checks, and/or allow the option to call user-defined scripts, like SpamAssasin and the like, to allow returning a true or false answer, and ignore emails based on that answer.

Good point. I dont allow users to see other users email addresses, so that should be enough to make sure its okay?

I am actually testing what seems a very simple answer to the above, which also gives me something consistant to look for in the returned mails.

I use the following code to add two headers to every outgoing e-mail

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

Every system that bounces mail should return the original headers (all that I have tested do) so you get these headers back with all failures.

The bouncer code then scans the inbox looking for all the X-Tracker-Dst headers to get the original destination, and pulls the X-Tracker-chk for each one. It then does the same MD5 calculation and if it's a match it knows it was a genuine bounce. To spoof this - the spoofer would need to know your unique code in order to get the MD5 correct. It also means that all I need to look for in the rejects inbox is these two headers. :)

On a seperate note - I'm going to see if I can figure out why the forum cannot see the mail box - since my vB can see my attachments folder, which is at the same level as the mail folder - it maybe nothing more than permissions.

Edit, okay, it's not permissions. A deeper look required over the weekend.

good idea, solves the query problem :)

I like the idea. But I'm not sure you will get all your headers back, I think it will depend on the ISP. I think AOL would be one of the ISP's that won't give you back all the headers, and some would give it back depending on the bounce type.

But I will test it out, and see if the percentage of those who do return it. If it's reasonably high enough (50+%), I think it would be worth it. An option can be added to see if the admin want to to rely on it, or ignore it.

Maybe a 3rd option, process automatically any email that has the headers to confirm it, and if it doesnt have them, put them in a "manual processing queue"?

I strongly suspect it is due to a (chroot)ed environment. chhroot setup will cause different users to have a distorted view of the system directories. If I login as superuser, my /home /etc /var directories are "real", and mapped to the main directories. If I login as a regular user, my directories are mapped. So when as a regular user I look for /var/spool/mail, in reality it's /home/users/chroot/var/spool/mail. So the path name to the file is not identical to both users.

That's doable. Maybe give it a status/error code of 'no sure', and let the admin decide from the stats page.

I plan to test these headers on a live system, just to see if I really get back a decent percentage of the original headers, this may take a couple of runs to calculate.

To give you guys some heads up, I may release 0.9 tonight for the 3.0.7 version. It has two new features:

1. IMAP/POP support, so those on control panels, or sites with external email servers, or those who just prefer not to deal with mail spools can use it.

2. Custom bounce filters. This is an optional config file that allows you to insert multiple custom regular expressions to match the patterns on bounce emails on your server that vBouncer couldn't catch. There's just too many special cases for each server MTA setup, that I though t's best to allow custom regex, rather than hardcode them. Plus, it will not require me to keep on releasing a new version for each pattern :)

Hi tamarian,

Sorry to offer late, but just getting back to this. Do you still need cPanel access and/or a POP account?

cPanel access is not needed, but would love to test the POP module on an Exim. So if you have a POP account that has bounced emails (or empty and not being used), please PM me the access info :)

Well after further testing - it is a permission problem.

In your cpanel account, for address [email protected]

The path needs to be " /home/<cpaccount>/mail/domain.com/rejects/inbox "

The mail, domain.com & rejects folders all need chmod'ing to 755.

The mailbox file can then be set to 666, and it will work - except - that as soon as another mail is received, exim chmod's the inbox file back to 660, cutting off php's read/write access. I now need to see if I can stop exim doing this.

How about changing the owner (chown) as well? If exim is no longer the owner of the file (but still has write permission) it should not be able to chmod it.

What or who would I set the owner to ? I have fixed it on my test server by changing one line in the exim.conf file - but this may not be possible if you are not on a dedicated server.

Change it to the apache user apache:apache (or if apache runs as nobody, then nobody:nobody).

Note that I'm not recommending people do this :) But it's worth it just to see if that's the culprit.

Version 0.9 is out. New features added:

o Collect logs via IMAP/POP or mail spool file
o Custom filters to match patterns in bounced emails

To upgrade, uninstall, then reinstall through the installation script.

Nope, exim still manages to change it back to 666 - but with the exim config change, it works for me - so I'm happy.

There is always the pop method if people cannot do this. :)


Btw, there is an error in the vbouncer-clean.php ;

Block Disabled:      (Update License Status)
Suspended or Unlicensed Members Cannot View Code.

There is a stray quote after where userid=

Thanks, fixed and uploaded.

Can you write a summary for what cPanel+Exim config needs to be changed, so the spool becomes readable/writable? I'll just add it to the how-to with your name, for those who can (and want to) change their Exim config.

Will do.

I have not installed this on my new server that is now serving as my test site (as of Sunday) and I am still getting it set up.

What all do I need to do to set this up -- just apply the hack, or do I need to do any of Paul's addons?

In the exim config file ( /etc/exim.conf ), near the bottom is a section that begins with virtual_userdelivery: - in that section is a line which says mode = 0660 - change this to mode = 0666 . Then chmod the inbox file to 666 as I previously mentioned (and the directory structure leading to it as previously described).

Paul,

Are you running exiscan-clamav or clamav connector or anything similar?

Thanks!

Never heard of it, so I guess not. :)

Yes, just install the new vBouncer (0.9), and wait it for it to collect some bounced emails. You can test the POP yourself first. If there are problems with th ePOP method, I'll take a look.

Cool, the how-to is updated. Let me know if I messed it up :)

They are Exim filters for viruses.

Tamarian -- will get that set up for you tonight when the guys at my host finish with the kernel upgrade (that should have been done when it was configured :speechless: ).

If my results differ from Paul's, please note that I am running ClamAV, so we may need to document that.

If you use the POP/IMAP method, the Exim config edit is not required, since you will not need to access the spool file directly.

I'll write up any Exim hints and tips you guys give me, since you have the cPanel+Exim setup. :)

Sent you a PM with some setup thoughts.

Do have a question on this though -- what does it do with bounced emails from new registrations? We delete registrations whose emails bounce and I don't want those to be included in the same tracking/warning as the ones who are subscribing to threads.

Second question -- does this (or will it plan to) address those who have email notifications on PMs in that it will remove this flag from their profile? I would even go as far as to say that if their email is bad, I would like ALL subscriptions and email notifications to be disabled.

You can exclude usergroups from the settings menu under "Protected usergroups" (to prevent usergroup changes" Or under "Untouchable usergroups" to prevent any actions such unsubscribing or PM's.

But if they register with a wrong email, you'd only get 1 or two bounces. If your bounce limit is 25 or 50, they wouldn't be affected.

It's doable if you guys really want it.

But the main purpose for vBouncer is to prevent server spikes due to the volume of emails generated during busy hours for new replies and subsequent notifications of new replies. Reducing this volume through unsubscribing bouncing members is the main purpose.

An occasional email to notify about a PM doesn't have that impact on the server

Update on the MD5 idea to check for forged bounced emails:

So far it seems most bounced emails will return the full original headers. The only exception I've seen so far is AOL, and only in the case when the AOL member in question rejects emails from your forum (i.e they are blocking your email from getting into their mail box.

So currently my upcoming version does the following:

1. Adds a new setting to enter your MD5 encryption string. If you leave it empty, it will not send the new header, and will process bounced emails as authentic. So it acts like an enable/disable option.

2. If you enter an MD5 encryption string, it will send the header out with outgoing email, but it will only check for them depending on the rules you set in vbouncer.inc pattern config file. This is done to allow the check to be turned on and off based on each pattern defined. If you define a pattern for AOL-sender-block (already defined in vbouncer.inc), you can set the check to no, so it will not ignore tham due to lack of the header.

3. If an MD5 header is defined, and the pattern requires the MD5 header, then it will ignore/skip bounced emails that do not have the header, or have the header but it did not match the MD5 key.

4. No additional manual queue to seperate which is which, since it's quite controllable by the settings, and only a small percentage (less than 1%) of bounced emails (in my logs at least) fall under this case.

So this is tested and running right now and ready for release as 1.0, let me know what you think.

I think I should read you post more carefully next time, I just re-installed it expecting to see this :(

LOL, c'mon, you don't even need to wait, I expect you already have a separate branch with a working version :) I plan to release it tomorrow, just wanted to confirm the stats with a decent sample of bounces.

I also get the following in my ACP

Warning: imap_open(): Couldn't open stream in /admincp/vbouncer.php on line 143

I'm not using the POP/IMAP option.

You mean in the diagnostics page? That should be fine, I just thought I'll let it show everything that can work or not work, regardless of chosen option, for fiagnostic purposes.

Um, okay - it's a bit distracting getting an error message for something I don't use.

Anyway, the diagnostics show this ;

vbouncer.ini file exists = Passed
vbouncer.ini file is readable = Passed

But the cron log shows this : vbounce.ini not found, or empty. Only processing standard reports.

The file in the zip, which I uploaded appears to be called vbouncer.inc (not ini)