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:

https://vborg.vbsupport.ru/showthrea...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.