vBulletin Mods

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

tamarian 28 Jun 2005 01:12

Quote:

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

CB|Steffen 28 Jun 2005 19:37

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.

tamarian 28 Jun 2005 19:45

Quote:

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

merk 29 Jun 2005 00:12

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

tamarian 29 Jun 2005 15:42

Quote:

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

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.

Quote:

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

merk 30 Jun 2005 02:25

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.

tamarian 30 Jun 2005 02:40

Quote:

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

merk 30 Jun 2005 02:43

Quote:

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

Paul M 02 Jul 2005 04:37

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

Paul M 02 Jul 2005 04:39

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.

merk 02 Jul 2005 04:52

good idea, solves the query problem :)

tamarian 02 Jul 2005 05:42

Quote:

Originally Posted by Paul M
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. :)

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.

merk 02 Jul 2005 06:11

Quote:

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

tamarian 02 Jul 2005 14:31

Quote:

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

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.

tamarian 02 Jul 2005 14:44

Quote:

Originally Posted by merk
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"?

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


All times are GMT. The time now is 10:42.

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.