Re: [vchkpw] processing .qmail files for all users
Hi, On Tue, 2005-05-24 at 12:04 -0400, Payal Rathod wrote: In a qmail + vpopmail setup, I would like to run, | /path/to/script in .qmail file for all users. Is there any eay way of doing it? You can do it in the .qmail-default file. Change: | /path/to/vpopmail/vdelivermail '' bounce-no-mailbox to: | /path/to/script | /path/to/vpopmail/vdelivermail '' bounce-no-mailbox - you still have to do it with every domain thou... /Anders
Re: [vchkpw] processing .qmail files for all users
Hi again, On Tue, 2005-05-24 at 12:24 -0400, Payal Rathod wrote: In a qmail + vpopmail setup, I would like to run, | /path/to/script in .qmail file for all users. Is there any eay way of doing it? You can do it in the .qmail-default file. Change: | /path/to/vpopmail/vdelivermail '' bounce-no-mailbox to: | /path/to/script | /path/to/vpopmail/vdelivermail '' bounce-no-mailbox But qmail-default is not looked at when the user has a .qmail file of her own, maybe for forwarding mails or something like that. Are you sure about that? What do I do in such case? Is it really a problem? /Anders
Re: [vchkpw] Troubles running make
Hi, On Tue, 2004-05-04 at 21:50, Patrick Donker wrote: Anybody willing to comment on my problem, or are there only 3 people on this list? From my experience, there is lots of clever and helpful people on this this list and in the vpopmail community in general. Have patience ;) About your problem - I don't know much about automake, sorry... /Anders
Re: [vchkpw] php extension or daemon
Hi, On Fri, 2004-04-02 at 03:46, Iavor Raytchev wrote: The main stumbling block seems the need to run Apache as vpopmail user. I have not investigated deep enough, but this seems to be one of the main reasons why the extension is somehow dead. Just from the top of my head, wouldn't Apache 2 solve this? Doesn't it allow for different UID/GID for different virtual hosts? Disclaimer: I could very well be completely wrong about this, but check it out! Hmm, and as of this writing, i decided to look at it myself: Special note: Use of this directive in VirtualHost is no longer supported. To configure your server for suexec use SuexecUserGroup., see: http://httpd.apache.org/docs-2.0/mod/mpm_common.html#user Hmm... /Anders
Re: [vchkpw] vpopmail 5.4.0 Make error on Solaris 9 (possible solution)
Hi, On Thu, 2004-02-26 at 21:09, Shiraz wrote: Did the steps to include nsl and socket libs for make of vpopmal v5.4.0 on Solaris 9 (sparc) with gcc 3.3.2. However, I am still getting the following error: gcc -g -O2 -Wall -o vchkpw vchkpw.o md5.o hmac_md5.o libvpopmail.a -L/usr/local/mysql/lib -R/var/qmail/vpopmail/lib -lmysqlclient -lz -lcrypt -lnsl -lsocket Undefined first referenced symbol in file floor /usr/local/mysql/lib/libmysqlclient.a(password.o) ld: fatal: Symbol referencing errors. No output written to vchkpw collect2: ld returned 1 exit status make[2]: *** [vchkpw] Error 1 Any other lib is missing. Help..? libm? use -lm /Anders
Re: [vchkpw] Heureka! Finished POP3-Frequency-Patch (against bruteforcing)
Hi, On Thu, 2004-02-12 at 01:21, knom wrote: I finished the Patch forqmail-pop3d which doesn't allow more then xx logins every yy seconds. Please see my post to the sourceforge tracker [874660]. Can we see the patch anywhere? If you log in more often then eg. 10 times in 5 minutes you get an error message which says, that you have to wait xx minutes until relogin. Thats quite good against pop3 bruteforcing, I think ! - and, not to nitpick - but imho it's a bad idea to show the timeout. It would be a handy tool for DOS'ers. They could easily optimize the attack specific to your site. /Anders
RE: [vchkpw] Heureka! Finished POP3-Frequency-Patch (against bruteforcing)
Hi, On Thu, 2004-02-12 at 02:15, Jake S wrote: Also, perhaps instead of you have to wait xx minutes maybe you can just list 0 messages. The idea of listing 0 messages (as new) could lead to some support nightmares. A customer consequently using the wrong password, and there is no sign that anything is wrong - or worse, some third malicious part causing this. /Anders
RE: [vchkpw] Eureka! Finished POP3-Frequency-Patch (against brute forcing)
Hi, On Thu, 2004-02-12 at 04:40, Jake S wrote: Also, perhaps instead of you have to wait xx minutes maybe you can just list 0 messages. The idea of listing 0 messages (as new) could lead to some support nightmares. A customer consequently using the wrong password, and there is no sign that anything is wrong - or worse, some third malicious part causing this. I'm not seeing your logic if a user has made it to checking their inbox then the credentials would have already been checked via vchkpw, correct or not and the appropriate errors would be listed. Oh i see - I thought you meant it should return 0 new messages for bad user/password - but you actually meant 0 new messages as response to correct user/password, but only after x failed tries? Also, with a timeout error code your bound to get support calls asking if you can bend the rules for that user because they have a very important message (usually larger penis ads) verses you simply say no new messages and no one knows the difference. If you just say no new messages, it can go on for month without the user knowing it. It only takes one malicous attacker x failed authentication attempt every y minutes to effectively suspend mail delivery. And instead you will receive support calls/emails that goes like I NEED THAT EMAIL NOW!!! MY CLIENT SENT IT LIKE 20 YEARS AGO, AND IT STILL ISN'T HERE!!! SOMETHING IS WACKED WITH YOU PEOPLE!! (Yep, smile! :-)) /Anders
RE: [vchkpw] vchkpw and courier 2.2.2 (probably a bug)
Hi, On Wed, 2004-01-14 at 11:24, Andrea Riela wrote: Try something simple like telnet 127.0.0.1 pop3 user [EMAIL PROTECTED] pass password I've tried with courier pop3. observe# telnet 127.0.0.1 110 Trying 127.0.0.1... Connected to 127.0.0.1. Escape character is '^]'. +OK Hello there. USER [EMAIL PROTECTED] +OK Password required. PASS test +OK logged in. LIST +OK POP3 clients that break here, they violate STD53. Is this an error or a warning? It does return +OK and nothing seems wrong about the output? Is there actually any mail waiting? Please double-check. /Anders
Re: [vchkpw] Managing vpopmail from remote server
Hi, On Wed, 2004-01-07 at 20:27, Mauricio Teixeira (listas) wrote: Is there a tool or magic way to manage vpopmail info from a remote server? Not afaik. How can I make this tool communicate to the remote vpopmail server and manage the existent users and domains? How about using ssh with RSA-authentication and a small wrapper for vpopmail functions? /Anders
Re: [vchkpw] vpopmail MD5 vs squid MD5
Hi, On Thu, 2004-01-08 at 02:43, toblo wrote: I found a workaround for this. I disable the MD5 password encryption at vpopmail (configure --enable-md5-password=n), thus it uses linux crypt encryption which is recodnized by squid. Could you please paste an example of one of those passwords including cleartext? (I know you pasted from squid, but please let us see one) /Anders
Re: [vchkpw] Disabling an account in vpopmail (using valias)
Hi, On Fri, 2004-01-02 at 18:54, John Councilman wrote: I am aware that in a standard dot-qmail file, you can disable an account by putting a # in the file, but the same does not seem to work with valias. I was trying to put a # in valias_line, and vpopmail tries to deliver to [EMAIL PROTECTED] Seems like a valias-bug... Does anyone have any ideas on how to disable an account? What about cat - /dev/null? You just want the mail to disappear? Use this: |exit 99 - or you can bounce all with: |exit 100 /Anders
Re: [vchkpw] Re: Inserting new users via mysql-insert into the vpopmail database
Hejsa, On Fri, 2003-11-07 at 00:21, Tom Collins wrote: Narrowing the possible scope for each letter to 64 from some larger group but increasing the entropy that goes into selecting each character seems like a good idea to me. Remember that we're only selecting 8 random characters -- that's about 40-bits of random numbers. No one has shown that the current method results in a limited set of possible passwords. I'm not arguing against using /dev/[u]random, I'm just saying that it's possible to over-engineer a random password generator... Let's calculate some randomness :) (8 characters from a 128 letter pool: 56 bits) 8 characters from a 80 letter pool: 50 bits 8 characters from a 64 letter pool: 48 bits I'll say it's an acceptable loss eliminating those letters that can easily be confused... Making use of /dev/urandom and/or /dev/random will be high on our priority list for the 5.5 development series. You wan't patches? That would be a nice project for little me... /Anders
Re: [vchkpw] vdelivermail EXITCODE problem
Hi, On Tue, 2003-09-30 at 10:09, [EMAIL PROTECTED] wrote: So I upgraded to the last stable version 5.2.1 whereas the changelog said that within 5.2.1 the EXITCODE checks would be performed. Vpopmail 5.2.1 fails to catch exitcode 100. Here is a patch: http://fmail.dk/stuff/vpopmail-5.2.1-vdeliver-command-100.diff Hope this helps. /Anders
Re: [vchkpw] Feature request for vaddaliasdomain
Hi, On Wed, 2003-09-24 at 23:31, Tom Collins wrote: A feature request for vaddaliasdomin. I would like a configure option (best) or a command-line switch (not so good) that reverses the order of the two arguments. I'd like it for two reasons: What if it was automatic? A bit odd to document, but otherwise a fabulous idea. vaddaliasdomain x.com y.com If both x.com and y.com exist, exit with an error. If x.com exists, make y.com an alias to it. If y.com exists, make x.com an alias to it. If neither exists, exit with an error. It shouldn't be difficult to do -- you can use vget_assign() to see if the domain exists. Please see SF Patch 812150 - It does exactly what you proposed here. http://sourceforge.net/tracker/index.php?func=detailaid=812150group_id=85937atid=577800 /Anders
Re: [vchkpw] Re: Feature request for vaddaliasdomain
Hi, On Thu, 2003-09-25 at 03:26, Paul L. Allen wrote: A bit odd to document, Damn right. I still haven't figured out a sensible usage message. I think we should just ignore the old way of calling vaddaliasdomain in the usage message, in that way new users will adobt the new way of doing things. The autosensing will ensure that we don't brake old script etc. but otherwise a fabulous idea. Bad Anders. Bad, bad, Anders. Letting people do what they find easiest is BAD. Ask the people who criticised me for suggesting it. I will NOT participate in that discussion. I provided a simple patch, try it, test it, feel it. No more, no less. [snip] /Anders
Re: [vchkpw] Re: Feature request for vaddaliasdomain
Hi, On Thu, 2003-09-25 at 03:46, Paul L. Allen wrote: I think we should just ignore the old way of calling vaddaliasdomain in the usage message, in that way new users will adobt the new way of doing things. Ummm, that implies that one way is more correct than the other. I do not believe that to be the case. I believe that one way is more natural to some of us than the other and that each of us should be able to use the interface we prefer. Well... I have nothing to say. The autosensing will ensure that we don't brake old script Yeah, old scripts will still work. But old sysadmins like me will get confused (I'm old, it's nearly 3am and I've had a lot of wine so I'm easily confused). We do something and it works and then later we look at the usage message and find that it COULD NOT HAVE WORKED. That causes to go diving into the code to see what the hell is happening... The usage message MUST explain both alternatives. It will be a little clumsy, to be sure, but it must explain both alternatives. Hummm Or something like: ... the two domains to be aliased ... - without saying which is which, for the user it doesn't matter much. A usage like: vaddaliasdomain [options] domain-a.tld domain-b.tld - nothing to be confused about. /Anders
Re: [vchkpw] Re: courier-imap / sql files
Hi, Phew, this mail is getting longer and longer... On Fri, 2003-09-12 at 04:23, Paul L. Allen wrote: It could get rather unwieldy if you use MySQL for other things. Why? Just a gut feeling that if you have many MySQL users for one purpose and many more MySQL users who are there purely as a fiddle to allow vpopmail to work then it could make life difficult to distinguish the two. But I am easily confused. :) IMHO it's the correct (tm) way to do things. It's not just a fiddle, it's the best solution. I would say that the setuid-thing is a fiddle. It could easily be done with vadddomain, the user must pre-exist as it is now, vopmail just have to create the .mysqlpass-file or whatever it is called. Or am i missing something here? Yes, you're missing me having to do two things instead of one. There are ways of setting up vpopmail so that if I add a system user then they automatically get mail. Yes, those solutions are non-standard hacks using custom scripts but they exist. My work is finished after I do useradd. Every time I have to do two things to add a user it not only increases my workload it increases the chance that I do one but not the other. As I think I may have said, I am easily confused. :) I think we confused eachother, we were talking about two different cases. I: When domain.tld is given a systemuser for their mail. You: When systemusers needed personal mail. - and now i can see the trouble ahead, but not that much trouble. [snip, user types] different usage patterns. For instance, the quota stuff is essential for a company wanting to offer a hotmail/yahoo/whatever service. For us it gets in the way of us billing people extra for going over their allotted usage. OT: We use the billing-model too :) But we also have skilled users, the kind that just sends you the conf-file, the kind that writes their own zone data. The kind that never calls, and when they do - you KNOW that they have a very good reason to do so. They could make ther own internal php-tools for example, You let your users play with PHP? I hope you have something that emulates suexec so you have some rudimentary protection against them using it to explore the filesystem. Then again, in your environment it may not matter. In ours PHP without an suexec equivalent would be a disaster. PHP, without modifications, is a security nightmare for any user who wishes to have a web interface create or modify files. When you have to make directories world-writeable or writeable by the UID of the HTTP server then you have a security nightmare. Let's leave PHP-(in)security out of this. setuid programs can be a very nice solution to many problems, but i think that we should consider the possibility of just using standard filelevel security. That's something that has been audited and proven for years. Ummm, I don't trust ANYTHING. I remember when the third edition of the Camel book came out reading of many attacks that had not been mentioned in the 2nd edition because they had not been known then but had always been present. How about the race hazard when executing shell or perl scripts (these days largely eliminated)? How about the many race hazards suexec is vulnerable to (I know of no exploits and the checks it does are better than no checks at all)? As we both know, the only way to secure your computer is to ensure it has no connections to the outside world and you are the only one who has physical access - as soon as you relax those constraints you are taking risks. The question is: is this particular solution playing Russian Roulette with 5 out of the 6 chambers loaded or only 1 of the 6 chambers loaded... Very well said about the roulette thing. It's a great idea to have several small tools to do tasks, my point was just that it's not enough to return 0 or 1 (or 57). Again, I was illustrating how the simple case of password authentication (without APOP) would go. The idea was to establish the general model for doing this sort of thing with setgid cleanly. I was illustrating that it could quickly get hairy, when arguments have to be passing to/from these tools. Mainly the passing of arguments to/from these tools. If it were just TRUE/FALSE-returns i would be all for it - well, almost ;-). I always envisaged that these tools would be passed arguments - you [snip] I think we already adressed this - and agreed... Set-id code is not without known hazards and there may be unknown hazards. I was addressing the question of whether there was any way of doing things relatively securely with set-id code. I don't think the risks are significantly higher than with qmail set-id code and I think they are vastly lower than with sendmail's monolithic, gigantic block of set-id code which has been exploited many times. Ohh boy i'm glad we are on a qmail-oriented list, elsewise we would have the great sendmail-flamefest now :) I really don't know
Re: [vchkpw] Re: courier-imap / sql files
Hi Paul and others, On Fri, 2003-09-12 at 14:32, Paul L. Allen wrote: IMHO it's the correct (tm) way to do things. It's not just a fiddle, it's the best solution. I would say that the setuid-thing is a fiddle. I think which way you regard as a fiddle depends very much upon what you do on your system. Yep indeed :) I think we confused eachother, we were talking about two different cases. I: When domain.tld is given a systemuser for their mail. Ah, we don't do that. We probably could, since we have to give them a system user to FTP their web site, but why bother when vpopmail lets you get away with a single user? Extra security? I've always hated the vpopmail model, all users are one user Oh, unless you're using a PHP webmail [snip] There could be many other reasons to give domainmail-admins system-users. Admin'ing mailinglists for one. You: When systemusers needed personal mail. - and now i can see the trouble ahead, but not that much trouble. The trouble is that vpopmail can be used in so many different ways. Yep, or maybe the biggest feature. But hey, qmail is delivering to systemusers isn't it? vdeliver doesn't even get run? I was illustrating that it could quickly get hairy, when arguments have to be passing to/from these tools. I think argument and value passing is reasonably well understood, relatively easy to code and the methods of avoiding buffer overflows known if not always widely applied. Provided the utilities are restricted to reading and writing the database it should be easy to ensure there are no known exploitable holes. But theres much more to it than buffer overflows. How do we trust the calling program, for one thing? Ohh boy i'm glad we are on a qmail-oriented list, elsewise we would have the great sendmail-flamefest now :) Indeed. But it's a valid point. Given the number of systems running [snip] I didn't say that it wasn't a valid point! /Anders
Re: [vchkpw] OT: sourceforge management
Hi, On Wed, 2003-09-10 at 21:09, Ken Jones wrote: Does anyone know how to delete a project at sourceforge. http://sourceforge.net/docman/display_doc.php?docid=14041group_id=1#projectremoval /Anders
Re: [vchkpw] courier-imap / sql files
Hi, On Thu, 2003-09-11 at 22:47, Tom Collins wrote: On Thursday, September 11, 2003, at 01:22 PM, Ken Jones wrote: The issue about sql login being compiled in also brings up another issue.. By putting the sql information into a ~vpopmail/etc file it solves the issue as long as all email domains are owned by vpopmail. If any domains are under a non-vpopmail user, then the sql information file needs to be readable by all. In that case I would recomend not allowing shell access, and chrooting ftp access to a users home directory. This is an interesting point and I'd love to find a clean solution to this issue. Me too, have been thinking about it for long time now (not getting much closer to a solution) Are you saying that it's possible to run some of the vpopmail utilities as a user other than root or vpopmail? I figured that for the add/del/mod domain commands, you'd have to be root since they modify qmail control files. When running vchkpw on a system that uses cdb, it needs read access to the vpasswd file in the domain directory. qmail setuids/setgids to the user/group in /var/qmail/users/assign. I see three solutions... Possibly many more :) 1) More finegrained mysql-permissions. vedelivermail can only read what it's supposed to know. Should not be able to write to anything but log, from which it can't read (like the syslog-model, everybody can write logs, root can read) 2) Make vdelivermail setuid (vpopmail), and do setuid to the real virtualuser-uid after all db stuff. This would be clean, effective and dangerous. 3) Make a mysql-user for each system-user using vpopmail, nightmare - but maybe the cleanest way to do it. The mysql-information could be stored in the domain (system-user) homedirectory, almost as mysql do it default. Say something! Can anyone think of other apps that have to deal with the issue of storing MySQL login information securely? Sorry no. /Anders
Re: [vchkpw] Re: courier-imap / sql files
Hi, On Fri, 2003-09-12 at 01:17, Paul L. Allen wrote: This is an interesting point and I'd love to find a clean solution to this issue. I don't think you'll find a clean solution which doesn't involve set-id. All the others are messy to administer, like a MySQL username per system user or adding a special group to every user (do all *nixes handle that well these days?) If you add a special group to every user you are back where you started. I can't see what's wrong with a mysql user per system user. That would be really clean and effective. If the admistrative tools is integrated into vpopmail, i fail to see any troble ahead (user/admin-vice). It would completely remove any use for any setuid/setgid-hacks. It will also remove the possibility of users injecting sql into any data not belonging to them. One problem would be the table-layout, the vpopmail-table would be useless for example. How about this: 1) An additional user and group, vpsql, used for absolutely no other purpose (except perhaps as owner of vpopmail database). 2) MySQL username and password in a file readable only by vpsql user and group, and writeable only by vpsql user (if that - most people will probably edit it as root). 3) A very small utility that is setgid vpsql. It does the following when passed a username and password to verify. You will also need small tools to do all other sorts of operations, quota, valias and so on. a) Reads the information in the password file. b) Drops setgid so it can do nothing further with the password file. c) Connects to MySQL. - and forgets username and password. e) Verifies mail username and password against database. f) Returns go or no-go. It's not as simple as that, think about APOP authentication... [snip]
Re: [vchkpw] Re: courier-imap / sql files
Hi, On Fri, 2003-09-12 at 03:16, Paul L. Allen wrote: If you add a special group to every user you are back where you started. I didn't say it was a good solution. I said it was a solution. Compared to that, a lot of the alternatives look good. Agree, alternatives are better. I can't see what's wrong with a mysql user per system user. That would be really clean and effective. It could get rather unwieldy if you use MySQL for other things. Why? If the admistrative tools is integrated into vpopmail, i fail to see any troble ahead (user/admin-vice). I can see one. I set up a system user. Who wants e-mail. So then I have to use another tool to add that user to vpopmail. It could easily be done with vadddomain, the user must pre-exist as it is now, vopmail just have to create the .mysqlpass-file or whatever it is called. Or am i missing something here? Another possibility it will open, is the users who administer their mail with shell-access (mailinglists, other things) could have access to their vpopmail-databases and do with them as they like. They could make ther own internal php-tools for example, their own weird scripting. I think maybe this could be a big selling point. It would completely remove any use for any setuid/setgid-hacks. That is the one advantage I see to it. Whether or not one views that advantage as compelling is another matter. setuid programs can be a very nice solution to many problems, but i think that we should consider the possibility of just using standard filelevel security. That's something that has been audited and proven for years. 3) A very small utility that is setgid vpsql. It does the following when passed a username and password to verify. You will also need small tools to do all other sorts of operations, quota, valias and so on. I did mention those at the end. And even said that I preferred several small tools to one large one that use switches to decide what it did because that would mean more code and a harder time auditing it. It's a great idea to have several small tools to do tasks, my point was just that it's not enough to return 0 or 1 (or 57). It's not as simple as that, think about APOP authentication... I don't have need of APOP so I didn't think about it. I was trying to establish the general principle for doing it setgid with minimal risks. I think something (well, several somethings) along those lines would be feasible without opening up vulnerabilities. None of us like set-id and try to avoid it, but there are times when it is better than the alternatives (if sufficient care is taken). Compared to the major hunk of setuid code that is sendmail and which a lot of systems run, this ought to be far less likely to be exploited. It's not the only solution and it may turn out not to be the best solution, but at least it's there for consideration (and possible improvement). It may turn out to be the best solution - but i see lots of problems with this solution. Mainly the passing of arguments to/from these tools. If it were just TRUE/FALSE-returns i would be all for it - well, almost ;-). /Anders
Re: [vchkpw] Re: Tom's fork of vpopmail (and qmailadmin)
Hi, On Wed, 2003-09-10 at 16:09, Benjamin Tomhave, CISSP wrote: First off, everybody needs to quit whining. Seriously, if Tom hadn't [snip] Just my sniping comment... I am so very sorry for being a whining sleeping idiot! I will say thanks to Tom, stop being a sysadmin and go back to kindergarten right away! Sorry - it was so tempting ;-) /Anders
Re: [vchkpw] Re: Tom's fork of vpopmail (and qmailadmin)
Hi, On Tue, 2003-09-09 at 19:30, Tom Collins wrote: I have forked ownership since I felt that Inter7 was doing a poor job of maintaining vpopmail and qmailadmin. I readily acknowledge that Ken created vpopmail and qmailadmin. They're GPL projects, so I'm free to fork them if I like. Since moving the projects to SourceForge, we've kept up with submitted patches and bug reports. I feel that making the move was beneficial to the projects themselves and the people that use them. Fine, fine. But! Could we please change the name then? It will be a support nightmare if we got two forks named the same. vpopmail-sf - anything please! [snip] since then. Managing the projects on SourceForge keeps everything out in the open, and allows anyone to contribute. Please, can we have CVS access then? Or maybe just patches for every release? It's a pain to keep a personal tree updated with new releases. Ken hasn't stated why he wants to be an owner of the project. I'm not sure I understand what he loses out on by being a developer on the project and not an admin. Prestige? - And maybe the fact that he created the thing in the first place. Counterquestion: Why do you refuse to add him? /Anders
Re: [vchkpw] Re: Tom's fork of vpopmail (and qmailadmin)
Hi, On Tue, 2003-09-09 at 19:51, Rick Romero wrote: Ken Jones hasn't contributed to vpopmail and qmailadmin development since March. We've had 12 qmailadmin releases and 7 vpopmail releases since then. Managing the projects on SourceForge keeps everything out in the open, and allows anyone to contribute. IMHO, I think Ken can bring a little more stability to the devel releases. Yes, we KNOW it's a development release, but some of the Changelog entries show a lack of, umm, a polished release. Agree. Let me say it this way, I've stopped using development releases in any production-environment (Yep, I know - but we have to, and everybody does it!). Now, while I didn't have a problem merging my hacks into the latest inter7 devel version, I have yet to grab a sourceforge version simply BECAUSE there are so many releases. Agree! Slow down, take a deep breath, give cvs-acces to those who can't wait or are doing active development. The occasional bugfixer or 3-line patcher doesn't need _bleeding_ edge code. /Anders
[vchkpw] Old releases, was: Re: [vchkpw] Inter7, vpopmail, and open source standards
Hey, On Wed, 2003-09-10 at 01:26, Oden Eriksson wrote: If you want to check in old stuff for historical reasons or whatever, I think I have at least 80% of all the releases at my site, it's at: http://www.deserve-it.com/sw/src/ Thanks man! You're a lifesaver! I just used almost an two hours googling for old vpop-releases... And then i see this post, as i was ready to give up :) And you got the release i needed! Cool! /Anders
Re: [vchkpw] Re: Change the default quota
Hi, On Thu, 2003-03-20 at 10:49, Jonas Pasche wrote: but is it OK to do 'make install' ? i already have a virtual domain, and many account Yes. It only installs the binaries and doesn't change your virtual host configuration. I have to wonder, will make install do a recursive chown and chgrp? If so, it would be a bad idea to use 'make install' if you use system quotas. -- Anders Brander - http://anders.brander.dk/
Re: [vchkpw] accept selected mails
Hi, On Sun, 2003-03-16 at 16:56, Jonas Pasche wrote: From the qmail-command man page: EXIT CODES command's exit codes are interpreted as follows: 0 means that the delivery was successful; 99 means that the deliv ery was successful, but that qmail-local should ignore all further delivery instructions; [...] - and there's more, i often use these defines in my dotqmail-code: /* exit codes */ #define EXIT_ACCEPT 0 #define EXIT_DROP 99 #define EXIT_BOUNCE 100 #define EXIT_TEMPERROR 111 -- Anders Brander [EMAIL PROTECTED]
Re: [vchkpw] Forwarding....
Hi, On Sun, 2003-03-16 at 17:03, Jonas Pasche wrote: Forwardings are handled by qmail-local before vpopmail drops in. They're well documented by Life with qmail: Not entirely correct, .qmail files is read by vdelivermail if they are placed inside users own directory. Please look at the check_forward_deliver() function in vdelivermail.c In other words, .qmail files in the domain directory is handled by qmail-local, while .qmail files in user-directories is handled by vdelivermail. -- Anders Brander [EMAIL PROTECTED]
Re: [vchkpw] Feature request: Usage of SSLREMOTEIP
Hi, On Monday 03 March 2003 00:44, Jonas Pasche wrote: Does anyone know a workaround until either vpopmail reads SSLREMOTEIP or ucspi-ssl sets TCPREMOTEIP? How about something like (untested): (env TCPREMOTEIP=$SSLREMOTEIP /home/vpopmail/bin/vchkpw) in your startup script instead of just /home/vpopmail/bin/vchkpw ? -- Anders Brander - http://anders.brander.dk/
Re: [vchkpw] starting vpop gives error
Hi, On Thu, 2003-02-27 at 20:47, Rob G wrote: Do a netstat -na | grep LISTEN and see if anything else is listening on port 110 as that is what is holding the address open. Try a netstat -lnp | grep 110 instead. It will also show the pid of the listening program. -- Anders Brander - http://anders.brander.dk/
Re: [vchkpw] vpopmail as a daemon
Hi, On Sunday 23 February 2003 19:03, Jesse Guardiani wrote: What does everyone think about the possibility of turning vpopmail into a daemon? Complete with network ports and the like. It would allow for a much more distributed architecture, IMHO. How about: ssh -l vpopmail your.mailserver.com ~/bin/vadddomain foobar.com password and so on? Wouldn't that help? /Anders
Re: [vchkpw] Email encryption
Hi, On Wednesday 11 December 2002 22:16, Remo Mattei wrote: Hi guys does any of you have an howto on how to have email drop in the user mailbox encrypted? So if send to a particolar address it's going to be automatically encrypted. I have often been thinking about this myself. We must face one thing, as long as the mail is travelling unencrypted, somebody can read it. The root-user of the local mailserver can always read it! I see two scenarios. 1. Client side software is helping. Pros: One can use existing PGP encryption with fairly good client support. PGP's prone public key system would make it quite secure too. Cons: It requires client side support (PGP software). 2. Invisible to client side. Could be implemented using some sort of public-key crypto, where the private part was the pop3/imap password. Pros: It doesn't require any client side support. Will stop the occasional cracker. Cons: Too unsecure to be used. Root will have access after the mail is encrypted! (think about it!) Just a few thoughts... (btw: I ended up using tcpserver with ssl support) /Anders
Re: [vchkpw] Email encryption
Hi, On Wednesday 11 December 2002 23:21, W.D.McKinney wrote: Just a few thoughts... (btw: I ended up using tcpserver with ssl support) How did you do this if may ask ? How i got tcpserver ssl-enabled? Here's a patch: http://www.nrg4u.com/qmail/ucspi-tcp-ssl-20020705.patch.gz - did that help? /Anders
Re: [vchkpw] pop3s - vpopmail using stunnel on port 995
Hi, On Thursday 14 November 2002 01:35, martin wrote: A link would do or a response from someone using vpopmail that has this successfully working. How about using tcpserver-ssl? It works like a charm (AFAIK) :) http://www.nrg4u.com/qmail/ucspi-tcp-ssl-20020705.patch.gz And as Rick noted, there is issues with Eudora, however, i made a small fix: http://fmail.dk/stuff/tcpserver-ssl-eudora1.patch Just my 2c. /Anders
Re: [vchkpw] incorrect work of vdelivermail
Hi, I think Peter answers were good for #2-4, but I would like to comment on #1. On Tuesday 12 November 2002 14:11, JUST a Tester wrote: PROBLEM #1. dot-qmail-default with contents like | /var/vpopmail/bin/vdelivermail '' [EMAIL PROTECTED] produce unnecessarily Delivered-To: [EMAIL PROTECTED] instead of just Delivered-To: [EMAIL PROTECTED] This line _is_ necessarily. Imagine two .qmail files pointing to each other in that fashion - it would be impossible to catch looping mail without the dt-lines. /Anders
Re: [vchkpw] To bounce or not to bounce...
Hi, On Tuesday 05 November 2002 09:22, [EMAIL PROTECTED] wrote: Is there any way to say in the domain/user/.qmail-file that If something, then bouche, else deliver the mail to the Maildir? Yep, return 100 (and some bounce text) for bounce - 0 for delivery. I got a program running first when mail arrives, and returns 100 if mail should not be delivered and prossessing the .qmail-file stoppes. This if fair enought, but I want the mail to bounce back to sender if it was not delivered. Is this running from .qmail-default or another .qmail-*? If it's another file this can be an explanation. Are you using vpopmail 5.3.10? There's a small bug in vdelivermail, It fails to catch return code 100, instead treating it as 111 (temp error) I made a patch against 5.3.9, don't know how well it applies to other versions, but it's a oneliner, should be easy to fix by hand :) http://fmail.dk/stuff/vdeliver-command-return-100.diff Hope this helps... /Anders
Re: [vchkpw] To bounce or not to bounce...
Hi, On Tuesday 05 November 2002 09:53, [EMAIL PROTECTED] wrote: It's running from the file /home/vpopmail/domain/user/.qmail (In the domain/.qmail-default it's okey, but it has to be user-spesific..) If it's okay in the default-file, then it's the problem with vdelivermail i was referring to. See vdelivermail.c line 713. Yep, return 100 (and some bounce text) for bounce - 0 for delivery. And how exactly would I put the bounce-text? Print to file descriptor 0. Are you using vpopmail 5.3.10? There's a small bug in vdelivermail, It fails to catch return code 100, instead treating it as 111 (temp error) I made a patch against 5.3.9, don't know how well it applies to other versions, but it's a oneliner, should be easy to fix by hand :) http://fmail.dk/stuff/vdeliver-command-return-100.diff Actually I've just upgraded to 5.2.1 to make the user-qmail-thing work. As I understood this is the latest stable version, and as a mailserver it has to be stable. I made a patch for 5.2.1 just for you :) http://fmail.dk/stuff/vpopmail-5.2.1-vdeliver-command-100.diff Does this help? /Anders
Re: [vchkpw] temporarily disable delivery retrieval for a domain
Hi, On Thursday 24 October 2002 22:29, you wrote: [snip] 1) if there is a comparable way to defer delivery for a virtual domain, similar to setting the sticky bit on a home directory How about a .qmail-default like this?: |exit 111 - That would make the mail-delivery fail temporarily (afaik), and qmail would try again later. /Anders
Re: [vchkpw] temporarily disable delivery retrieval for a domain
Hi, On Friday 25 October 2002 01:14, you wrote: Said Anders Brander on Fri, Oct 25, 2002 at 12:38:21AM +0200: How about a .qmail-default like this?: |exit 111 - That would make the mail-delivery fail temporarily (afaik), and qmail would try again later. Thanks for the tip, but I think that would only work on mail to the default, or catch-all, and not all other users. The sticky-bit idea is better, but this would work. Try it :) /Anders
[vchkpw] vdelivermail fails when alias line starting with | and containing /Maildir/
Hi, I think i've encountered a bug, vdelivermail seems to process the line: |/do/deliver/to /home/vpopmail/domains/example.com/test1/Maildir/ wrongly. It deals with it like it's a /Maildir/-line, which is wrong. It seems like vdelivermail checks for /Maildir/ anywhere in the line, before it checks for a | at the start of the line. I've made a quick fix to vdelivermail.c. http://fmail.dk/stuff/vdeliver-command.diff Please test and comment. /Anders
[vchkpw] return code 100 and vdelivermail
Hi, Is there any reason that vdelivermail doesn't catch return code 100 when running |-commands? Please see vdelivermail.c line 764-770. It deals with 100 as it were 111. Is this right? For the curious: http://fmail.dk/stuff/vdeliver-command-return-100.diff :) /Anders
