[vchkpw] cvm-vchkpw for vpopmail.
Dear All, I want to use the Mailfront SMTP front end. I tried to install the cvm-vchkpw for authentication using vpopmail, I followed the instructions in README.vchkpw .but I cannot find it - cvm-vchkpw - in the /usr/local/bin. Can anyone help me ? Best Regards. Samir Noshy
[vchkpw] how to run the vpopmail pop3 daemon ?
Hello, I have set up a Qmail system wich delivers into Maildir/ format. Know I would like to have vpopmail as a pop3 server especially for virtual domains I created via vadddomain and virtual users created via qmailadmin. How to ? I read into the INSTALL file that I should put a line : [...] 12. How to use vchkpw with qmail-pop3d server Here is a sample startup line for qmail-pop3d and vchkpw env - PATH=/var/qmail/bin:/usr/local/bin \ tcpserver -H -R 0 pop-3 \ /var/qmail/bin/qmail-popup your.domain.com \ /home-dir-of-vpopmail/bin/vchkpw /var/qmail/bin/qmail-pop3d \ Maildir [...] but where? in what file should I put it ? Thank you in advance. -- ASPO Infogérance http://aspo.rktmb.org/activites/infogerance Unofficial FAQ fcolc http://faq.fcolc.eu.org/ LUG sur Orléans et alentours (France). Tél : 02 34 08 26 04 / 06 33 26 13 14
Re: [vchkpw] VPopmail Quotas in chkuser
Rick Macdougall wrote: Hi, I could be wrong but my experience shows me that CHKUSER_MBXQUOTA is a percentage of the users total quota. I use CHKUSER_MBXQUOTA=98 here and it works as I expect it too, ie rejecting mail when the users quota is 98% used. Regards, Rick Thanks Rick, it was a case of me not reading the docs properly. I've set the environment variable and it does as I was expecting. :) Thanks again. -- Regards, Scott Clark This email has been sent to you by Scott Clark mail at scottclark dot me dot uk. Visit me @ http://www.scottclark.me.uk/ The views and opinions expressed in this email are the author's own. This email is intended for the exclusive use of the addressee only. If you are not the intended recipient, you should not use the contents nor disclose them to any other person and you should immediately notify the sender and delete the email.
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 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
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
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
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
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
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/domain 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 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
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] how to run the vpopmail pop3 daemon ?
Rakotomandimby (R12y) Mihamina wrote: Hello, I have set up a Qmail system wich delivers into Maildir/ format. Know I would like to have vpopmail as a pop3 server especially for virtual domains I created via vadddomain and virtual users created via qmailadmin. How to ? I read into the INSTALL file that I should put a line : [...] 12. How to use vchkpw with qmail-pop3d server Here is a sample startup line for qmail-pop3d and vchkpw env - PATH=/var/qmail/bin:/usr/local/bin \ tcpserver -H -R 0 pop-3 \ /var/qmail/bin/qmail-popup your.domain.com \ /home-dir-of-vpopmail/bin/vchkpw /var/qmail/bin/qmail-pop3d \ Maildir [...] but where? in what file should I put it ? Thank you in advance. /var/qmail/supervise/qmail-pop3d/run in a default qmail install. BTW, it's stongly recommended you make all domains virtual.
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 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 Tuesday 01 March 2005 2:27 pm, Charles J. Boening wrote: snip 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. snip Ken Jones
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 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
slaps forehead 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: snip 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. snip Ken Jones
