Re: [vchkpw] Spamassin configuration
on 3/3/05 12:03 PM, Tom Collins <[EMAIL PROTECTED]> wrote: > On Mar 3, 2005, at 8:54 AM, Nick Harring wrote: >> No, it wouldn't require this. It would require that you edit the >> recipient list prior to queueing. There's nothing 'ugly' that I can see >> about that process. > > I think Nick's method would work for those who want to block anything > that scores as spam but not modify message headers. > > For others, like myself, who want to block at 10+ but tag as spam > anything with 5+, it will not work. In my case, each user would need > their own, custom copy of the email with the headers (and possible > rewritten message) based on their personal scoring configuration. > > I kind of like my original idea though, but would want to collect some > stats before implementing it. My idea is pretty simple -- for > non-relay hosts, after the first RCPT TO is accepted, reply to all > additional RCPT TO requests with a 4xx result. > > How many messages come into a server for multiple recipients in the > same domain? Practically all spam coming to my server comes to multiple recipients. For non-spam messages this is much less frequent. > I guess if someone was mailing multiple people at the > same company, it would happen. But with most mailing lists using > custom bounce messages for each recipient, they wouldn't be affected. > > How about the spammers who email 100's of random usernames in a domain, > hoping to hit valid addresses? The 4xx response would at least slow > them down (and even stop them if their spam programs don't retry 4xx > responses). > > The biggest downside I can see is if someone sends a large email (say > with a file attached) to multiple people in one domain, then sending > server will have to push it through multiple times. Here is another possibility that comes to mind as a "transparent" solution. I don't know whether the scanner can be configured to work this way: Scan the incoming message based on each of the multiple recipients' settings. If *all* users agree to reject, then reject it at the SMTP level. In any other case mark the mail with a provisional spam status header line which indicates that scanning must be deferred until delivery time. Messages without the provisional status line are not scanned at delivery time. -Kurt
Re: [vchkpw] Spamassin configuration
on 3/3/05 8:54 AM, Nick Harring <[EMAIL PROTECTED]> wrote: >>> Simscan isn't replacing qmail-smtpd, so this isn't strictly an smtp >>> limitation. Perhaps I'm just not getting it, but why wouldn't the >>> following work: >>> Email comes in for users A, B and C. A and B have an SA threshold of > 5, >>> C has a threshold of 9. The message scores at 7. Delete A and B from > the >>> recipient list when queueing the message, and tell qmail-smtpd to > accept >>> the message since at least one recipient will be receiving the > message. >>> Since the other two users consider it spam, they don't really care > what >>> the remote side thinks. Other scenarios are just as easy to work > through >>> in a way that'd work. >> >> that would require queueing multiple messages from the same SMTP >> conversation. >> >> what happens if on the 49th recipient of a 50 recipient message, the >> queueing >> fails? Your 'solution' is ugly, and simply will not work. >> > No, it wouldn't require this. It would require that you edit the > recipient list prior to queueing. There's nothing 'ugly' that I can see > about that process. If I'm understanding you, I see one real problem with your suggestion. Tom said it clearly: on 3/2/05 4:12 PM, Tom Collins <[EMAIL PROTECTED]> wrote: > One of the benefits of simscan is that it rejects the spam. So, if a > legitimate message gets tagged as spam for some reason, the sender will > get the rejection notice and know that it wasn't received. If I understand your suggestion, a legitimate sender in your example scenario gets no notification that users A and B did not receive the message. -Kurt
Re: [vchkpw] Spamassin configuration
On Wed, 2 Mar 2005, Ken Jones wrote: We are using it in vhostadmin to build a php based management interface. Since vpopmaild can be run under tcpserver (over ssl if you need), it lets management interfaces to run on any computer and access vpopmaild over the net. I have a development version of vhostadmin I need to package up for release. If any one wants a copy of it before we pretty it up, email me and I'll send you the tarball. That sounds interesting. My main "right now" interest is not in replacing qmailadmin just yet, but in stealing your .qmail manipulation code. I've got vpopmaild working with 5.4.x here and I've got Rick's (?) php objects, but I'm right back at square one with replacing my current .qmail modification junk since there's no high-level objects in Rick's set. My current squirrelmail plugin for turning spamass on/off, setting forwards, vacations, etc. calls a setuid vpopmail C program. I want to get away from that for various reasons, but the first is to allow another option, virus scanning. The rewrite involved is painful enough to merit a switch to vpopmaild/php I think. Thanks, Charles Cheers, Ken Jones
Re: [vchkpw] Spamassin configuration
> How many messages come into a server for multiple recipients in the > same domain? I guess if someone was mailing multiple people at the > same company, it would happen. But with most mailing lists using > custom bounce messages for each recipient, they wouldn't be affected. > > How about the spammers who email 100's of random usernames in a domain, > hoping to hit valid addresses? The 4xx response would at least slow > them down (and even stop them if their spam programs don't retry 4xx > responses). We actually see a fair amount of messages come in for multiple valid users under one domain. They're usually messages of the style "meeting at lunch" and similar things, sent from some office manager to several staffers. These are sometimes sent from home accounts (users don't have the best email practices...). Maybe it would be best to defer the messages after some number of recipients? Something like accepting the first 5 or 10, the 4xx responses for anything after that? I think I've only ever seen maybe two or three *valid* messages with hundreds of recipients -- most of the valid messages with multiple recipients seem to have less than about 10 recipients. -Bill * Waveform Technology UNIX Systems Administrator
Re: [vchkpw] Spamassin configuration
On Mar 3, 2005, at 8:54 AM, Nick Harring wrote: No, it wouldn't require this. It would require that you edit the recipient list prior to queueing. There's nothing 'ugly' that I can see about that process. I think Nick's method would work for those who want to block anything that scores as spam but not modify message headers. For others, like myself, who want to block at 10+ but tag as spam anything with 5+, it will not work. In my case, each user would need their own, custom copy of the email with the headers (and possible rewritten message) based on their personal scoring configuration. I kind of like my original idea though, but would want to collect some stats before implementing it. My idea is pretty simple -- for non-relay hosts, after the first RCPT TO is accepted, reply to all additional RCPT TO requests with a 4xx result. How many messages come into a server for multiple recipients in the same domain? I guess if someone was mailing multiple people at the same company, it would happen. But with most mailing lists using custom bounce messages for each recipient, they wouldn't be affected. How about the spammers who email 100's of random usernames in a domain, hoping to hit valid addresses? The 4xx response would at least slow them down (and even stop them if their spam programs don't retry 4xx responses). The biggest downside I can see is if someone sends a large email (say with a file attached) to multiple people in one domain, then sending server will have to push it through multiple times. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
Re: [vchkpw] Spamassin configuration
On Thursday 03 March 2005 10:54 am, Nick Harring wrote: > I attempted to use the archive of the simscan list, and found one > discussion which ended with the abrupt declaration from you that it > couldn't be done. Perhaps you could point me at a thread where there's > real discussion of this? I will find this for you. > Also, would it be more effective if I simply submitted a simscan patch > which implemented the functionality I'm talking about, to show it can be > done (or to learn it can't) rather than discussing how it could? sure. It won't get added to simscan (unless you've thought of some way to do it that I have not, that isn't mind-numbingly stupid), but feel free to submit a patch. -Jeremy -- Jeremy Kitchen ++ Systems Administrator ++ Inter7 Internet Technologies, Inc. [EMAIL PROTECTED] ++ www.inter7.com ++ 866.528.3530 ++ 815.776.9465 int'l kitchen @ #qmail #gentoo on EFnet IRC ++ scriptkitchen.com/qmail GnuPG Key ID: 481BF7E2 ++ jabber:[EMAIL PROTECTED] pgpB3ORmVmvJZ.pgp Description: PGP signature
RE: [vchkpw] Spamassin configuration
> > > > Simscan isn't replacing qmail-smtpd, so this isn't strictly an smtp > > limitation. Perhaps I'm just not getting it, but why wouldn't the > > following work: > > Email comes in for users A, B and C. A and B have an SA threshold of 5, > > C has a threshold of 9. The message scores at 7. Delete A and B from the > > recipient list when queueing the message, and tell qmail-smtpd to accept > > the message since at least one recipient will be receiving the message. > > Since the other two users consider it spam, they don't really care what > > the remote side thinks. Other scenarios are just as easy to work through > > in a way that'd work. > > that would require queueing multiple messages from the same SMTP > conversation. > > what happens if on the 49th recipient of a 50 recipient message, the > queueing > fails? Your 'solution' is ugly, and simply will not work. > No, it wouldn't require this. It would require that you edit the recipient list prior to queueing. There's nothing 'ugly' that I can see about that process. > > yes, and again this has all been discussed on the simscan mailing list. > Please read the several threads there, paying close attention to my posts. > I > cover most of these issues in detail. > > -Jeremy I attempted to use the archive of the simscan list, and found one discussion which ended with the abrupt declaration from you that it couldn't be done. Perhaps you could point me at a thread where there's real discussion of this? Also, would it be more effective if I simply submitted a simscan patch which implemented the functionality I'm talking about, to show it can be done (or to learn it can't) rather than discussing how it could? Nick Harring Sr. System Administrator Parus Interactive
Re: [vchkpw] Spamassin configuration
On Thursday 03 March 2005 08:59 am, Nick Harring wrote: > > > > > I don't think vdelivermail or vpopmail in general should be > > calling > > > > > > spamc/spamassassin. Let that be handled elsewhere. Let's stick > > to > > > > > > delivering mail and deciding where it goes. > > > > > > > > However, lets remember that if spam is only scanned at the MTA > > level, > > > > > SpamAssassin user preferences will not function if the e-mail is > > > > addressed to more than one sender. Scanning in vdelivermail, at > > the > > > > MDA > > > > > > > level, does not have this restriction. For that reason I still > > think > > > > > there is value in scanning in vdelivermail. > > > > > > Obviously this is a current limitation in simscan > > > > no, it's a limitation in how SMTP works. This has been discussed on > > the > > > simscan mailing list several times, please read my posts there. > > Simscan isn't replacing qmail-smtpd, so this isn't strictly an smtp > limitation. Perhaps I'm just not getting it, but why wouldn't the > following work: > Email comes in for users A, B and C. A and B have an SA threshold of 5, > C has a threshold of 9. The message scores at 7. Delete A and B from the > recipient list when queueing the message, and tell qmail-smtpd to accept > the message since at least one recipient will be receiving the message. > Since the other two users consider it spam, they don't really care what > the remote side thinks. Other scenarios are just as easy to work through > in a way that'd work. that would require queueing multiple messages from the same SMTP conversation. what happens if on the 49th recipient of a 50 recipient message, the queueing fails? Your 'solution' is ugly, and simply will not work. > I know people think that it makes some huge difference in their spam > receipt levels whether they reject spam during smtp or not, however I've > not seen anybody actually try and prove it, so until then I'm skeptical. > > I would really like to be able to use this solution, but using server > defaults or the first users preferences are just flat out wrong ways of > handling email. unfortunately, when scanning at the SMTP level, that's all you have. If you want per-user filtering preferences, scan at delivery time. Simple as that. > They're not only wrong conceptually, but are a huge > breach of the users trust. They setup custom settings with the > understanding those settings would be used. yes, and again this has all been discussed on the simscan mailing list. Please read the several threads there, paying close attention to my posts. I cover most of these issues in detail. -Jeremy -- Jeremy Kitchen ++ Systems Administrator ++ Inter7 Internet Technologies, Inc. [EMAIL PROTECTED] ++ www.inter7.com ++ 866.528.3530 ++ 815.776.9465 int'l kitchen @ #qmail #gentoo on EFnet IRC ++ scriptkitchen.com/qmail GnuPG Key ID: 481BF7E2 ++ jabber:[EMAIL PROTECTED] pgpDM9LOiJNEU.pgp Description: PGP signature
RE: [vchkpw] Spamassin configuration
> > > > I don't think vdelivermail or vpopmail in general should be calling > > > > spamc/spamassassin. Let that be handled elsewhere. Let's stick to > > > > delivering mail and deciding where it goes. > > > > > > However, lets remember that if spam is only scanned at the MTA level, > > > SpamAssassin user preferences will not function if the e-mail is > > > addressed to more than one sender. Scanning in vdelivermail, at the > > > > MDA > > > > > level, does not have this restriction. For that reason I still think > > > there is value in scanning in vdelivermail. > > > Obviously this is a current limitation in simscan > > no, it's a limitation in how SMTP works. This has been discussed on the > simscan mailing list several times, please read my posts there. > Simscan isn't replacing qmail-smtpd, so this isn't strictly an smtp limitation. Perhaps I'm just not getting it, but why wouldn't the following work: Email comes in for users A, B and C. A and B have an SA threshold of 5, C has a threshold of 9. The message scores at 7. Delete A and B from the recipient list when queueing the message, and tell qmail-smtpd to accept the message since at least one recipient will be receiving the message. Since the other two users consider it spam, they don't really care what the remote side thinks. Other scenarios are just as easy to work through in a way that'd work. I know people think that it makes some huge difference in their spam receipt levels whether they reject spam during smtp or not, however I've not seen anybody actually try and prove it, so until then I'm skeptical. I would really like to be able to use this solution, but using server defaults or the first users preferences are just flat out wrong ways of handling email. They're not only wrong conceptually, but are a huge breach of the users trust. They setup custom settings with the understanding those settings would be used. Nick Harring Sr. System Administrator Parus Interactive
RE: [vchkpw] Spamassin configuration
So let me see if I can summarize where this might be going. A lot has been talked about on this topic. Use the pw_uid/pw_gid to check and see if a user wants their mail filtered. I'd also suggest setting another bit for delivery. So we'd have a bit that says scan for spam and a bit that says deliver to domain default spam folder (.SPAM or whatever) or not. This would handle both the problem of if the user wants their mail scanned and the disposition of the scanned mail. The user's only options for tagged spam are to deliver to inbox so they can filter or deliver to a predetermined spam container that the domain administrator specifies. vdelivermail would pull the delivery location for spam from it's command line or from the domain limits file. I also think spamc options should be stored in the same place. vdelivermail would call spamc. Personally, I don't think we should offer the ability to call Spamassassin directly. It's just not as efficient. Maybe the spamc functionality could be compiled right into vdelivermail so no forking is necessary. That would be slick! Sound about right? Have I missed anything? Charlie -Original Message- From: Ken Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 02, 2005 7:14 AM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spamassin configuration On Wednesday 02 March 2005 12:22 am, Charles J. Boening wrote: > I guess the pw_gid/pw_uid fields are numeric. Yeah. bit flags. > Saving a file open/read/close is a good idea if possible. That's why > I was thinking if the current vpasswd/database structure could be > modified it wouldn't be too bad. I think it's worth trying to not have those operations if possible. Efficency! > I still don't know if I'd be sold on a compile time option. I just > don't think it's as flexible. Which begs the question does it need to > be that flexible. I guess by reading options from a database it makes > it easier when you go to upgrade. One less option to remember while > compiling. :) yeah, we do have a huge number of config options. > Would another option be to pass the spam directory as an option to > vdelivermail in the .qmail-default file for a domain? Granted it > wouldn't address making the spam folder settable on a per user basis > but then again I guess it doesn't really need to be. Check the > pw_gid/pw_uid to see if it's enabled. If so, put spam in the place > specified when vdelivermail was called. > > How about making it an environment variable that could be set via > tcpserver? Checking an environment variable sure is low cost. I think we should definitly check for a variable. I thought of something last night. We could add it to the domain limits structure. That file gets parsed anyway and adding one more option to parse should have almost no processing impact. Ken Jones
RE: [vchkpw] Spamassin configuration
Using the domainlimits file isn't a bad idea. It doesn't really address scanning on a per user basis. My thoughts on that are if a user doesn't want the spam filtering they can set their score to say 99. How would we address users who want the spam tagging but want to handle the filtering on their end? On the environment variable option. Is there a way we can set variables for vpopmail? Charlie -Original Message- From: Ken Jones [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 02, 2005 7:14 AM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spamassin configuration On Wednesday 02 March 2005 12:22 am, Charles J. Boening wrote: > I guess the pw_gid/pw_uid fields are numeric. Yeah. bit flags. > Saving a file open/read/close is a good idea if possible. That's why > I was thinking if the current vpasswd/database structure could be > modified it wouldn't be too bad. I think it's worth trying to not have those operations if possible. Efficency! > I still don't know if I'd be sold on a compile time option. I just > don't think it's as flexible. Which begs the question does it need to > be that flexible. I guess by reading options from a database it makes > it easier when you go to upgrade. One less option to remember while > compiling. :) yeah, we do have a huge number of config options. > Would another option be to pass the spam directory as an option to > vdelivermail in the .qmail-default file for a domain? Granted it > wouldn't address making the spam folder settable on a per user basis > but then again I guess it doesn't really need to be. Check the > pw_gid/pw_uid to see if it's enabled. If so, put spam in the place > specified when vdelivermail was called. > > How about making it an environment variable that could be set via > tcpserver? Checking an environment variable sure is low cost. I think we should definitly check for a variable. I thought of something last night. We could add it to the domain limits structure. That file gets parsed anyway and adding one more option to parse should have almost no processing impact. Ken Jones
Re: [vchkpw] Spamassin configuration
On Mar 2, 2005, at 11:49 AM, Nick Harring wrote: Obviously this is a current limitation in simscan, however I think the correct behavior would be to scan once for scoring, then gather white and black lists, modify scoring accordingly, then delete anybody who has exceeded their threshold from the recipients list, if that list is now null then reject the message, otherwise queue it with the trimmed recipient list. This could be streamlined also by first looking for any differences in prefs, and if none are found then simply doing one pass and applying it globally. Or am I not aware of something in simscan that makes the above not feasible? One of the benefits of simscan is that it rejects the spam. So, if a legitimate message gets tagged as spam for some reason, the sender will get the rejection notice and know that it wasn't received. With multiple recipients, there's no way to reject the message for some but not others. I guess it would be possible to modify qmail-smtpd to give 4xx (defer) responses for any additional recipients, forcing the sending SMTP server to send the message once for each recipient. That would hopefully only affect a small number of messages and not add a huge amount of overhead. You'd have the added benefit of spam zombies not retrying their messages (so it would act as a sort of greylisting). Authenticated senders (relay, SMTP AUTH) wouldn't be affected. Either would email generated by the server itself (mailing list messages, cron jobs, etc.). -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
Re: [vchkpw] Spamassin configuration
On Wednesday 02 March 2005 01:49 pm, Nick Harring wrote: > > -Original Message- > > From: Paul Oehler [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 02, 2005 12:36 AM > > To: vchkpw@inter7.com > > Subject: Re: [vchkpw] Spamassin configuration > > > > > I don't think vdelivermail or vpopmail in general should be calling > > > spamc/spamassassin. Let that be handled elsewhere. Let's stick to > > > delivering mail and deciding where it goes. > > > > However, lets remember that if spam is only scanned at the MTA level, > > SpamAssassin user preferences will not function if the e-mail is > > addressed to more than one sender. Scanning in vdelivermail, at the > > MDA > > > level, does not have this restriction. For that reason I still think > > there is value in scanning in vdelivermail. > Obviously this is a current limitation in simscan no, it's a limitation in how SMTP works. This has been discussed on the simscan mailing list several times, please read my posts there. -Jeremy -- Jeremy Kitchen ++ Systems Administrator ++ Inter7 Internet Technologies, Inc. [EMAIL PROTECTED] ++ www.inter7.com ++ 866.528.3530 ++ 815.776.9465 int'l kitchen @ #qmail #gentoo on EFnet IRC ++ scriptkitchen.com/qmail GnuPG Key ID: 481BF7E2 ++ jabber:[EMAIL PROTECTED] pgp6BS3oUz4hF.pgp Description: PGP signature
RE: [vchkpw] Spamassin configuration
> -Original Message- > From: Paul Oehler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 02, 2005 12:36 AM > To: vchkpw@inter7.com > Subject: Re: [vchkpw] Spamassin configuration > > > I don't think vdelivermail or vpopmail in general should be calling > > spamc/spamassassin. Let that be handled elsewhere. Let's stick to > > delivering mail and deciding where it goes. > > However, lets remember that if spam is only scanned at the MTA level, > SpamAssassin user preferences will not function if the e-mail is > addressed to more than one sender. Scanning in vdelivermail, at the MDA > level, does not have this restriction. For that reason I still think > there is value in scanning in vdelivermail. > > Paul > > Obviously this is a current limitation in simscan, however I think the correct behavior would be to scan once for scoring, then gather white and black lists, modify scoring accordingly, then delete anybody who has exceeded their threshold from the recipients list, if that list is now null then reject the message, otherwise queue it with the trimmed recipient list. This could be streamlined also by first looking for any differences in prefs, and if none are found then simply doing one pass and applying it globally. Or am I not aware of something in simscan that makes the above not feasible? Nick Harring Parus Interactive
RE: [vchkpw] Spamassin configuration
> > > How about making it an environment variable that could be set via > > tcpserver? > > I don't think that would work, since the environment variables only > flow through to qmail-smtpd. I don't think there's a way for the > variables to flow through to qmail-local. > Correct, they cannot propagate to qmail-local because it is not invoked by qmail-smtpd. Environment variables only follow fork()->exec() type call chains.
RE: [vchkpw] Spamassin configuration
Point taken. And a good one. :) -Original Message- From: Paul Oehler [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 02, 2005 12:36 AM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spamassin configuration > I don't think vdelivermail or vpopmail in general should be calling > spamc/spamassassin. Let that be handled elsewhere. Let's stick to > delivering mail and deciding where it goes. However, lets remember that if spam is only scanned at the MTA level, SpamAssassin user preferences will not function if the e-mail is addressed to more than one sender. Scanning in vdelivermail, at the MDA level, does not have this restriction. For that reason I still think there is value in scanning in vdelivermail. Paul
Re: [vchkpw] Spamassin configuration
On Mar 1, 2005, at 10:22 PM, Charles J. Boening wrote: Would another option be to pass the spam directory as an option to vdelivermail in the .qmail-default file for a domain? Granted it wouldn't address making the spam folder settable on a per user basis but then again I guess it doesn't really need to be. Check the pw_gid/pw_uid to see if it's enabled. If so, put spam in the place specified when vdelivermail was called. That's a good idea. The postmaster for a domain could easily edit the pref using QmailAdmin, and it wouldn't add any open/read/close file overhead to vdelivermail. How about making it an environment variable that could be set via tcpserver? I don't think that would work, since the environment variables only flow through to qmail-smtpd. I don't think there's a way for the variables to flow through to qmail-local. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
Re: [vchkpw] Spamassin configuration
On Mar 1, 2005, at 5:48 PM, Kurt Bigler wrote: What I should have said was that my ps listing shows nothing that I recognize as a vpopmail daemon. I didn't think vdelivermail was a daemon, but that may be my ignorance of what a daemon is. So you could clarify "vpopmail daemon"? In the vpopmail 5.5 CVS tree, there is a new vpopmaild program. With vpopmaild running, it's possible for a PHP script to interact with the vpopmail library without having to run as the root or vpopmail user. It is still under development, but will eventually roll into the stable releases of vpopmail, along with a PHP-based version of qmailadmin. I have not been involved with vpopmaild or the PHP-qmailadmin, so other developers will have to answer any additional questions you might have. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
Re: [vchkpw] Spamassin configuration
On Wednesday 02 March 2005 12:22 am, Charles J. Boening wrote: > I guess the pw_gid/pw_uid fields are numeric. Yeah. bit flags. > Saving a file open/read/close is a good idea if possible. That's why I > was thinking if the current vpasswd/database structure could be modified > it wouldn't be too bad. I think it's worth trying to not have those operations if possible. Efficency! > I still don't know if I'd be sold on a compile time option. I just > don't think it's as flexible. Which begs the question does it need to > be that flexible. I guess by reading options from a database it makes > it easier when you go to upgrade. One less option to remember while > compiling. :) yeah, we do have a huge number of config options. > Would another option be to pass the spam directory as an option to > vdelivermail in the .qmail-default file for a domain? Granted it > wouldn't address making the spam folder settable on a per user basis but > then again I guess it doesn't really need to be. Check the > pw_gid/pw_uid to see if it's enabled. If so, put spam in the place > specified when vdelivermail was called. > > How about making it an environment variable that could be set via > tcpserver? Checking an environment variable sure is low cost. I think we should definitly check for a variable. I thought of something last night. We could add it to the domain limits structure. That file gets parsed anyway and adding one more option to parse should have almost no processing impact. Ken Jones
Re: [vchkpw] Spamassin configuration
On Tuesday 01 March 2005 7:48 pm, Kurt Bigler wrote: > on 2/28/05 5:02 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote: > > on 2/28/05 7:06 AM, Ken Jones <[EMAIL PROTECTED]> wrote: > >> We are almost ready to release a new php web interface that talks to the > >> vpopmail daemon where we planned on adding support for this spamassassin > >> stuff. > > > > You mention "vpopmail daemon". The only vpopmail daemon I have running > > is vchkpw, used with qmail-pop3d. > > What I should have said was that my ps listing shows nothing that I > recognize as a vpopmail daemon. I didn't think vdelivermail was a daemon, > but that may be my ignorance of what a daemon is. > > So you could clarify "vpopmail daemon"? The development branch of vpopmail has a new program: vpopmaild It can be run as a daemon under tcpserver. It provides just about all the features in the vpopmail libraries. Programs can authenticate with it and ask it to execute vpopmail type commands. We are using it in vhostadmin to build a php based management interface. Since vpopmaild can be run under tcpserver (over ssl if you need), it lets management interfaces to run on any computer and access vpopmaild over the net. I have a development version of vhostadmin I need to package up for release. If any one wants a copy of it before we pretty it up, email me and I'll send you the tarball. > And can someone confirm that SA with per-user preferences means that if I > configure SA to interact with qmail-smtpd that this can result in SMTP > rejections based on individual user prefs? Yes. That is already available with simscan. However email to multiple recipients can not support reading each of their users preferences. I think the default in simscan is to use the preferences of the first recipient. > And is there some redundancy in > thie smtpd-time access to vpopmail information between this and chkuser > that might be a performance concern? Not that I am aware of. Cheers, Ken Jones
Re: [vchkpw] Spamassin configuration
I don't think vdelivermail or vpopmail in general should be calling spamc/spamassassin. Let that be handled elsewhere. Let's stick to delivering mail and deciding where it goes. However, lets remember that if spam is only scanned at the MTA level, SpamAssassin user preferences will not function if the e-mail is addressed to more than one sender. Scanning in vdelivermail, at the MDA level, does not have this restriction. For that reason I still think there is value in scanning in vdelivermail. Paul
RE: [vchkpw] Spamassin configuration
If you're not scanning mail for spam, then you shouldn't be checking for the spam headers. I don't think there would be an issue with forged headers. Most are using Spamassassin at the MTA level via simscan or qmail-scanner. If it's stripping headers and putting valid ones in, where's the problem? I don't think vdelivermail or vpopmail in general should be calling spamc/spamassassin. Let that be handled elsewhere. Let's stick to delivering mail and deciding where it goes. Charlie -Original Message- From: Rick Macdougall [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 3:50 PM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spamassin configuration Tom Collins wrote: > On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote: > >> Is that a good idea ? Say a spam slips through that forges the SA >> headers ? >> >> (Yes, I'm playing devil's advocate here, since SA already checks for >> just that type of thing and ignores them/strips them out, but what >> happens when some new admin doesn't install SA correctly and the mail >> does NOT get scanned by SA but the spammers have made it look like it >> has.) >> >> I'll keep quiet now :) > > > If a message forges SA headers to appear as ham when it's really spam, > then that isn't any different than not having the headers at all (as > far as vdelivermail storing it in a spam folder). > > If you're running SA, it will strip out any old spam headers before > outputing its own headers, so it isn't an issue. > > If you're not running SA, then a ham message with forged headers > indicating that it was spam could end up in the spam folder, but why > would someone want to do that? Hi, Yah, What I'm saying is a mis-configured server with spam coming through that is SA forging itself as ham. Not very likely, but I thought I'd throw it out there. Regards, Rick
RE: [vchkpw] Spamassin configuration
I guess the pw_gid/pw_uid fields are numeric. Saving a file open/read/close is a good idea if possible. That's why I was thinking if the current vpasswd/database structure could be modified it wouldn't be too bad. I still don't know if I'd be sold on a compile time option. I just don't think it's as flexible. Which begs the question does it need to be that flexible. I guess by reading options from a database it makes it easier when you go to upgrade. One less option to remember while compiling. :) Would another option be to pass the spam directory as an option to vdelivermail in the .qmail-default file for a domain? Granted it wouldn't address making the spam folder settable on a per user basis but then again I guess it doesn't really need to be. Check the pw_gid/pw_uid to see if it's enabled. If so, put spam in the place specified when vdelivermail was called. How about making it an environment variable that could be set via tcpserver? Charlie -Original Message- From: Ken Jones [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 4:46 PM To: vchkpw@inter7.com Subject: Re: [vchkpw] Spamassin configuration On Tuesday 01 March 2005 2:27 pm, Charles J. Boening wrote: > > I saw some discussion the other day about the pw_uid and pw_gid fields > in the vpopmail sql tables. I vote to use the unused one (pw_gid > IIRC) to store the spam setting. Say relative path to SPAM maildir. > If the value is there, then deliver accordingly. If not, deliver to > standard delivery location. Also, an environment variable should also > be set so maildir/procmail filters can access it as well. We could use one of the pw_gid or pw_uid fields to enable/disable putting the email into a spam folder. We already have a field for enable/disable spamc processing. Since we need a character array for storing a directory location for spam placement, the uid/gid fields would not work. I'd rather not add this space to the vpasswd structure since there is a lot of code that would need to be checked. I'd recommend either a default location compiled into the source or a file in the Maildir directory that only contains the path, like perhaps "spammaildir" Another idea, we make the compile time spamdirectory a configure option that could be overriden by this "spammaildir" file. like: --enable-spam-maildir=".Spam" > > On my system, my $HOME looks something like this: > > . > > |-- .qmail > |-- Maildir > | > | |-- .SPAM > | | > | | |-- cur > | | |-- maildirfolder > | | |-- new > | | > | | `-- tmp > > `-- mailfilter So in this case if we used a "spammaildir" file it could contain ".SPAM" or use --enable-spam-maildir=".SPAM" and forget about having to create a spammaildir file. I wonder if there would be much of an efficency advantage to not looking for a spammaildir file and only using a configure option. It would save a file open/read/close operation. > I cut out the irrelevant stuff. For all my users using Spamassassin I > filter tagged spam to the .SPAM directory. This shows up right above > "Trash" in Squirrelmail. In my mailfilter script I also make sure > that the courierimapsubscribed file has the right info so the user can > see the directory. The maildir is created the first time the user > gets a spam message. Good point about auto-creation of the maildir. We should do that! > > Point is that everyone does it different and flexibility is a good > thing. IMHO, add the capability to vdelivermail to check the "pw_gid" > field or add another data field "pw_spam" and stay away from compiled > options. We're doing the database call anyway right? We sure could get the pw_gid field to decide to do the spam directory processing from the database lookup. If set we would need to read the spammaildir file. Ken Jones
Re: [vchkpw] Spamassin configuration
> On a high volume system like yours we could just check for spamassassin > headers to see if it is marked as spam. That should not add too much extra > processing since we already read through the email. That's what I was thinking, and what we already have a lot of users doing. It's easy to key in on the x-spam-status or x-spam-level and filter the message accordingly. > For a small systems where the load is lower (ours is like this) we could > continue to run spamc/spamd in vdelivermail then check the spam headers > like > above. Wish I could still do that :-) At first when we set up the system it was neat, but now it just means I have to modify 4 configs for some things (two inbound MXes, a mailstore box, and an outbound SMTP box). NFS doesn't entirely help, since we have a lot of users that use us as a frontend for their own mailservers that we don't directly control. > Of course, both of these would be configurable options. Probably it would > be > best to have them disabled by default. Easy to add one more --enable-thingamabobber line to the already long string I use ;-) I'm liking what I'm hearing with all this new feature discussion. Sounds like *exactly* what I've been wanting to do, but lacking the time to properly implement. -Bill * Waveform Technology UNIX Systems Administrator
Re: [vchkpw] Spamassin configuration
on 2/28/05 5:02 PM, Kurt Bigler <[EMAIL PROTECTED]> wrote: > on 2/28/05 7:06 AM, Ken Jones <[EMAIL PROTECTED]> wrote: > >> We are almost ready to release a new php web interface that talks to the >> vpopmail daemon where we planned on adding support for this spamassassin >> stuff. > > You mention "vpopmail daemon". The only vpopmail daemon I have running is > vchkpw, used with qmail-pop3d. What I should have said was that my ps listing shows nothing that I recognize as a vpopmail daemon. I didn't think vdelivermail was a daemon, but that may be my ignorance of what a daemon is. So you could clarify "vpopmail daemon"? And can someone confirm that SA with per-user preferences means that if I configure SA to interact with qmail-smtpd that this can result in SMTP rejections based on individual user prefs? And is there some redundancy in thie smtpd-time access to vpopmail information between this and chkuser that might be a performance concern? Thanks, Kurt
Re: [vchkpw] Spamassin configuration
On Tuesday 01 March 2005 2:27 pm, Charles J. Boening wrote: > > I saw some discussion the other day about the pw_uid and pw_gid fields > in the vpopmail sql tables. I vote to use the unused one (pw_gid IIRC) > to store the spam setting. Say relative path to SPAM maildir. If the > value is there, then deliver accordingly. If not, deliver to standard > delivery location. Also, an environment variable should also be set so > maildir/procmail filters can access it as well. We could use one of the pw_gid or pw_uid fields to enable/disable putting the email into a spam folder. We already have a field for enable/disable spamc processing. Since we need a character array for storing a directory location for spam placement, the uid/gid fields would not work. I'd rather not add this space to the vpasswd structure since there is a lot of code that would need to be checked. I'd recommend either a default location compiled into the source or a file in the Maildir directory that only contains the path, like perhaps "spammaildir" Another idea, we make the compile time spamdirectory a configure option that could be overriden by this "spammaildir" file. like: --enable-spam-maildir=".Spam" > > On my system, my $HOME looks something like this: > > . > > |-- .qmail > |-- Maildir > | > | |-- .SPAM > | | > | | |-- cur > | | |-- maildirfolder > | | |-- new > | | > | | `-- tmp > > `-- mailfilter So in this case if we used a "spammaildir" file it could contain ".SPAM" or use --enable-spam-maildir=".SPAM" and forget about having to create a spammaildir file. I wonder if there would be much of an efficency advantage to not looking for a spammaildir file and only using a configure option. It would save a file open/read/close operation. > I cut out the irrelevant stuff. For all my users using Spamassassin I > filter tagged spam to the .SPAM directory. This shows up right above > "Trash" in Squirrelmail. In my mailfilter script I also make sure that > the courierimapsubscribed file has the right info so the user can see > the directory. The maildir is created the first time the user gets a > spam message. Good point about auto-creation of the maildir. We should do that! > > Point is that everyone does it different and flexibility is a good > thing. IMHO, add the capability to vdelivermail to check the "pw_gid" > field or add another data field "pw_spam" and stay away from compiled > options. We're doing the database call anyway right? We sure could get the pw_gid field to decide to do the spam directory processing from the database lookup. If set we would need to read the spammaildir file. Ken Jones
Re: [vchkpw] Spamassin configuration
On Tuesday 01 March 2005 5:54 pm, Nick Harring wrote: > > On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote: > > > Is that a good idea ? Say a spam slips through that forges the SA > > > headers ? > > > > > > (Yes, I'm playing devil's advocate here, since SA already checks for > > > just that type of thing and ignores them/strips them out, but what > > > happens when some new admin doesn't install SA correctly and the > > mail > > > > does NOT get scanned by SA but the spammers have made it look like > > it > > > > has.) > > > > > > I'll keep quiet now :) > > > > If a message forges SA headers to appear as ham when it's really spam, > > then that isn't any different than not having the headers at all (as > > far as vdelivermail storing it in a spam folder). > > > > If you're running SA, it will strip out any old spam headers before > > outputing its own headers, so it isn't an issue. > > > > If you're not running SA, then a ham message with forged headers > > indicating that it was spam could end up in the spam folder, but why > > would someone want to do that? > > The only remaining concern I have is that now vpopmail and spamassassin > upgrades become linked. If, heavens forbid, vpopmail becomes less > maintained at some point, and SA makes a shift in the headers then all > the users are adrift with an outdated SA version until somebody hacks up > the code. Or of course they can turn off the nifty keen feature and > reimplement using procmail or whatever. However if developers are > willing to shoulder this potential workload, who am I to complain? It's not too big a deal. I went through the spamassassin 2.63 to 3.X version upgrade where they changed the header format. One we figured out the new format it was just a few lines of code that changed. Ken
RE: [vchkpw] Spamassin configuration
> On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote: > > Is that a good idea ? Say a spam slips through that forges the SA > > headers ? > > > > (Yes, I'm playing devil's advocate here, since SA already checks for > > just that type of thing and ignores them/strips them out, but what > > happens when some new admin doesn't install SA correctly and the mail > > does NOT get scanned by SA but the spammers have made it look like it > > has.) > > > > I'll keep quiet now :) > > If a message forges SA headers to appear as ham when it's really spam, > then that isn't any different than not having the headers at all (as > far as vdelivermail storing it in a spam folder). > > If you're running SA, it will strip out any old spam headers before > outputing its own headers, so it isn't an issue. > > If you're not running SA, then a ham message with forged headers > indicating that it was spam could end up in the spam folder, but why > would someone want to do that? The only remaining concern I have is that now vpopmail and spamassassin upgrades become linked. If, heavens forbid, vpopmail becomes less maintained at some point, and SA makes a shift in the headers then all the users are adrift with an outdated SA version until somebody hacks up the code. Or of course they can turn off the nifty keen feature and reimplement using procmail or whatever. However if developers are willing to shoulder this potential workload, who am I to complain?
Re: [vchkpw] Spamassin configuration
Tom Collins wrote: On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote: Is that a good idea ? Say a spam slips through that forges the SA headers ? (Yes, I'm playing devil's advocate here, since SA already checks for just that type of thing and ignores them/strips them out, but what happens when some new admin doesn't install SA correctly and the mail does NOT get scanned by SA but the spammers have made it look like it has.) I'll keep quiet now :) If a message forges SA headers to appear as ham when it's really spam, then that isn't any different than not having the headers at all (as far as vdelivermail storing it in a spam folder). If you're running SA, it will strip out any old spam headers before outputing its own headers, so it isn't an issue. If you're not running SA, then a ham message with forged headers indicating that it was spam could end up in the spam folder, but why would someone want to do that? Hi, Yah, What I'm saying is a mis-configured server with spam coming through that is SA forging itself as ham. Not very likely, but I thought I'd throw it out there. Regards, Rick
Re: [vchkpw] Spamassin configuration
On Mar 1, 2005, at 1:34 PM, Rick Macdougall wrote: Is that a good idea ? Say a spam slips through that forges the SA headers ? (Yes, I'm playing devil's advocate here, since SA already checks for just that type of thing and ignores them/strips them out, but what happens when some new admin doesn't install SA correctly and the mail does NOT get scanned by SA but the spammers have made it look like it has.) I'll keep quiet now :) If a message forges SA headers to appear as ham when it's really spam, then that isn't any different than not having the headers at all (as far as vdelivermail storing it in a spam folder). If you're running SA, it will strip out any old spam headers before outputing its own headers, so it isn't an issue. If you're not running SA, then a ham message with forged headers indicating that it was spam could end up in the spam folder, but why would someone want to do that? -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
Re: [vchkpw] Spamassin configuration
Tom Collins wrote: On Mar 1, 2005, at 11:05 AM, Bill Wichers wrote: Just a quick note. vdelivermail already parses headers to make sure mail is not looping. It could easily check for SpamAssassin headers and filter based on that. Again, this would be a compile-time option, and those who know how to use maildrop/procmail could do their fancy filtering there. Hummm, Is that a good idea ? Say a spam slips through that forges the SA headers ? (Yes, I'm playing devil's advocate here, since SA already checks for just that type of thing and ignores them/strips them out, but what happens when some new admin doesn't install SA correctly and the mail does NOT get scanned by SA but the spammers have made it look like it has.) I'll keep quiet now :) Regards, Rick
Re: [vchkpw] Spamassin configuration
On Mar 1, 2005, at 11:05 AM, Bill Wichers wrote: Running spamc/spamd directly from vpopmail seems very, very scary to me. We handle well over 1 million messages/day here and have several beefy machines front-ending for our mail system that do all the filtering (ClamAV and Spamassassin). Running Spamassassin on the vpopmail mailstore box simply does not work from us (nowhere near enough CPU/RAM resources on the one server). Spamassassin really *is* seperate from vpopmail. The filtering function could be efficiently implemented in vdelivermail since that process is already involved in the message delivery, and it would be nice to not have to involve shell or perl scripts to filter messages into mailboxes. Just a quick note. vdelivermail already parses headers to make sure mail is not looping. It could easily check for SpamAssassin headers and filter based on that. Again, this would be a compile-time option, and those who know how to use maildrop/procmail could do their fancy filtering there. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
RE: [vchkpw] Spamassin configuration
I've been following this the last couple days and figured I'd put my $0.02 in. If you're wanting Spamassassin to be called from vpopmail, how about making it work per domain or per user like simscan does with it's simcontrol file. Then it could be on a per domain basis so you don't have to micromanage. Or if you're hosting multiple domains you could enable or disable on a per domain basis. You could store a vpopcontrol file in the ~vpopmail/domains/ directory. Vdelivermail could read that. Another option would be to just have vpopmail do delivery only. Most of us are either running qmail-scanner or simscan. I recently changed from qmail-scanner to simscan myself. With qmail-scanner or simscan doing Spamassassin, I think all you need is a program to handle the delivery. Currently I have a "stock" mailfilter file called from .qmail for anyone who wants spam filtering. I have a web interface for users to turn it on and off. The web interface just sends an email to a special account who's mailfilter copies the "stock" one and a .qmail file to the user's directory. I saw some discussion the other day about the pw_uid and pw_gid fields in the vpopmail sql tables. I vote to use the unused one (pw_gid IIRC) to store the spam setting. Say relative path to SPAM maildir. If the value is there, then deliver accordingly. If not, deliver to standard delivery location. Also, an environment variable should also be set so maildir/procmail filters can access it as well. On my system, my $HOME looks something like this: . |-- .qmail |-- Maildir | |-- .SPAM | | |-- cur | | |-- maildirfolder | | |-- new | | `-- tmp `-- mailfilter I cut out the irrelevant stuff. For all my users using Spamassassin I filter tagged spam to the .SPAM directory. This shows up right above "Trash" in Squirrelmail. In my mailfilter script I also make sure that the courierimapsubscribed file has the right info so the user can see the directory. The maildir is created the first time the user gets a spam message. Point is that everyone does it different and flexibility is a good thing. IMHO, add the capability to vdelivermail to check the "pw_gid" field or add another data field "pw_spam" and stay away from compiled options. We're doing the database call anyway right? If we're adding Spamassassin support why not add TMDA support as well. :) Call the TMDA script passing it the email, check the return result and decide to deliver or not. If not, then the user isn't authorized via TMDA and a challenge was sent out. Again, this type of thing should be relatively easy to add to vdelivermail. At least the concept is easy. :) Again, we'd have to have a pw_tmda or similar to check and see if we should attempt TMDA delivery. If so, then check for the existence of $HOME/.tmda. If it's not there then create it by calling vadduser-tmda or similar to create the structure and put the right information in the files. Then call tmda-filter and handle delivery based on the return code. I've kind of strayed off the Spamassassin topic but I think something like calling TMDA is more suited to be built into vdelivermail than calling Spamassassin. Let simscan and qmail-scanner take care of calling Spamassassin. Charlie -Original Message----- From: Bill Wichers [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 01, 2005 11:05 AM To: vchkpw@inter7.com Subject: RE: [vchkpw] Spamassin configuration > Putting the spamc->spamd calls inside vpopmail makes sense to me. > However then putting the logic that decides where to deliver the mail, > and tying those to irrevocably together is what I'm asking not be done. > I'm in the same load situation as you, my systems do a couple hundred > thousand local deliveries a day, and invoking spamassassin rather than > spamc is unthinkable. However the overhead to fork and exec procmail > or [snip] No one has suggested non-modifiable behavior. I suggested maybe a compile-time directive to either do or not-do the filtering, and others suggested some kind of config file to hold the options (and presumably configuration info for the options too). All the discussion about the name of the maildir to use has implied a *default* of "spam", but even worst case you could always just change that in the source. Running spamc/spamd directly from vpopmail seems very, very scary to me. We handle well over 1 million messages/day here and have several beefy machines front-ending for our mail system that do all the filtering (ClamAV and Spamassassin). Running Spamassassin on the vpopmail mailstore box simply does not work from us (nowhere near enough CPU/RAM resources on the one server). Spamassassin really *is* seperate from vpopmail. The filtering function could be efficiently implemented in vdelivermail since that p
Re: [vchkpw] Spamassin configuration
On Tuesday 01 March 2005 1:05 pm, Bill Wichers wrote: > > Putting the spamc->spamd calls inside vpopmail makes sense to me. > > However then putting the logic that decides where to deliver the mail, > > and tying those to irrevocably together is what I'm asking not be done. > > I'm in the same load situation as you, my systems do a couple hundred > > thousand local deliveries a day, and invoking spamassassin rather than > > spamc is unthinkable. However the overhead to fork and exec procmail or > > [snip] > > No one has suggested non-modifiable behavior. I suggested maybe a > compile-time directive to either do or not-do the filtering, and others > suggested some kind of config file to hold the options (and presumably > configuration info for the options too). All the discussion about the name > of the maildir to use has implied a *default* of "spam", but even worst > case you could always just change that in the source. > > Running spamc/spamd directly from vpopmail seems very, very scary to me. > We handle well over 1 million messages/day here and have several beefy > machines front-ending for our mail system that do all the filtering > (ClamAV and Spamassassin). Running Spamassassin on the vpopmail mailstore > box simply does not work from us (nowhere near enough CPU/RAM resources on > the one server). Spamassassin really *is* seperate from vpopmail. The > filtering function could be efficiently implemented in vdelivermail since > that process is already involved in the message delivery, and it would be > nice to not have to involve shell or perl scripts to filter messages into > mailboxes. Looks like we are on the same page Bill. On a high volume system like yours we could just check for spamassassin headers to see if it is marked as spam. That should not add too much extra processing since we already read through the email. For a small systems where the load is lower (ours is like this) we could continue to run spamc/spamd in vdelivermail then check the spam headers like above. Of course, both of these would be configurable options. Probably it would be best to have them disabled by default. Ken Jones
RE: [vchkpw] Spamassin configuration
> Putting the spamc->spamd calls inside vpopmail makes sense to me. > However then putting the logic that decides where to deliver the mail, > and tying those to irrevocably together is what I'm asking not be done. > I'm in the same load situation as you, my systems do a couple hundred > thousand local deliveries a day, and invoking spamassassin rather than > spamc is unthinkable. However the overhead to fork and exec procmail or [snip] No one has suggested non-modifiable behavior. I suggested maybe a compile-time directive to either do or not-do the filtering, and others suggested some kind of config file to hold the options (and presumably configuration info for the options too). All the discussion about the name of the maildir to use has implied a *default* of "spam", but even worst case you could always just change that in the source. Running spamc/spamd directly from vpopmail seems very, very scary to me. We handle well over 1 million messages/day here and have several beefy machines front-ending for our mail system that do all the filtering (ClamAV and Spamassassin). Running Spamassassin on the vpopmail mailstore box simply does not work from us (nowhere near enough CPU/RAM resources on the one server). Spamassassin really *is* seperate from vpopmail. The filtering function could be efficiently implemented in vdelivermail since that process is already involved in the message delivery, and it would be nice to not have to involve shell or perl scripts to filter messages into mailboxes. -Bill * Waveform Technology UNIX Systems Administrator
RE: [vchkpw] Spamassin configuration
> > Guilty, I have thousands of accounts, mostly commercial, and mail comes > constantly 24 hours a day. While there are some nice programs out there > to replace qmail-queue or to drop inside a dot qmail file, I really want > to avoid running the perl interpreter (once sometimes twice) for each > message. I can make better use of system resources elswhere. > > If I understand what Ken is proposing correctly, you could make vpopmail > without the spamassassin switch to return to the normal delivery method, > continuing to call spamassassin/spamc/procmail/maildrop as before. > > DAve Putting the spamc->spamd calls inside vpopmail makes sense to me. However then putting the logic that decides where to deliver the mail, and tying those to irrevocably together is what I'm asking not be done. I'm in the same load situation as you, my systems do a couple hundred thousand local deliveries a day, and invoking spamassassin rather than spamc is unthinkable. However the overhead to fork and exec procmail or maildrop isn't significant based on the little bit of testing I did. Besides which, for load there are other improvements to vpopmail which should be made (such as dynamic linking of vpopmail binaries). I'm merely asking that the ability to have a message checked be decoupled from the ability to have it delivered into a SPAM folder, so that we can pick and choose the features we need. Nick
Re: [vchkpw] Spamassin configuration
Nick Harring wrote: How about if a mailbox called SPAM exists, put it there, otherwise just drop it in the INBOX? That sounds nice and clean. I like it. Ken Jones If you implement this, please do not remove the ability to simply have the message tagged and then be able to pass it to procmail or maildrop. I'd love to leverage built in spamassassin support, however if you're going to force me into using a folder called spam, then it becomes useless to me. I'm unconvinced this is logic which even remotely belongs in vdelivermail, however obviously a lot of people are worried about the supposed overhead of launching procmail and having to generate procmailrc files. Guilty, I have thousands of accounts, mostly commercial, and mail comes constantly 24 hours a day. While there are some nice programs out there to replace qmail-queue or to drop inside a dot qmail file, I really want to avoid running the perl interpreter (once sometimes twice) for each message. I can make better use of system resources elswhere. If I understand what Ken is proposing correctly, you could make vpopmail without the spamassassin switch to return to the normal delivery method, continuing to call spamassassin/spamc/procmail/maildrop as before. DAve -- Dave Goodrich Systems Administrator http://www.tls.net Get rid of Unwanted Emails...get TLS Spam Blocker!
RE: [vchkpw] Spamassin configuration
> > > > How about if a mailbox called SPAM exists, put it there, otherwise just > > drop it in the INBOX? > > That sounds nice and clean. I like it. > > Ken Jones If you implement this, please do not remove the ability to simply have the message tagged and then be able to pass it to procmail or maildrop. I'd love to leverage built in spamassassin support, however if you're going to force me into using a folder called spam, then it becomes useless to me. I'm unconvinced this is logic which even remotely belongs in vdelivermail, however obviously a lot of people are worried about the supposed overhead of launching procmail and having to generate procmailrc files. Thanks, Nick Harring Sr System Administrator Webley Systems
Re: [vchkpw] Spamassin configuration
On Monday 28 February 2005 6:51 pm, Tom Collins wrote: > On Feb 28, 2005, at 2:36 PM, Bill Wichers wrote: > > Maybe even a site-wite compile-time directive? Probably the most common > > would be something like SPAM under the INBOX for the filtered messages. > > Having it in SQL would be nice (allow users to configure it if they > > call > > the SPAM dir something else in their own hierarchy), although I'm not > > familiar enough with the innards of the code to know if that would work > > well... > > How about if a mailbox called SPAM exists, put it there, otherwise just > drop it in the INBOX? That sounds nice and clean. I like it. Ken Jones
Re: [vchkpw] Spamassin configuration
>> How about if a mailbox called SPAM exists, put it there, otherwise just >> drop it in the INBOX? > > That would be my choice, a lot of the systems I've looked at used the > IMAP folder "Spam" to hold the messages tagged by spamc. That is how I > had been planning to do it. Alternatively couldn't a env var be used? > Change the var, change the delivery path relative to the users home dir. Sounds good to me, although better make sure the "spam" directory was case-insensitive. In just this thread we've seen SPAM, spam, and Spam :-) Env var seems like a neat idea too... I could see something doing a "below this score, message->inbox, below this score AND above that score message->spam, and above someother score message->trash kind of sorting. Any plans to have vdelivermail absorb some maildrop functionality too? -Bill * Waveform Technology UNIX Systems Administrator
Re: [vchkpw] Spamassin configuration
Tom Collins wrote: On Feb 28, 2005, at 2:36 PM, Bill Wichers wrote: Maybe even a site-wite compile-time directive? Probably the most common would be something like SPAM under the INBOX for the filtered messages. Having it in SQL would be nice (allow users to configure it if they call the SPAM dir something else in their own hierarchy), although I'm not familiar enough with the innards of the code to know if that would work well... How about if a mailbox called SPAM exists, put it there, otherwise just drop it in the INBOX? That would be my choice, a lot of the systems I've looked at used the IMAP folder "Spam" to hold the messages tagged by spamc. That is how I had been planning to do it. Alternatively couldn't a env var be used? Change the var, change the delivery path relative to the users home dir. DAve -- Dave Goodrich Systems Administrator http://www.tls.net Get rid of Unwanted Emails...get TLS Spam Blocker!
Re: [vchkpw] Spamassin configuration
on 2/28/05 7:06 AM, Ken Jones <[EMAIL PROTECTED]> wrote: > On Sunday 27 February 2005 2:42 am, Kurt Bigler wrote: >> How are you planning on making per-user options available to individual >> users for editing? I thought I had read something about using SqWebmail >> for this but I can not find the message now and can find no other >> confirmation, and the SqWebmail info does not seem to mention any support >> for spamassasin. > > We are almost ready to release a new php web interface that talks to the > vpopmail daemon where we planned on adding support for this spamassassin > stuff. You mention "vpopmail daemon". The only vpopmail daemon I have running is vchkpw, used with qmail-pop3d. I was thinking that vpopmail would only be used to provide the domain/user organization, and a hierarchy in which preferences could be stored. It is my hope that these per-user settings would (if desired) influence rejection by qmail-smtpd (i.e. via $QMAILQUEUE patch) rather than being limited to filtering that can be set up in .qmail files. I'm not sure if that's what you're referring to since I don't yet understand exactly at what levels this functionality interfaces with vpopmail. I'm also wondering about redundancy between this and chkuser, in terms of the need for qmail-smtpd to have access to vpopmail info at the domain/user level. I also haven't installed chkuser yet and don't know how it interfaces with vpopmail. Lacking intimate familiarity it's very hard work to assimilate all this information and so it is vastly helpful to be able to ask these questions. Thanks in advance. > Hopefully we can release the new code tomorrow. Wow. Is what you are working on general enough to be used for per-user preferences that outside the spamassassin realm? In other words, if you are solving the problem of authenticating to gain access to per-user preferences, and putting up an interface for that, can you use hooks up front that are general enough to allow extension for other purposes? In my case, I'd like individual users to be able to enable any of several other other custom filtering rules having nothing to do with spamassassin. I don't want users to have to go in more than once place, especially more than one login to achieve this. In other words, I'm looking at a set of simple checkboxes for this purpose, not a general-purpose rule-entry paradigm. I'm sure there will be many others besides me that will want this, sooner or later. >> Looking forward to having this feature rolled into 5.4. > Me too. And we have time over here to work on it. That's great. I can possibly help test. I would serve well as a "dummy" tester, as long as things are not too rough. -Kurt
Re: [vchkpw] Spamassin configuration
On Feb 28, 2005, at 2:36 PM, Bill Wichers wrote: Maybe even a site-wite compile-time directive? Probably the most common would be something like SPAM under the INBOX for the filtered messages. Having it in SQL would be nice (allow users to configure it if they call the SPAM dir something else in their own hierarchy), although I'm not familiar enough with the innards of the code to know if that would work well... How about if a mailbox called SPAM exists, put it there, otherwise just drop it in the INBOX? -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
Re: [vchkpw] Spamassin configuration
On Fri, 25 Feb 2005, Ken Jones wrote: I wrote the code since we needed to support per user spamassasin preferences. At Tom's request I put it in the 5.5 development version. We run a 5.5.1 version production with no problems. I think it's about time we merged this feature into the 5.4 release. Any objections? How does this impact the current spam assassin option in qmailadmin? We currently use that (it just calls a default maildrop recipe) and use a squirrelmail plugin to set spamass prefs. We have another in-house plugin that can toggle the filtering on/off from within squirrelmail which I'm currently rewriting to use vpopmaild for .qmail manipulation. Is there a blurb somewhere that outlines how this new system works? Thanks, Charles Ken Jones inter7.com
Re: [vchkpw] Spamassin configuration
At 12:06 28/2/2005, you wrote: ..snip... > How are you planning on making per-user options available to individual > users for editing? I thought I had read something about using SqWebmail > for this but I can not find the message now and can find no other > confirmation, and the SqWebmail info does not seem to mention any support > for spamassasin. We are almost ready to release a new php web interface that talks to the vpopmail daemon where we planned on adding support for this spamassassin stuff. Hopefully we can release the new code tomorrow. I don't know the PHP Web Interface written by Ken to change the per-user Spamassassin options but we are using here a Squirrelmail plugin that works smoothly in a Vpopmail system. It uses a C wrapper to write the User Prefs to .spamassassin dirs solving the permissions issue this way. Obviously this could be a useful solution only if you use this Webmail interface. William. -- Esta mensagem foi verificada por Ultralink-Scanner e nenhum virus foi encontrado. Web Server Ultralink: http://www.ultralink.com.br --
Re: [vchkpw] Spamassin configuration
On Saturday 26 February 2005 1:19 pm, Tom wrote: >> Will this also allow the user to sort spam to a user specified folder as >> well? Would be nice to cut out a procmail process too. > > Sounds like a good idea. We just need a place to store that information. > Perhaps an optional new file that could specify the users spam folder. > I think a relative directory path might be best for migration reasons. > > Ken Jones Suggestion: Maybe even a site-wite compile-time directive? Probably the most common would be something like SPAM under the INBOX for the filtered messages. Having it in SQL would be nice (allow users to configure it if they call the SPAM dir something else in their own hierarchy), although I'm not familiar enough with the innards of the code to know if that would work well... Sounds like a great feature though. We've been wanting to offer something like this to our users for a while, but haven't had the time to develop and interface for it. -Bill * Waveform Technology UNIX Systems Administrator
Re: [vchkpw] Spamassin configuration
On Sunday 27 February 2005 2:42 am, Kurt Bigler wrote: > on 2/25/05 3:43 PM, Jason S <[EMAIL PROTECTED]> wrote: > > On Fri, 25 Feb 2005 16:47:36 -0500 (EST), Ron Dyck <[EMAIL PROTECTED]> wrote: > >> I'm currently upgrading my mail server and am installing simscan. > >> Simscan claims that there is an option to configure vpopmail with > >> spamassassin option: > >> --enable-spamassassin > >> (http://www.qmailwiki.org/Simscan/Guide) > >> The allows vpopmail user options so individual users can set their own > >> perferences. > >> > >> I can't find this configure option anywhere, but would like to consider > >> it. > >> > >> Does anyone have any information on this? > > > > The document you reference tells you what you need to know as far as > > simscan is concerned. If you want more info about per-user config in > > spamassassin using sql, check here: > > http://wiki.apache.org/spamassassin/UsingSQL > > Excuse the newbie questions, but I've been reading for two solid days now, > and I need to start asking some questions before I fall over dead... > > Does the per-user config require that I switch my qmail+vpopmail > authorization from cdb to sql, or is this a separate issue? Separate issue. The spamassassin code is only in the development branch. We are talking about integrating it into the stable branch along with Tom's re-written vdelivermail. The vdelivermail code sure could use a clean re-write. Thanks for taking that on Tom! > > How are you planning on making per-user options available to individual > users for editing? I thought I had read something about using SqWebmail > for this but I can not find the message now and can find no other > confirmation, and the SqWebmail info does not seem to mention any support > for spamassasin. We are almost ready to release a new php web interface that talks to the vpopmail daemon where we planned on adding support for this spamassassin stuff. Hopefully we can release the new code tomorrow. > Looking forward to having this feature rolled into 5.4. Me too. And we have time over here to work on it. Ken Jones
Re: [vchkpw] Spamassin configuration
On Saturday 26 February 2005 1:19 pm, Tom wrote: > Will this also allow the user to sort spam to a user specified folder as > well? Would be nice to cut out a procmail process too. Sounds like a good idea. We just need a place to store that information. Perhaps an optional new file that could specify the users spam folder. I think a relative directory path might be best for migration reasons. Ken Jones
Re: [vchkpw] Spamassin configuration
On Saturday 26 February 2005 10:36 am, Tom Collins wrote: > On Feb 25, 2005, at 8:48 PM, Ken Jones wrote: > > I wrote the code since we needed to support per user spamassasin > > preferences. At Tom's request I put it in the 5.5 development version. > > We run a 5.5.1 version production with no problems. > > > > I think it's about time we merged this feature into the 5.4 release. > > Any objections? > > I plan on rolling it in to 5.4 after my updated vdelivermail has been > released and tested further. Since most of the code for the per-user > spamassassin filtering is in vdelivermail, I'd rather re-integrate it > into my new code. I'd like to get the spamassassin feature in a bit sooner. How about you put the new vdelivermail into cvs for testing. Then we can review and help test the new code while we integrate in the spamassasin code and the variable size increase to fix the quota problem. No need for you to do the extra work when we have available time. Cheers, Ken Jones
Re: [vchkpw] Spamassin configuration
Tom wrote: Will this also allow the user to sort spam to a user specified folder as well? Would be nice to cut out a procmail process too. My interest is peaked. I am currently investigating doing just that and not finding any good solutions. I just hate to use another perl or shell script do to do anything. If vdelivermail could call spamc with per user prefs, *and* deliver to a users spam box, I would be a happy camper. Mark me for willing to test any code. DAve -- Dave Goodrich Systems Administrator http://www.tls.net Get rid of Unwanted Emails...get TLS Spam Blocker!
Re: [vchkpw] Spamassin configuration
on 2/25/05 3:43 PM, Jason S <[EMAIL PROTECTED]> wrote: > On Fri, 25 Feb 2005 16:47:36 -0500 (EST), Ron Dyck <[EMAIL PROTECTED]> wrote: >> I'm currently upgrading my mail server and am installing simscan. Simscan >> claims that there is an option to configure vpopmail with spamassassin >> option: >> --enable-spamassassin >> (http://www.qmailwiki.org/Simscan/Guide) >> The allows vpopmail user options so individual users can set their own >> perferences. >> >> I can't find this configure option anywhere, but would like to consider it. >> >> Does anyone have any information on this? > > The document you reference tells you what you need to know as far as > simscan is concerned. If you want more info about per-user config in > spamassassin using sql, check here: > http://wiki.apache.org/spamassassin/UsingSQL Excuse the newbie questions, but I've been reading for two solid days now, and I need to start asking some questions before I fall over dead... Does the per-user config require that I switch my qmail+vpopmail authorization from cdb to sql, or is this a separate issue? How are you planning on making per-user options available to individual users for editing? I thought I had read something about using SqWebmail for this but I can not find the message now and can find no other confirmation, and the SqWebmail info does not seem to mention any support for spamassasin. Looking forward to having this feature rolled into 5.4. Thanks. -Kurt Bigler
Re: [vchkpw] Spamassin configuration
Will this also allow the user to sort spam to a user specified folder as well? Would be nice to cut out a procmail process too. -- Regards, Tom > On Feb 25, 2005, at 8:48 PM, Ken Jones wrote: >> I wrote the code since we needed to support per user spamassasin >> preferences. At Tom's request I put it in the 5.5 development version. >> We run a 5.5.1 version production with no problems. >> >> I think it's about time we merged this feature into the 5.4 release. >> Any objections? > > I plan on rolling it in to 5.4 after my updated vdelivermail has been > released and tested further. Since most of the code for the per-user > spamassassin filtering is in vdelivermail, I'd rather re-integrate it > into my new code. > > -- > Tom Collins - [EMAIL PROTECTED] > QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ > You don't need a laptop to troubleshoot high-speed Internet: > sniffter.com > > >
Re: [vchkpw] Spamassin configuration
On Feb 25, 2005, at 8:48 PM, Ken Jones wrote: I wrote the code since we needed to support per user spamassasin preferences. At Tom's request I put it in the 5.5 development version. We run a 5.5.1 version production with no problems. I think it's about time we merged this feature into the 5.4 release. Any objections? I plan on rolling it in to 5.4 after my updated vdelivermail has been released and tested further. Since most of the code for the per-user spamassassin filtering is in vdelivermail, I'd rather re-integrate it into my new code. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
Re: [vchkpw] Spamassin configuration
On Friday 25 February 2005 3:47 pm, Ron Dyck wrote: > I'm currently upgrading my mail server and am installing simscan. Simscan > claims that there is an option to configure vpopmail with spamassassin > option: > --enable-spamassassin > (http://www.qmailwiki.org/Simscan/Guide) > The allows vpopmail user options so individual users can set their own > perferences. > > I can't find this configure option anywhere, but would like to consider it. > > Does anyone have any information on this? I wrote the code since we needed to support per user spamassasin preferences. At Tom's request I put it in the 5.5 development version. We run a 5.5.1 version production with no problems. I think it's about time we merged this feature into the 5.4 release. Any objections? Ken Jones inter7.com
Re: [vchkpw] Spamassin configuration
On Feb 25, 2005, at 4:12 PM, Rick Macdougall wrote: That is a 5.5 option and is not available in the 5.4 series. I do know a few people do run the 5.5 series in production but I do not recommend it unless you are reading the vpopmail-dev list and are prepared to debug some code. Ken and Tom may have a different opinion though :), as I do believe Ken is one of the people running 5.5.x Actually, I agree with Rick. 5.4.x is the way to go. Be sure to grab the latest version listed on SourceForge as 'stable'. I consider some of the 5.4 releases as 'devel' because they incorporate significant changes. Once a release has been out as 'devel' for awhile with a significant number of downloads (and no scary bug reports), I'll re-classify it as 'stable'. -- Tom Collins - [EMAIL PROTECTED] QmailAdmin: http://qmailadmin.sf.net/ Vpopmail: http://vpopmail.sf.net/ You don't need a laptop to troubleshoot high-speed Internet: sniffter.com
Re: [vchkpw] Spamassin configuration
Jason S wrote: On Fri, 25 Feb 2005 16:47:36 -0500 (EST), Ron Dyck <[EMAIL PROTECTED]> wrote: I'm currently upgrading my mail server and am installing simscan. Simscan claims that there is an option to configure vpopmail with spamassassin option: --enable-spamassassin (http://www.qmailwiki.org/Simscan/Guide) The allows vpopmail user options so individual users can set their own perferences. I can't find this configure option anywhere, but would like to consider it. The document you reference tells you what you need to know as far as simscan is concerned. If you want more info about per-user config in spamassassin using sql, check here: http://wiki.apache.org/spamassassin/UsingSQL simscan has a list as well: http://news.gmane.org/gmane.mail.qmail.simscan Hi, That is a 5.5 option and is not available in the 5.4 series. I do know a few people do run the 5.5 series in production but I do not recommend it unless you are reading the vpopmail-dev list and are prepared to debug some code. Ken and Tom may have a different opinion though :), as I do believe Ken is one of the people running 5.5.x Regards, Rick
Re: [vchkpw] Spamassin configuration
On Fri, 25 Feb 2005 16:47:36 -0500 (EST), Ron Dyck <[EMAIL PROTECTED]> wrote: > I'm currently upgrading my mail server and am installing simscan. Simscan > claims that there is an option to configure vpopmail with spamassassin > option: > --enable-spamassassin > (http://www.qmailwiki.org/Simscan/Guide) > The allows vpopmail user options so individual users can set their own > perferences. > > I can't find this configure option anywhere, but would like to consider it. > > Does anyone have any information on this? > > Thanks, > > ron > > > = > Ron Dyck > [EMAIL PROTECTED] > webbtech.net > = > The document you reference tells you what you need to know as far as simscan is concerned. If you want more info about per-user config in spamassassin using sql, check here: http://wiki.apache.org/spamassassin/UsingSQL simscan has a list as well: http://news.gmane.org/gmane.mail.qmail.simscan Good luck -- Jason [EMAIL PROTECTED]
