There was a little discussion a while ago about forwarding mail on the vpopmail list, and how a simple forward, while innocent in itself, then goes on to forward Spam that gets received through normal use. Essentially, a spammer sends my user Spam, we accept it (possibly tagging it through simscan), and we then forward it out because that's what the user wanted, to their local ISP.
Their local ISP's spam scanner then recognizes this spam and is less than impressed with us. I've seen it in my cases, where users will forward to both big (hotmail, AOL, etc) and Small (local) ISPs.
We've found solutions over the years, but none of them are really cleanly implemented.
I was looking at filterto from the qtools package at http://www.superscript.com/qtools/filterto.html and figured this would work out really well, and can easily be added to .qmail files.
One thing I'm looking for is to essentially have qmailadmin determine if the e-mail address is in the same domain (and if it is, just deliver locally), and if it's not, as opposed to adding '&[EMAIL PROTECTED]' to the .qmail file, add '| filterto [EMAIL PROTECTED] /var/qmail/bin/forwardfilter', which would be self-explanitory- run spamc, check the return, and return 0 to forward or anything else to move on in the .qmail file.
What is involved in getting qmailadmin to drop a more custom prefix/suffix to the e-mail address? To my knowledge, it'd be the only thing that would need to be changed, as vpopmail would do the right thing with the pipe (though alternately, it'd be interesting to see if this is more efficiently built right into vdelivermail into the qmail_inject_*() process or even parsing process (check_forward_deliver() or deliver_mail()'s 'must be an email address' section)?
Thoughts?
I guess another part of it is:
1. what would be easiest on the user (no changing of interfaces, ec)
2. which application is more efficient
3. which application is more volitile (ie: will any patch need to be updated every release- qmailadmin will just treat it as a program, but would it break vdelivermail?)
4. is it better coded into vdelivermail or would it better be a seperate application?
5. Would a qmail-inject wrapper be simpler, and an update to QMAILINJECT to make it pass on the file descriptors (I'd imagine like qmail-queue replacements).
-M
Their local ISP's spam scanner then recognizes this spam and is less than impressed with us. I've seen it in my cases, where users will forward to both big (hotmail, AOL, etc) and Small (local) ISPs.
We've found solutions over the years, but none of them are really cleanly implemented.
I was looking at filterto from the qtools package at http://www.superscript.com/qtools/filterto.html and figured this would work out really well, and can easily be added to .qmail files.
One thing I'm looking for is to essentially have qmailadmin determine if the e-mail address is in the same domain (and if it is, just deliver locally), and if it's not, as opposed to adding '&[EMAIL PROTECTED]' to the .qmail file, add '| filterto [EMAIL PROTECTED] /var/qmail/bin/forwardfilter', which would be self-explanitory- run spamc, check the return, and return 0 to forward or anything else to move on in the .qmail file.
What is involved in getting qmailadmin to drop a more custom prefix/suffix to the e-mail address? To my knowledge, it'd be the only thing that would need to be changed, as vpopmail would do the right thing with the pipe (though alternately, it'd be interesting to see if this is more efficiently built right into vdelivermail into the qmail_inject_*() process or even parsing process (check_forward_deliver() or deliver_mail()'s 'must be an email address' section)?
Thoughts?
I guess another part of it is:
1. what would be easiest on the user (no changing of interfaces, ec)
2. which application is more efficient
3. which application is more volitile (ie: will any patch need to be updated every release- qmailadmin will just treat it as a program, but would it break vdelivermail?)
4. is it better coded into vdelivermail or would it better be a seperate application?
5. Would a qmail-inject wrapper be simpler, and an update to QMAILINJECT to make it pass on the file descriptors (I'd imagine like qmail-queue replacements).
-M
