Re: [vchkpw] qmail tap patch
On Thursday, July 14 at 09:21 AM, quoth project: When I apply the taps patch file and recompile my qmail, I can't see the logs in /va r/log/maillog anymore but before I applied the taps patch I can see the logs in that directory. How were the logs getting into /var/log/maillog before? I just simply add *.* /dev/tty on the syslogd.conf How does that affect /var/log/maillog? I don't know I just can\t see anyting in it, btw I am using qmail-scaner, the after 2 days my qmail-scanner is not working anymore, I can acceppt many spam now Qmail logs do not necessarily go to syslog. How qmail logs get into /var/log/maillog is critical to figuring out how it might be broken. I suggest you read www.lifewithqmail.com, and set your system up that way, THEN set it up with qmail-scanner, and get back to us. ~Kyle -- The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts. -- Bertrand Russell pgpFOS9jbYPh7.pgp Description: PGP signature
Re: [vchkpw] qmail tap patch
How does that affect /var/log/maillog? ~Kyle On Wednesday, July 13 at 07:27 AM, quoth project: I just simply add *.* /dev/tty on the syslogd.conf Kyle Wheeler wrote: On Sunday, July 10 at 10:51 AM, quoth empf: Hi, When I apply the taps patch file and recompile my qmail, I can't see the logs in /va r/log/maillog anymore but before I applied the taps patch I can see the logs in that directory. How were the logs getting into /var/log/maillog before? ~Kyle -- I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. -- Gallileo ~Kyle -- We *can't* simply do our science and not worry about the ethical issues. -- Bill Joy pgpouwc5672g3.pgp Description: PGP signature
Re: [vchkpw] qmail tap patch
On Sunday, July 10 at 10:51 AM, quoth empf: Hi, When I apply the taps patch file and recompile my qmail, I can't see the logs in /va r/log/maillog anymore but before I applied the taps patch I can see the logs in that directory. How were the logs getting into /var/log/maillog before? ~Kyle -- I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. -- Gallileo signature.asc Description: Digital signature
Re: [vchkpw] Questions about vdelivermail
On Friday, July 8 at 06:36 PM, quoth Kyle Wheeler: On Friday, July 8 at 12:20 PM, quoth Tren Blackburn: Why do you have .qmail-user files? Because it was the only way I could think of to forward the message without actually storing it on the qmail server. What I want is it to be virus scanned (happens at smtp level via simscan), and then run through dspam. Is there a simple way to allow a message to go through the .qmail-default file and forward to another server, but not store the message on the qmail server as well. Sorry if I didn't explain it very clearly before and thanks for the reply. AHA! I thought as much. Vpopmail will do what you want if you move .qmail-user into user/.qmail Oops, I'm a moron - this was already suggested. :) ~Kyle -- If there be any among us who would wish to dissolve this Union or to change its republican form, let them stand undisturbed as monuments of the safety with which error of opinion may be tolerated where reason is left free to combat it. -- Thomas Jefferson: First Inaugural, 1801 signature.asc Description: Digital signature
Re: [vchkpw] Questions about vdelivermail
On Friday, July 8 at 12:20 PM, quoth Tren Blackburn: Why do you have .qmail-user files? Because it was the only way I could think of to forward the message without actually storing it on the qmail server. What I want is it to be virus scanned (happens at smtp level via simscan), and then run through dspam. Is there a simple way to allow a message to go through the .qmail-default file and forward to another server, but not store the message on the qmail server as well. Sorry if I didn't explain it very clearly before and thanks for the reply. AHA! I thought as much. Vpopmail will do what you want if you move .qmail-user into user/.qmail ~Kyle -- It is a dogma of faith that the demons produce wind, storms, and rain of fire from heaven. -- St. Thomas Aquinas, "Summa Theologica" signature.asc Description: Digital signature
Re: [vchkpw] Questions about vdelivermail
On Friday, July 8 at 11:52 AM, quoth Tren Blackburn: Hey List; Running vpopmail-5.4.10 and building sort of a dspam appliance. I have dspam enabled in the .qmail-default of the domain with the following line: | /usr/local/bin/dspam --deliver=innocent --mode=teft --user [EMAIL PROTECTED] --stdout | /home/vpopmail/bin/vdelivermail '' bounce-no-mailbox Okay... And I've created mailboxes on the server that I use only for authentication as I've got a .qmail file for each user that just forwards to the end server. In my telnet tests however, it doesn't seem like the message is even getting to vdelivermail...it's just being blasted through to the .qmail-user file in the domain directory (/home/vpopmail/domains/domain.com). Don't have .qmail-user files. When qmail has the message and is going to deliver it, it has been told to look in ~vpopmail/domains/domain.com/. It will deliver to the most specific .qmail file it finds. .qmail-default is a catch-all, while .qmail-user files are more specific. Why do you have .qmail-user files? I'm wondering how it would be possible to make this work, as I do not want any email actually stored on this server, but I do need the accounts on the server so users can authenticate to the dspam cgi program. Suggestions would be appreciated. I'm pretty confident it can be made to work. ~Kyle -- Genius may have its limitations but stupidity is not thus handicapped. -- Elbert Hubbard signature.asc Description: Digital signature
Re: [vchkpw] Qmail keeps failing!
On Thursday, July 7 at 09:18 PM, quoth [EMAIL PROTECTED]:
I was told to disable spamassasin for out going emails. (good point
but how?)
Depends on how you have it all set up. I understand you use
qmail-scanner? Basically, you want to unset QMAILQUEUE whenever
RELAYCLIENT is set. The easiest way is to add a shell script to your run
file. The basic run file looks like this:
tcpserver ${TCPSERVER_OPTIONS} qmail-smtpd
So change it to:
tcpserver ${TCPSERVER_OPTIONS} nospamforrelay.sh qmail-smtpd
Where nospamforrelay.sh is a shell script that looks like this:
#!/bin/sh
test "`printenv | grep RELAYCLIENT`" && unset QMAILQUEUE
exec $*
Or disable it all together (can't, this IP was identified and a prime
spam source when MS Exchange was running the email (go figure,
someone hacked Exchange 2003).
What's that got to do with spam filtering for outgoing email?
I can find no indication that I am scanning outgoing email at all, in
the Qmail scanner.
Because that's not qmail-scanner's purview. Check out The Big Qmail
Picture to familiarize yourself with how things work
(http://www.nrg4u.com/). Qmail-scanner gets stuck between qmail-smtpd
and qmail-queue, depending on the contents of the QMAILQUEUE environment
variable.
How do I find/verify and disable?
Does outbound email get tagged with X-Spam-Status headers? If so, then
you're scanning them unnecessarily. If not, then you're all set.
What are the key apps I should launch to see what or who has control
in qmail issues and why (i am aware of the obvious /var/log/ and
netstat and ps and the other very basics.)
vi /service/qmail-smtpd/run
;)
~Kyle
--
As we enjoy great Advantages from the Inventions of others we should be
glad of an Opportunity to serve others by any Invention of ours, and
this we should do freely and generously.
-- Benjamin Franklin
signature.asc
Description: Digital signature
Re: [vchkpw] Why does Inter7 opt Qmail?
On Tuesday, July 5 at 02:37 PM, quoth Steve Cole: Squirrelmail w/Zlib compression turned on Very good, and I like it - but no drag and drop. ;) hand before, and I currently use the Debian package -- they're about Great. Now apt-get install imapproxy, configure and marvel. :) Been thinking about it - figured if nobody was complaining about speed, I'd hold off. The best I've gotten here is a homemade tiny squirrelmail plugin that puts a link to qmailadmin on the squirrelmail login page. If anyone's interested, I can post it (though it's really and truly trivial). Sure, if it's a plugin. That would possibly save me some editing time for updates. http://www.memoryhole.net/~kyle/managelink_login-0.1-1.4.0.tar.gz ~Kyle -- The criterion of truth is that it works even if nobody is prepared to acknowledge it. -- Ludwig von Mises signature.asc Description: Digital signature
Re: [vchkpw] Why does Inter7 opt Qmail?
On Tuesday, July 5 at 06:19 PM, quoth Bruno Negrão: 3) We don't have personnel and don't intend to dedicade C programmers to develop patches for qmail by ourselves. Out of curiosity, how frequently do you find the need to patch qmail? I would have thought it was a "decide what it needs to do, patch qmail to do that, then install & ignore" kind of process. My boss actually dreams on making us a mail outsourcer for other companies.We are already a small ISP, but he dreams about our customers stop using their MS Outlook's to use our supposed beautiful webmail/domain-administration solution of his dreams. So he wants to know if there is something already close to it on the open-source market. He wants to know if there is something ready. (don't get mad with me, I'm just researching what he asked) Ahh... well, don't get too anxious for people to drop their MS Outlooks. I've yet to see a webmail that provides the speed and convenience (and offline access) that a good client-side mail browser can (not that I'm defending MS Outlook or anything). What's bad on inter7 tools? For example, my boss thinks Sqwebmail is ugly, and it really is. But, IMP is a pain in the ass to set it up. We substituted Sqwebmail to IMP, but when I have to update IMP I almost break down and cry. Sqwebmail is easy and ugly, IMP is handsome and very complicated to install. I've been very happy with squirrelmail. The interface is fairly customizeable (especially given that it's written in PHP with CSS stylesheets), it has a lot of useful plugins, and upgrading it is a breeze: just replace the folder full of php scripts (I've done it by hand before, and I currently use the Debian package -- they're about equally as easy). I can change the configuration per-domain by using the vlogin plugin (www.squirrelmail.org/plugin_view.php?id=47). Of course, ymmv. But we're happy with Qmailadmin though. But could be nicer if Sqwebmail and Qmailadmin were integrated and very good looking, providing a continuos look and feel pattern. The best I've gotten here is a homemade tiny squirrelmail plugin that puts a link to qmailadmin on the squirrelmail login page. If anyone's interested, I can post it (though it's really and truly trivial). But look at it this way: there's nothing in the license that says you can't take qmail, rename it to (mySweetMailserver, for example), and release it under the GPL. That nobody's done that says something. I don't understand about licensing, but I researching on Qmail-ldap, I heard it is licensed "under BSD which is DFSG-free" - having this licensing, could it be shipped with the distributions? Do you have some opinion on Qmail-ldap? Mmm, not exactly. Qmail-ldap is based on qmail (as I understand, it's a big patch to qmail). The patch itself has a license (BSD) which is separate from qmail-proper. However, I've never used qmail-ldap. Though all my account information is stored in ldap, I've stuck with using vpopmail's ldap support. Some ideas with webmail applications and domain administration? Definitely give squirrelmail a go. As far as domain administration goes... have you checked out Inter7's offerings? They have vqadmin, vqregister, and vqsignup which I think would do a lot of what you want. -- The longer I live the more I see that I am never wrong about anything, and that all the pains that I have so humbly taken to verify my notions have only wasted my time. -- George Bernard Shaw signature.asc Description: Digital signature
Re: [vchkpw] Why does Inter7 opt Qmail?
On Tuesday, July 5 at 02:37 PM, quoth Steve Cole: On Tuesday 05 July 2005 14:18, Listas barbarojo wrote: It has been developed in a modular way that makes it extreamly easy to add functionality to it and much more. Wrong. I has been developed in such a way that functionality has to be added in the form of patches, and it is suffering greatly from age now. qmail is very powerful and vpopmail makes it relatively simple to use, but it is stagnant, old, hard to use without patches and just plain old doesn't work at all if you try to use the original source on a modern system (it'll fail to compile or do strange things). Old? Yes. Hard to use without patches? Eh, I think netqmail has addressed that "problem". Stagnant? Depends on what you mean by that. I actually really like the way qmail works for the purpose --- I know exactly what it's doing, why, and how. Additionally, the patch method, while understandably hard or inconveninent for people who do not know C or who prefer the ./configure interface for turning on features, is a good way to do it for the security-paranoid who would rather trace out each addition rather than review code and try to untangle giant webs of #ifdef's. DJB let this baby into the wild, but didn't allow it to find its own way. If it weren't secure and relatively well supported, it would die. I'll go a step further, if it hadn't been a godsend in 1996 compared to Sendmail, it wouldn't have gone anywhere. But, times have moved on! DJB should let it go under some license - maybe BSD or GPL, so that the community can do something with it. UCSPI-TCP and Daemontools, too. I wish it had a license like that too. On the other hand, he put his name (and $500) behind it - something he really couldn't do if just anybody could add code to it and call it qmail. But look at it this way: there's nothing in the license that says you can't take qmail, rename it to (mySweetMailserver, for example), and release it under the GPL. That nobody's done that says something. It's also hard to program for. A lot of DJB's code relationships are like a foreign language. Not that it's wrong, just that it's difficult. I disagree - I find most of the code refreshingly straightforward. Comments might help, but I think it's really pretty simple to decipher. I'm relatively happy with vpopmail + qmail + patches, but saying that qmail is some wondrous software package is bunk. Heh, indeed - very little software is "wondrous". It's looking mighty old these days... You say that like "old" is a bad thing. vpopmail and qmail should be one package that gets distributed along with modernization patches, and it would be that way if DJB didn't have his claws of death on a piece of code that he last updated in 1997. That's abandonment, and the software really is starting to creak in terms of relevancy. "creak"? Gotta love loaded adjectives. I look at it this way: qmail was released in its current form in 1997, which is nearly a decade ago. In the fast-paced world of software development, like dog-years, that's practically a century ago. And yet, like the Franklin Stove, it still does exactly what it was designed to do. There've been some complaints about how you should install it (the default INSTALL isn't very good), how you compile it (glibc changed its interface), and some people dislike its lack of built-in support for features like smtp-auth (and work around it with patches or programs like mailfront). But in terms of complaints over nearly a decade, that's a stunningly low number of "problems", none of them actually serious. I think it says something about the ease of maintenance, ease of patching, and ease of configuration that qmail has lasted this long virtually unchanged. "Creak"? Far from it. While it may be harder to install than ./configure && make && make install, I don't see any reason to think qmail isn't up to the task anymore. ~Kyle -- I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. -- Gallileo signature.asc Description: Digital signature
Re: [vchkpw] Why does Inter7 opt Qmail?
On Tuesday, July 5 at 03:05 PM, quoth Bruno Negrão: does your boss have a rationale for his doubts, or are they based upon a 'gut' feeling? usually doubts arise based upon shortcomings. what shortcoming does your boss see in qmail (note, small 'q' - it is not "Qmail"). OK. He wants to know if there is a tendency on the market for some other mailserver. He asks me what mailservers the biggest linux/Unix distributors are using on their products. For example, what's the mailserver shipped with RedHat, Solaris, Mandrake, Debian, etc? I really don't know. I believe all of them are shipped only with Sendmail, but I'm not sure on this actually. Well, to answer your question directly: RedHat ships with sendmail, but seems to be planning to migrate to exim. Debian ships with exim. Solaris still ships with sendmail. Mandrake ships with postfix. MacOS X ships with postfix. SuSe ships with postfix. The last general internet survey that I saw still gave sendmail a comfortable lead. Recently I believe there's been a bit of a shift from sendmail to postfix from the major distributors. But let's examine this a little bit more closely: why does he care what the "tendency on the market" is? I mean, if your current email needs are being met, and your forseeable email needs will be met by your current system, then there's really only three valid reasons to change it: 1. The sysadmin (you) doesn't like the current setup 2. The sysadmin (you) might not have a job soon and the management is worried that the mail system might be unintelligible to his (your) replacement. 3. The current system has cost the company something (maintenance costs or embarrassing security intrusion, for example) Disturbing as that second thought may be, there's really no other good reason to change mail systems. And, the second one is the only one that has any relation to what the "tendency on the market" is. ~Kyle -- UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn signature.asc Description: Digital signature
Re: [vchkpw] Qmail Scanner error UnknownSender error
On Wednesday, June 8 at 04:03 PM, quoth [EMAIL PROTECTED]: I just redid my QMail Rocks installation again on Fedora Core 3. I did a lot more checking this time with SUIDPerl and made sure it was solid prior to install. Installation went error free. QMail is receiving email and sending them to our outlook clients. But. Sending mail will reach it's destination, but the scanner is stripping the header. Email arrive to their destination as UnknownSender and (no subject) there was info in both those fields when I sent them! Anyone have an idea what is causing this? Are you using the "formail" utility anywhere in your scripts before the mail gets sent? I once had a similar problem, where formail would add an mbox-style From header to the top of the email, which smtp servers would take as the first line of the body of an email without headers, and then things would get all mangled. ~Kyle -- Memory is like an orgasm---it's better when you don't have to fake it. -- Seymour Cray signature.asc Description: Digital signature
Re: [vchkpw] smtp authentication
On Wednesday, May 18 at 09:12 AM, quoth Payal Rathod: Can someone tell me which kind of SMTP-Auth patch (or qmail-smtpd replacement) integrates properly with vpopmail+qmail setup? I don't want to use mailfront for the same but I am open to other ideas where SMTP-Auth module can check the password from vpasswd files of vpopmail. I've been using the patch available here: http://www.fehcom.de/qmail/smtpauth.html for about three years on a production machine with vpopmail without trouble. ~Kyle -- Our lives begin to end the day we become silent about things that matter. -- Martin Luther King Jr. signature.asc Description: Digital signature
Re: [vchkpw] SMTP after POP
On Wednesday, April 27 at 04:28 PM, quoth Juraj Hantak: Hi, I have a question is smtp after POP feature supported in the newest Courier Imap? Courier IMAP provides neither SMTP nor POP service, so my guess is: no. ~Kyle -- Genius may have its limitations but stupidity is not thus handicapped. -- Elbert Hubbard signature.asc Description: Digital signature
Re: [vchkpw] [OT] Better Spam Detection
On Tuesday, April 26 at 10:21 AM, quoth Andrew Niemantsverdriet: I have been running qmail + vpopmail + qmailscanner + spamassassin + clamav for a while now. While some spam is caught our detection rate is not great. My qmail uses ordb and spamhaus and dsbl for rbl checking. I am using pretty much stock spamassassin rules. The only thing that is changed is it uses mysql for per user preferences. How can I improve our detection? What recommendations does the list have? I agree with most of the list - your options are: 1. enable all of the rules that spamassassin has (and install any necessary software a. Razor2 b. Pyzor c. DCC d. DNS rules 2. make sure that it is using and developing bayesian databases That much has gotten me a VERY good spam detection rate. Beyond that: 3. Add rules from some of the rule archives 4. Finally - examine the spam that doesn't get caught to try and determine patterns. Then you can write your own rules. ~Kyle -- Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve. -- Alan Perlis signature.asc Description: Digital signature
Re: [vchkpw] vpopmail misusing qmail's control files (Was: can't relay any more)
On Tuesday, April 19 at 04:34 PM, quoth Jeremy Kitchen: > I do know, however, that if you remove a domain from virtualdomains, > vchkpw will still function without problem. IMHO, this is wrong > behavior. What happens if you take a domain and move it into the > locals file, and use vchkpw configured with --enable-passwd for > authenticating local users? Where will vpopmail start when looking > where to authenticate? It SHOULD look in locals/virtualdomains first. Well, there's something to be said for rejecting domains that aren't in virtualdomains, I agree. > vpopmail has to determine where to look for the password database to > authenticate against, as well as telling qmail how to deliver the > messages to vpopmail. It's only logical that it would follow the same > lookup mechanisms qmail does in order to find where a domain's home > directory is. Fair enough. Cut-and-paste from qmail's source, I imagine, right? > > Imagine this: you used to have lists.domain.com as a vpopmail > > domain, just to logically separate out your mailing lists (like > > list.cr.yp.to). Then you decide that you want to migrate that domain > > from ezmlm to GNU Mailman... but it's still on the same machine, so > > it still has an entry in virtualdomains. Should vpopmail be able to > > detect that the virtualdomains redirection of mail no longer sends > > mail to vpopmail but to a mailman frontend script? > > sure, but why does it need to? It would look up the domain in > virtualdomains, find out what user the domain belongs to.. find out > where the domain is located (either because of a listing in > users/assign or an /etc/passwd entry, etc) go to that directory, and > look for a vpasswd.cdb file. If it finds one, it tries to > authenticate the user using it.. if it does not find one, it assumes > the domain is not vpopmail and rejects the authentication. It can't rely on the presence of a vpasswd.cdb file - it might be that all the user records were stored in ldap or mysql. ... and if I do that, then migrate a domain as I describe, then I, the administrator, need to change the ldap/mysql database - which is akin to fully deleting the domain rather than just twiddling my virtualdomains config file and assuming it'll Just Work (tm). > vdelivermail doesn't care about domains.. it simply cares about environment > variables passed to it via qmail-local. I know. > > What if, instead, I wanted to merely move > > where lists.domain.com gets delivered and stored (not that I can come up > > with a good reason for wanting to do so, but its certainly within my > > rights as an admin)... should vpopmail follow the virtualdomain entries > > out to the eventual delivery to make sure that they're getting delivered > > to a vdelivermail script? > > find out where the domain's directory should be and look for a vpasswd.cdb > file.. I don't see the complication. They don't have to be there, obviously. > > Upon reflection, I think there's probably too much flexibility in the > > virtualdomains setup for vpopmail to parse and attempt to interpret the > > qmail virtualdomains file fully. It could take a simplistic approach, > > but that simplistic approach would limit the configurable power of > > qmail. If you start throwing qmail-users into the mix, it becomes > > astonishingly complex for vpopmail to decide whether or not a given > > address is going to be delivered to a vpopmail domain. > > not overly, unless you're using address-based virtualdomains entries, which > are extremely rare, and not relevant to the architecture of vpopmail. If I use virtualdomains to change the extension delimiter (to, say, an underscore rather than a hyphen), it's still valid to send it to a vpopmail domain, but would confuse the heck out of a chkuser patch unless it fully supported all the permutations of configuration that I can swizzle into my virtualdomains file. Then let's say I have another virtual domain that I want set to deliver to a virtual user, configured like so: domain1.com:domain1.com domain2.com:domain1.com_joe Will I confuse vchkpw? How much of this should it actually be responsible for? Now let's say I have a different server for people in my company to use for sending (and authenticating) than I do for storing my domain's email. This machine may have an empty rcpthosts and virtualdomains file, because it's not supposed to receive un-authenticated mail. Why should it be required to deliver un-authenticated mail just to make vchkpw work? Why does it need access to my mailstore backend? I'm not saying it couldn't be done, I'm just saying it's more complicated and more restrictive than you seem to imply and don't think such "features" are a requirement for a decent virtual domain package. ~Kyle -- The liberty of a democracy is not safe if the people tolerate the growth of a private power to a point where it becomes stronger than the democratic state itself. -- Franklin
Re: [vchkpw] can't relay any more
On Tuesday, April 19 at 03:24 PM, quoth Jeremy Kitchen: > On Tuesday 19 April 2005 03:04 pm, Kyle Wheeler wrote: > > On Tuesday, April 19 at 12:32 PM, quoth Jeremy Kitchen: > > > On Monday 18 April 2005 10:48 pm, Rick van Vliet wrote: > > > > You're right -- Thought I had that one. :\ > > > > But if we can stretch this topic - why doesn't vpopmail 'pay attention > > > > to locals or virtualdomains'? Is it just late and I'm space-y? > > > > > > It doesn't do it for any real reason, it just does it because it was > > > poorly designed, and nobody has changed it. > > > > What do you expect it to do? > > I expect it to look at the virtualdomains file to determine what user the > domain should be handled by (or that it's even there!) and then look up the > user using standard qmail lookup procedures (check qmail-users first, then > system users) > > I recently had a problem with a customer who was moving one of his domains to > an exchange server but leaving the qmail server in place for filtering. I > took the domain out of virtualdomains and sent qmail-send a HUP signal, > however, the chkuser patch was still looking for 'valid' users inside the > vpopmail databases. This is wrong behavior on vpopmail's part. Wouldn't that instead be wrong behavior on the chkuser patch's part? I imagine vchkpw would need to be altered to do the same to prevent people from authenticating to the wrong server. On the other hand, how many software products do you use that parse the config files of other systems? Do many sendmail milters parse the /etc/sendmail.cf? Should php parse apache's config files? I'm not saying it wouldn't be useful if vpopmail did go through qmail's config files, especially since they're so semantically simple; I think it would be a good idea! But does that necessarily make ignoring the config files of a separate piece of software WRONG? I don't think so. Imagine this: you used to have lists.domain.com as a vpopmail domain, just to logically separate out your mailing lists (like list.cr.yp.to). Then you decide that you want to migrate that domain from ezmlm to GNU Mailman... but it's still on the same machine, so it still has an entry in virtualdomains. Should vpopmail be able to detect that the virtualdomains redirection of mail no longer sends mail to vpopmail but to a mailman frontend script? What if, instead, I wanted to merely move where lists.domain.com gets delivered and stored (not that I can come up with a good reason for wanting to do so, but its certainly within my rights as an admin)... should vpopmail follow the virtualdomain entries out to the eventual delivery to make sure that they're getting delivered to a vdelivermail script? Upon reflection, I think there's probably too much flexibility in the virtualdomains setup for vpopmail to parse and attempt to interpret the qmail virtualdomains file fully. It could take a simplistic approach, but that simplistic approach would limit the configurable power of qmail. If you start throwing qmail-users into the mix, it becomes astonishingly complex for vpopmail to decide whether or not a given address is going to be delivered to a vpopmail domain. ~Kyle -- The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding. -- Brandeis signature.asc Description: Digital signature
Re: [vchkpw] can't relay any more
On Tuesday, April 19 at 12:32 PM, quoth Jeremy Kitchen: > On Monday 18 April 2005 10:48 pm, Rick van Vliet wrote: > > You're right -- Thought I had that one. :\ > > But if we can stretch this topic - why doesn't vpopmail 'pay attention > > to locals or virtualdomains'? Is it just late and I'm space-y? > > It doesn't do it for any real reason, it just does it because it was poorly > designed, and nobody has changed it. What do you expect it to do? I expect to be able to use my virtualdomains file for more than JUST vpopmail domains (for example, I have several lists.* domains that are handled exclusively by GNU Mailman). ~Kyle -- Power always thinks it has a great soul and vast views beyond the comprehension of the weak; and that it is doing God's service when it is violating all his laws. -- John Adams signature.asc Description: Digital signature
Re: [vchkpw] qmail send service is not running
On Monday, April 18 at 12:49 PM, quoth Jeremy Kitchen: > On Saturday 16 April 2005 01:47 pm, Jan-Willem Regeer wrote: > > On Apr 13, 2005, at 4:32 AM, Manish Jain wrote: > > > Dear all, > > > My qmail send service is no trunning. > > > > > > Help!!! > > > Dear all, > > My car is not running. > > have you tried replacing the back passenger side tire? If that doesn't fix it, my guess is you're out of headlight fluid. ~Kyle -- The real problem is not whether machines think, but whether men do. -- B. F. Skinner signature.asc Description: Digital signature
Re: [vchkpw] how to do simple vpopmail delivery with filtering
On Friday, April 8 at 10:38 PM, quoth Tom Collins: > Are safecat and/or maildir quota-aware? Safecat is not, and shouldn't be (it does not identify itself as strictly a maildir delivery mechanism). The maildir shell script wrapper around safecat, I do not know... but I doubt it works very hard at it. How hard would it be to check the quota stuff from a shell script? ~Kyle -- Never think that war, no matter how necessary, no matter how justified, is not a crime. -- Ernest Hemingway signature.asc Description: Digital signature
Re: [vchkpw] how to do simple vpopmail delivery with filtering
On Friday, April 8 at 09:33 AM, quoth Charlie Garrison: > And now I want to learn more about '|preline'. Could someone point me > to the documentation for that? man preline or, if you don't have it set already... env MANPATH=/var/qmail/man man preline and, if for some reason, you deleted the man page, you can find a copy of it here: http://www.qmail.org/man/man1/preline.html ~Kyle -- Dealing with failure is easy: Work hard to improve. Success is also easy to handle: You've solved the wrong problem. Work hard to improve. -- Alan Perlis signature.asc Description: Digital signature
Re: [vchkpw] how to do simple vpopmail delivery with filtering
On Friday, April 8 at 12:13 AM, quoth Charlie Garrison: > >And so you can have a pure-vpopmail solution for your > >QmailAdmin-enabled Spam Detection option. > > I feel like someone arriving late at the party. I can't find any spam > detection options in qmailadmin. I am using the latest stable release; should > I be using a development release? Is there any online documentation you can > refer me to? When you run ./configure for QmailAdmin, you can use the --enable-spam-command="blah blah blah", and that will enable the "Spam Detection" feature of QmailAdmin. It's in the documentation... check out the INSTALL file (http://cvs.sourceforge.net/viewcvs.py/qmailadmin/qmailadmin/INSTALL?rev=1.7) ~Kyle -- The real problem is not whether machines think, but whether men do. -- B. F. Skinner signature.asc Description: Digital signature
Re: [vchkpw] how to do simple vpopmail delivery with filtering
On Wednesday, April 6 at 06:38 PM, quoth Tom Collins: > By the way, I plan to revisit the vdelivermail code sometime (hopefully > soon) and have it set the environment variables correctly, to match > what qmail-local would set if it was a non-virtual domain. > > This should make some of your .qmail and other scripts easier to > write... Excellent - I would definitely appreciate it. ~Kyle -- Well, I've wrestled with reality for over thirty five years, doctor, and I'm happy to state I finally won out over it. -- Jimmy Stewart, in "Harvey" signature.asc Description: Digital signature
Re: [vchkpw] how to do simple vpopmail delivery with filtering
On Wednesday, April 6 at 02:50 AM, quoth danielcm: > > On Apr 5, 2005, at 9:28 AM, Kyle Wheeler wrote: > > > > > > >What you *want* is this: > > > >| preline yourfilter | maildir $vpophome/$domain/$user/Maildir/ > > > >(maildir is from the safecat package) > > > >However, vpopmail steadfastly refuses to set up the environment for > >it's > >.qmail processing in a convenient way (or even a qmail-compatible way), > >so what you can do is approximate it like this (all on one line): > > > >| preline yourfilter | maildir /path/to/vpopdomains/`echo $USER | tr > >A-Z > >a-z`/`echo $EXT | tr A-Z a-z`/Maildir/ > > > > > > I don't think it needs to be that complicated, all I have is: > | preline yourfilter | /usr/local/bin/maildir.sh ./Maildir/ > > My maildir.sh file is: > exec /usr/bin/safecat "$1"/tmp "$1"/new > > works for me since the .qmail file is in the users home directory. Really? When I check out the environment from one of those .qmail files (e.g. by creating a qmail file containing: | printenv > /tmp/env That file contains the line: PWD=/var/lib/vpopmail/domains/memoryhole.net Indicating that if I directed it to ./Maildir/ it would deliver to /var/lib/vpopmail/domains/memoryhole.net/Maildir/ which of course doesn't exist. Just because the .qmail file is in the user's home directory doesn't mean it's PWD is the user's home directory. If vpopmail actually does deliver to /var/lib/vpopmail/domains/memoryhole.net/user/Maildir/ when I put ./Maildir/ into my user's .qmail file, then it's behaving incorrectly. The environment SHOULD be set identically to if the virtual user was a real user and qmail was doing the delivery. ~Kyle -- I would be delighted to offer any advice I can on understanding women. When I have some I'll let you know. -- Jean Luc Picard signature.asc Description: Digital signature
Re: [vchkpw] how to do simple vpopmail delivery with filtering
On Tuesday, April 5 at 01:24 AM, quoth Kurt Bigler: > > NOTE: This command must deliver the mail) > > Particularly the last line is of interest. Indeed. > All I need is to satisfy that requirement that the command must > deliver the mail. I want it delivered exactly as vdelivermail would > have delivered it, but I want to pipe it through my filter on the way > out. > > I have been able to prototype my filtering functionality in a .qmail-user > file in one of my domain directories as follows: > > | myfilter | /var/vpopmail/bin/vdelivermail '' bounce-no-mailbox > > I have been testing this for several days and this approach is working fine. Yes, however, this approach will not work as the QmailAdmin spam-command. It will create a loop (i.e. vdelivermail sends it to your filter, which pipes it to vdelivermail, which sends it to...). > However, it is a hack (and doesn't play well with qmailadmin), and what I > really want to do is to be able to use something like this in the > user/.qmail file instead: > > | preline myfilter | simple_vpopmail_final_delivery What you *want* is this: | preline yourfilter | maildir $vpophome/$domain/$user/Maildir/ (maildir is from the safecat package) However, vpopmail steadfastly refuses to set up the environment for it's .qmail processing in a convenient way (or even a qmail-compatible way), so what you can do is approximate it like this (all on one line): | preline yourfilter | maildir /path/to/vpopdomains/`echo $USER | tr A-Z a-z`/`echo $EXT | tr A-Z a-z`/Maildir/ > My assumption is that what I am calling simple_vpopmail_final_delivery > is in fact the last stage of what vdelivermail does, and if so I'm > wondering if there is any architectural reason why this piece of > functionality could not be made available as a separate command, > perhaps even as vdelivermail with another command-line option to > suppress prelinining and other functionality associated with the > user/.qmail file. It would HAVE to ignore the .qmail file, otherwise you passing mail to it from within the .qmail file would create a loop. That, or to prevent people from destroying their own mail servers, it would have to have it's own loop detection. > In the mean time, what is the best (simplest, most reliable) way to > achieve > this simplistic delivery functionality? I think "maildir" (or "safecat") is what you want to use. If you think the environment manipulation is a bit much, I agree, but them's the breaks, at the moment. ~Kyle -- Science is like sex: Sometimes something useful comes out, but that is not the reason we are doing it. -- Richard P. Feynman signature.asc Description: Digital signature
