vBulletin Mods

The Official vBulletin Modifications Site
https://www.vbulletin.org/forum/showthread.php?t=83486

-=Sniper=- 22 Jun 2005 23:16

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.

Spinball 22 Jun 2005 23:31

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?

tamarian 22 Jun 2005 23:34

Quote:

Originally Posted by -=Sniper=-
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.

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.

tamarian 22 Jun 2005 23:46

Quote:

Originally Posted by Spinball
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:

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

-=Sniper=- 23 Jun 2005 01:07

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.

Quote:

Originally Posted by tamarian
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.


Spinball 23 Jun 2005 09:55

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 24 Jun 2005 14:45

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 24 Jun 2005 21:38

Quote:

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 25 Jun 2005 10:24

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 26 Jun 2005 19:01

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

Paul M 26 Jun 2005 20:02

Quote:

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 "[email protected]<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 26 Jun 2005 21:40

Quote:

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 26 Jun 2005 21:43

Quote:

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?

Quote:

2. The problem I haven't got round yet is that something (probably exim) appears to be rewriting the Return-Path to "[email protected]<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 26 Jun 2005 21:55

Quote:

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 26 Jun 2005 22:01

Quote:

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.

Quote:

Originally Posted by tamarian
Would a sym link bypass this restriction?

I have no idea what a sym link is.

Quote:

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.


All times are GMT. The time now is 21:52.

Powered by vBulletin® Version 3.8.14
Copyright © 2021, MH Sub I, LLC dba vBulletin. All Rights Reserved. vBulletin® is a registered trademark of MH Sub I, LLC
Copyright ©2001 - , vbulletin.org. All rights reserved.