Re: [vchkpw] vpopmail sans qmail.
On 2006-12-30, at 1938, Christopher Chan wrote: When a scripter manages to stuff your queues with over 500k messages of rubbish, the last thing you want to do is to let any of it out let alone wait for it to disappear. The queues need to be cleared right away before you get even more bogged down. i'm thinking of writing a patch for qmail-send, where if the timestamp on a mess file is older than DOUBLE the value of control/ queuelifetime, it would delete the message BEFORE attempting one last delivery... i think this would be a huge help in cleaning up cases like this without having to shut down qmail-send. i know, more patches... i didn't realize that postfix didn't have support for virtual domains. this would be a show-stopper for me installing it on my own server, or on a client's server. postfix has its own virtual mail backend...but you had to build the tables and management scripts/tools yourself. Its virtual mail backend provides the structure but you had to fill it in. ah... so it's basically like what qmail is without vpopmail. it all makes sense now... why not just write something similar to vpopmail, but which works using whatever low-level mechanism postfix provides to handle virtual mailboxes? or if there is no such support, add it in? :D. I am sure someone must have built something like that...it is only probably not as well known as vpopmail. it may not be as well known as vpopmail, but google knows about it and that's all that really counts. i did a search for postfix virtual domain management interface and came up with this site, which sounds like vpopmail and qmailadmin rolled into one: http://www.postfixvirtual.net/ and i think this thread has pretty much played itself out in terms of being relevant to vpopmail, so i'm going to end here (although if anybody else is interested in seeing how this turns out, speak up and let us know you care.) either way, i am interested in whether you try this or not, and if so, what kind of results you have with it. if the thread dies, please let me know via direct email. take care. | John M. Simpson--- KG4ZOW ---Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | | http://video.google.com/videoplay?docid=-4312730277175242198 | PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] vpopmail sans qmail.
... You apparently do the way it was formerly done too at the outfit; generate cdb and then scp the cdb file across to relevant boxes. What did you do to ensure that it is an atomic operation on the push/copy out to mailhub? the mailbox server sends the file using a command line this: cat file | ssh -I id_dsa_blah [EMAIL PROTECTED] filename the SSH key is in the authorized_keys file on the mailhub, with a forced command which uses the original command as a filename... it makes sure the filename is one of a small number it recognizes, and then runs a specific handler for each file. for validrcptto.cdb it does this: case validrcptto.cdb ) cat validrcptto.new chmod 644 validrcptto.new mv validrcptto.new validrcptto.cdb ;; and /var/qmail/control/validrcptto.cdb is a symlink to the file in this non-root user's home directory. other files which need to be atomically updated work the same way. Interesting. Thank you. for my needs and my clients' needs, my patches are the best solution. they may not be for everybody, which is why i'll explain the differences between validrcptto.cdb and chkusr, but i don't claim either one to be better than the other. different people have different needs. Yes, so long as you do not need the 'instant' creation of accounts or what not, your system will do fine for those who have a controlled generation of the cdb files. i've never had anybody get upset over a ten-second delay (which is actually why i wrote the onchange patch, to kick off this whole distribution process... the delay was previously up to one minute, and even that i never heard any complaints about.) If only we could build a cdb file in ten seconds...we have too many records do to it in that space of time. For your traffic patterns, cdb will probably do. The outfit I worked for handled on a daily average, 200 million SMTP connections or over 8 million connections hourly. It was not acceptable to spend minutes pushing the cdb file across for the mailhubs and probably still is. (Please don't give me the get proper hardware. If I could have gotten more servers or replacements that had better disk i/o...) actually, once the process started, the new cdb files were active on the mailhubs in under five seconds. i'm not running a system the size of gmail, and i doubt anybody else on this list is either. :D I am sure that the outfit would be very pleased to be compared to Gmail. ROTFL. I have done sendmail, postfix and qmail. qmail is the best in that it is simple and elegant. I had colleagues who would not touch qmail with a ten foot pole. They did not care to delve into the internals of qmail and qmail is a pain if you have to go in the clear out spam. sendmail and postfix are much better in the queue management area. after i wrote the validrcptto.cdb patch and stopped accepting messages for non-existent mailboxes to start with, it's rare for my queue to have more than five messages in it. i saw the same results with my clients' servers, when i upgraded them to use the validrcptto.cdb feature. This is fine for low trafic sites. When I was still working for that outfit, the problem was to keep the spam away from existing mailboxes and preferably not even allowing it into the queues. Stopping qmail-send to scrounge out spam and then making sure you delete the stuff properly and do not end up with a corrupt queue is not their cup of tea since it is something they have to do regularly (yes...partly free webmail provider). if they can identify the messages they don't want (using grep or whatever) then instead of DELETING them, they can simply touch the mess/*/___ files with an old timestamp (i use 1998-01-01 00:00:00 for this) and then kick the queue by sending an ALRM signal to qmail-send. what happens is that qmail-send will try each message exactly one more time, and then delete it through the normal timeout mechanism. which means that, for individual spam-deletion cases, qmail-queue never needs to be stopped at all. the only time i ever stop a queue is if the filesystem has filled up and caused real corruption. When a scripter manages to stuff your queues with over 500k messages of rubbish, the last thing you want to do is to let any of it out let alone wait for it to disappear. The queues need to be cleared right away before you get even more bogged down. Don't give tell me about qmHandle. That script is broken and will leave you with corrupt bounce messages under certain conditions besides being awfully slow. i've never used qmhandle. i wrote my own qfixq script years ago, and tested the living daylights out of it. and since releasing it, whenever somebody reports a problem with it, i fix it and release a new version immediately. the version on my web site has been free of any reported bugs since 2005-08-30, and the only change since then was to add an empty option to
Re: [vchkpw] vpopmail sans qmail.
On 2006-12-25, at , Christopher Chan wrote: ... So it appears to me that your comment (whose connection pool might become overloaded) indicates you have no idea what I meant by 'connection pooling'. This is software on the mailhub side, not the mysql server side, that addresses mysql's poor connection handling performance. you are correct, i wasn't aware of any way to do this on the client side. this reminds me of the IMAP connection pooling program that some people use with courier-imap. ... You apparently do the way it was formerly done too at the outfit; generate cdb and then scp the cdb file across to relevant boxes. What did you do to ensure that it is an atomic operation on the push/copy out to mailhub? the mailbox server sends the file using a command line this: cat file | ssh -I id_dsa_blah [EMAIL PROTECTED] filename the SSH key is in the authorized_keys file on the mailhub, with a forced command which uses the original command as a filename... it makes sure the filename is one of a small number it recognizes, and then runs a specific handler for each file. for validrcptto.cdb it does this: case validrcptto.cdb ) cat validrcptto.new chmod 644 validrcptto.new mv validrcptto.new validrcptto.cdb ;; and /var/qmail/control/validrcptto.cdb is a symlink to the file in this non-root user's home directory. other files which need to be atomically updated work the same way. for my needs and my clients' needs, my patches are the best solution. they may not be for everybody, which is why i'll explain the differences between validrcptto.cdb and chkusr, but i don't claim either one to be better than the other. different people have different needs. Yes, so long as you do not need the 'instant' creation of accounts or what not, your system will do fine for those who have a controlled generation of the cdb files. i've never had anybody get upset over a ten-second delay (which is actually why i wrote the onchange patch, to kick off this whole distribution process... the delay was previously up to one minute, and even that i never heard any complaints about.) For your traffic patterns, cdb will probably do. The outfit I worked for handled on a daily average, 200 million SMTP connections or over 8 million connections hourly. It was not acceptable to spend minutes pushing the cdb file across for the mailhubs and probably still is. (Please don't give me the get proper hardware. If I could have gotten more servers or replacements that had better disk i/o...) actually, once the process started, the new cdb files were active on the mailhubs in under five seconds. i'm not running a system the size of gmail, and i doubt anybody else on this list is either. ROTFL. I have done sendmail, postfix and qmail. qmail is the best in that it is simple and elegant. I had colleagues who would not touch qmail with a ten foot pole. They did not care to delve into the internals of qmail and qmail is a pain if you have to go in the clear out spam. sendmail and postfix are much better in the queue management area. after i wrote the validrcptto.cdb patch and stopped accepting messages for non-existent mailboxes to start with, it's rare for my queue to have more than five messages in it. i saw the same results with my clients' servers, when i upgraded them to use the validrcptto.cdb feature. Stopping qmail-send to scrounge out spam and then making sure you delete the stuff properly and do not end up with a corrupt queue is not their cup of tea since it is something they have to do regularly (yes...partly free webmail provider). if they can identify the messages they don't want (using grep or whatever) then instead of DELETING them, they can simply touch the mess/*/___ files with an old timestamp (i use 1998-01-01 00:00:00 for this) and then kick the queue by sending an ALRM signal to qmail-send. what happens is that qmail-send will try each message exactly one more time, and then delete it through the normal timeout mechanism. which means that, for individual spam-deletion cases, qmail-queue never needs to be stopped at all. the only time i ever stop a queue is if the filesystem has filled up and caused real corruption. Don't give tell me about qmHandle. That script is broken and will leave you with corrupt bounce messages under certain conditions besides being awfully slow. i've never used qmhandle. i wrote my own qfixq script years ago, and tested the living daylights out of it. and since releasing it, whenever somebody reports a problem with it, i fix it and release a new version immediately. the version on my web site has been free of any reported bugs since 2005-08-30, and the only change since then was to add an empty option to just plain delete everything in the queue, and to add a check to
Re: [vchkpw] vpopmail sans qmail.
John Simpson wrote: On 2006-12-22, at 1006, Christopher Chan wrote: John Simpson wrote: http://qmail.jms1.net/patches/validrcptto.cdb.shtml There is a better patch for vpopmail support in qmail. A mysql patch that goes straight the vpopmail mysql database but I am not sure of its location. The writer even rebuffed one of Inter7's developers when someone floated the idea of qmail supporting vpopmail's mysql tables and the developer said he would write it since he was not aware of the patch's existence. So I believe the Inter7 guy drop it right then and there or maybe not. I believe it is this one here and the writer was Italian: http://www.interazioni.it/opensource/chkusr/ that's all well and good, IF your incoming mail always arrives on the same machine where vpopmail is running, IF you don't mind re-compiling qmail everytime vpopmail is upgraded, and IF you keep your user information in a mysql database. If it ain't broke...I don't see why people would want to upgrade vpopmail unless there is a security fix or a feature that they need. Realistically, it cannot be as bad as you make it. most ISPs handle a large enough volume of email that they have several internet-facing servers which handle the flood of incoming mail, and forward the legitimate messages to an internal machine which contains the mailboxes. the one mailbox machine will be running vpopmail, but the other internet-facing servers (i call them mailhubs) are generally not running vpopmail, which means they are not able to check recipients or process AUTH commands against the vpopmail information. i've seen people get around this using mysql, both by having the mailhubs connect across the network to a database server, and by setting up mysql servers on the mailhubs and replicating the data. but what if the company isn't using mysql in the first place? (i spent eight years building and running ISPs with this exact scenario- multiple mailhubs, no mysql. yes, we had a customer database- but that was for billing, and it wasn't directly involved with the mechanics of the systems themselves.) my validrcptto.cdb and auth.cdb patches get around these problems by storing the list of valid recipient addresses and the list of valid userid/password pairs in cdb files, and just copying those files from the mailbox server out to the mailhubs whenever they change. PLUS, the fact that they're cdb files means that the lookups happen without the added overhead of having to open a connection to a mysql server (whose connection pool might become overloaded in case of a spam flood.) I will pit my four years in my previous job as a MTA admin in a SME email service provider that handles in total over 40 million mailboxes against your eight years running and building ISPs. The same two stage delivery system is used too. I have dealt with both types of environments. An older system built cdb files for deployment to the frontline mailhubs. The newer systems had mysql servers for the frontline mailhubs. I get the impression you have not seen mysql connection pooling in acton. When I joined, they used sendmail frontline hubs patched to support mysql databases with cdb support being later added by me for the older system. The sendmail patch had no connection pooling support and so it would open a new mysql connection to the mysql server and yes, this meant that the mysql server would become overloaded in the case of a spam flood. There was, for example, one set of 5 frontline servers handling up to 600 connections each using one mysql server and another set of 4 frontline servers also doing 600 connections using another mysql server. I did a trial with postfix with its mysql and mysql connection pooling support because I got tired of manually taking care of the queues due to the mysql servers being overloaded and due to the many security holes that were being discovered in sendmail 8.12.x. postfix replaced sendmail very soon after the first trial run. mysql connection pooling makes a huge difference. Those two mysql servers under the sendmail system would be pushed till they had only 10% cpu idle resources being reported and they were still not delivering because mysql just cannot handle a large number of connections that are being set up and torn down at the same time. With the postfix system using postfix's builtin connection pooling support, just ONE mysql server is enough to the mysql query load for all eleven boxes at full load (all connections available taken and a tcp syn queue backlog of over 1024 per box) without breaking a sweat. Lowest cpu idle registered on the mysql server is 80%. Connection pooling is king. The bottleneck now is not the mysql server but the mailhubs themselves. So it appears to me that your comment (whose connection pool might become overloaded) indicates you have no idea what I meant by 'connection pooling'. This is software on the mailhub side, not the
Re: [vchkpw] vpopmail sans qmail.
On 2006-12-22, at 1006, Christopher Chan wrote: John Simpson wrote: http://qmail.jms1.net/patches/validrcptto.cdb.shtml There is a better patch for vpopmail support in qmail. A mysql patch that goes straight the vpopmail mysql database but I am not sure of its location. The writer even rebuffed one of Inter7's developers when someone floated the idea of qmail supporting vpopmail's mysql tables and the developer said he would write it since he was not aware of the patch's existence. So I believe the Inter7 guy drop it right then and there or maybe not. I believe it is this one here and the writer was Italian: http:// www.interazioni.it/opensource/chkusr/ that's all well and good, IF your incoming mail always arrives on the same machine where vpopmail is running, IF you don't mind re- compiling qmail everytime vpopmail is upgraded, and IF you keep your user information in a mysql database. most ISPs handle a large enough volume of email that they have several internet-facing servers which handle the flood of incoming mail, and forward the legitimate messages to an internal machine which contains the mailboxes. the one mailbox machine will be running vpopmail, but the other internet-facing servers (i call them mailhubs) are generally not running vpopmail, which means they are not able to check recipients or process AUTH commands against the vpopmail information. i've seen people get around this using mysql, both by having the mailhubs connect across the network to a database server, and by setting up mysql servers on the mailhubs and replicating the data. but what if the company isn't using mysql in the first place? (i spent eight years building and running ISPs with this exact scenario- multiple mailhubs, no mysql. yes, we had a customer database- but that was for billing, and it wasn't directly involved with the mechanics of the systems themselves.) my validrcptto.cdb and auth.cdb patches get around these problems by storing the list of valid recipient addresses and the list of valid userid/password pairs in cdb files, and just copying those files from the mailbox server out to the mailhubs whenever they change. PLUS, the fact that they're cdb files means that the lookups happen without the added overhead of having to open a connection to a mysql server (whose connection pool might become overloaded in case of a spam flood.) the down side is that you have to write some scripts to generate the validrcptto.cdb and auth.cdb files in the first place, and copy them out to the mailhubs. however, my web site also has working mkvalidrcptto and mkauth scripts, along with a web page which explains how to use ssh to push the files out to your mailhubs... so while it may not be brain dead easy, it's certainly not as difficult as setting up and maintaining replication between mysql servers. for my needs and my clients' needs, my patches are the best solution. they may not be for everybody, which is why i'll explain the differences between validrcptto.cdb and chkusr, but i don't claim either one to be better than the other. different people have different needs. postfix trumps chkusr/chkuser just as chkusr/chkuser trumps the cdb check. everybody has their own opinions... mine happen to be the exact opposite of what you've written here. First, chkusr vs rcptto.cdb. tcpserver + qmail-smtpd means a fresh fork for each new connection. The cdb rcptto means a disk access for each rcpt to check and regular rebuilds of the cdb database. chkusr/chkuser helps by keeping I/O of disk (okay we can contest whether looking up cdbs is better than looking up mysql tables or not but I think it is fair game to say that mysql lookups are more likely to be disk I/O free) and by not needing regular rebuilds of a cdb file. In fact, it offers instant/real-time user existence checks. until you build in the overhead of mysql replication (or even worse, qmail-smtpd connecting to a mysql server across the network.) open() takes less CPU and less time than mysql_connect(), even if the mysql server is on the same machine (because open() only involves qmail-smtpd and the kernel, while mysql_connect() also involves mysqld, which may already be busy with other clients, witness the complains about this very issue on the courier-imap list.) and in the case of a file like validrcptto.cdb, which would be used constantly on a busy server, the file's data blocks would be in the kernel's disk cache 99% of the time, so there is almost never any wait for a disk to rotate- any disk reads are satisfied from the kernel's disk cache. if anything, i think the chances of a single file already being cached in the kernel's disk cache are higher than the chances of a mysql server having the right rows from the right table in memory, plus be idle at the right time and be able to answer qmail-smtpd's queries
Re: [vchkpw] vpopmail sans qmail.
On 2006-12-18, at 0444, Christopher Chan wrote: Darrel O'Pry wrote: I'm currently considering replacing qmail in my mail systems. I was wondering if anyone had tried vpopmail with postfix or exim and what their experiences were. Yeah, I use vpopmail with postfix. Love it. postfix user existence checks mean I don't have large queues. funny, i've been doing the same thing using qmail (making sure recipient email addresses exist before accepting a RCPT command in the SMTP conversation) for over a year now. http://qmail.jms1.net/patches/validrcptto.cdb.shtml -- | John M. Simpson - KG4ZOW - Programmer At Large | | http://www.jms1.net/ [EMAIL PROTECTED] | -- | Mac OS X proves that it's easier to make UNIX | | pretty than it is to make Windows secure. | -- PGP.sig Description: This is a digitally signed message part
Re: [vchkpw] vpopmail sans qmail.
John Simpson wrote: On 2006-12-18, at 0444, Christopher Chan wrote: Darrel O'Pry wrote: I'm currently considering replacing qmail in my mail systems. I was wondering if anyone had tried vpopmail with postfix or exim and what their experiences were. Yeah, I use vpopmail with postfix. Love it. postfix user existence checks mean I don't have large queues. funny, i've been doing the same thing using qmail (making sure recipient email addresses exist before accepting a RCPT command in the SMTP conversation) for over a year now. Yes. with a patch. I know patches exist. I have nothing against qmail. I will recommend qmail where it is most suitable...as the mta for outgoing mails for a mailing list or as the second stage in the inbound system due to dot-qmail which is a delivery system that is second to none. http://qmail.jms1.net/patches/validrcptto.cdb.shtml There is a better patch for vpopmail support in qmail. A mysql patch that goes straight the vpopmail mysql database but I am not sure of its location. The writer even rebuffed one of Inter7's developers when someone floated the idea of qmail supporting vpopmail's mysql tables and the developer said he would write it since he was not aware of the patch's existence. So I believe the Inter7 guy drop it right then and there or maybe not. I believe it is this one here and the writer was Italian: http://www.interazioni.it/opensource/chkusr/ postfix trumps chkusr/chkuser just as chkusr/chkuser trumps the cdb check. First, chkusr vs rcptto.cdb. tcpserver + qmail-smtpd means a fresh fork for each new connection. The cdb rcptto means a disk access for each rcpt to check and regular rebuilds of the cdb database. chkusr/chkuser helps by keeping I/O of disk (okay we can contest whether looking up cdbs is better than looking up mysql tables or not but I think it is fair game to say that mysql lookups are more likely to be disk I/O free) and by not needing regular rebuilds of a cdb file. In fact, it offers instant/real-time user existence checks. postfix improves on this by 1) no new fork for each connection (except perhaps initially if handling hundreds or thousands of connections right after startup of postfix) and 2) by using mysql connection pooling which means you don't hammer the mysql server into the ground with the constant setting up and breaking down of connections. This is without including all the great anti-spam features that postfix provides too. IM2000 does not appear to be happening, DJB apparently will not make any more improvements to qmail to deal with today's Internet and I do not fancy mixing a bunch of patches to get similar functionality on tcpserver's less efficient architecture (one fork per new connection). One of these days I am going to try to make dot-qmail/qmail-users support for postfix and see how much more fanatic some qmail guys are about qmail than I was. I can boast the ability to install qmail without even looking at the documentation and the ability to split a qmail queue's directory structure across different disks to get better delivery performance besides using the multiple qmail queue method. And having qmail patched and tuned to be able to push over a thousand qmail-remotes while under constant injections via qmail-smtpd and qmail-qmtpd non-stop. I probably know/understand qmail better than you do. So if you are running a site with low traffic, by all means, continue using your patched qmail that requires you to stop the queue (and sometimes even the tcpserver for qmail-smtpd) before you can do any clean up of the queue and that might get you blocked for being 'abusive' because it opened up 120 connections to the same mx for whatever reason you got that composition of emails in the queue. I, for my part, cannot recommend qmail except for cases where it does not need an uber number of patches to be acceptable and does not require queue clean up and its delivery behaviour is tolerable. Sigh. But I am more inclined to teach others how to use qmail since it is so SIMPLE. When will spammers disappear?
Re: [vchkpw] vpopmail sans qmail.
Christopher Chan wrote: http://qmail.jms1.net/patches/validrcptto.cdb.shtml There is a better patch for vpopmail support in qmail. A mysql patch that goes straight the vpopmail mysql database but I am not sure of its location. The writer even rebuffed one of Inter7's developers when someone floated the idea of qmail supporting vpopmail's mysql tables and the developer said he would write it since he was not aware of the patch's existence. So I believe the Inter7 guy drop it right then and there or maybe not. I believe it is this one here and the writer was Italian: http://www.interazioni.it/opensource/chkusr/ postfix trumps chkusr/chkuser just as chkusr/chkuser trumps the cdb check. First, chkusr vs rcptto.cdb. tcpserver + qmail-smtpd means a fresh fork for each new connection. The cdb rcptto means a disk access for each rcpt to check and regular rebuilds of the cdb database. chkusr/chkuser helps by keeping I/O of disk (okay we can contest whether looking up cdbs is better than looking up mysql tables or not but I think it is fair game to say that mysql lookups are more likely to be disk I/O free) and by not needing regular rebuilds of a cdb file. In fact, it offers instant/real-time user existence checks. In addition, I believe Matt Simerson authored a tcpserver mysql patch to allow the removal of cdb files altogether. http://www.tnpi.biz - it's great for heavily loaded servers, because constantly recompiling that damn file with multiple processes tends to corrupt it. I love qmail too, but I'm with ya on all the 'unapproved' patches and it's concurrency limitations. Rick
Re: [vchkpw] vpopmail sans qmail.
In addition, I believe Matt Simerson authored a tcpserver mysql patch to allow the removal of cdb files altogether. http://www.tnpi.biz - it's great for heavily loaded servers, because constantly recompiling that damn file with multiple processes tends to corrupt it. Eh? Rebuilding it while multiple processes are accessing it corrupts it?!? Or multiple processes trying to rebuild the same file? I love qmail too, but I'm with ya on all the 'unapproved' patches and it's concurrency limitations. The mysql side of things could be alleviated by using sqlrelay. Don't hammer mysql. Hammer sqlrelay instead :) Christopher
Re: [vchkpw] vpopmail sans qmail.
Christopher Chan wrote: In addition, I believe Matt Simerson authored a tcpserver mysql patch to allow the removal of cdb files altogether. http://www.tnpi.biz - it's great for heavily loaded servers, because constantly recompiling that damn file with multiple processes tends to corrupt it. Eh? Rebuilding it while multiple processes are accessing it corrupts it?!? Or multiple processes trying to rebuild the same file? I believe it's multiple processes trying to rebuild the same file. I've had a corrupted cdb for a long time - from courier POP auths. I've never fixed it because I also have the mysql patches, and SMTP Auth in place. Everything works, so I'm not touching it until I completely rebuild that system :) I love qmail too, but I'm with ya on all the 'unapproved' patches and it's concurrency limitations. The mysql side of things could be alleviated by using sqlrelay. Don't hammer mysql. Hammer sqlrelay instead :) Oh EXCELLENT tip. I thought replicating the database to each server was the best solution, sqlrelay looks like it'll make things even better. Thanks Christopher
Re: [vchkpw] vpopmail sans qmail.
Rick Romero wrote: Christopher Chan wrote: In addition, I believe Matt Simerson authored a tcpserver mysql patch to allow the removal of cdb files altogether. http://www.tnpi.biz - it's great for heavily loaded servers, because constantly recompiling that damn file with multiple processes tends to corrupt it. Eh? Rebuilding it while multiple processes are accessing it corrupts it?!? Or multiple processes trying to rebuild the same file? I believe it's multiple processes trying to rebuild the same file. I've had a corrupted cdb for a long time - from courier POP auths. I've never fixed it because I also have the mysql patches, and SMTP Auth in place. Everything works, so I'm not touching it until I completely rebuild that system :) Heh. I do the same with postfix. SMTP-AUTH against vpopmail tables is a no brainer. I love qmail too, but I'm with ya on all the 'unapproved' patches and it's concurrency limitations. The mysql side of things could be alleviated by using sqlrelay. Don't hammer mysql. Hammer sqlrelay instead :) Oh EXCELLENT tip. I thought replicating the database to each server was the best solution, sqlrelay looks like it'll make things even better. Thanks Christopher You are welcome Rick. I would still keep a slave or two around :). Don't let the sudden huge decrease in load make you do drastic reductions in mysql server instances :D.
Re: [vchkpw] vpopmail sans qmail.
Christopher Chan wrote: John Simpson wrote: On 2006-12-18, at 0444, Christopher Chan wrote: Darrel O'Pry wrote: I'm currently considering replacing qmail in my mail systems. I was wondering if anyone had tried vpopmail with postfix or exim and what their experiences were. Yeah, I use vpopmail with postfix. Love it. postfix user existence checks mean I don't have large queues. How? I have looked for this several times in the past few years and not seen it. Other than the postfix.txt on the inter7 website, but nothing substantial about how it is done, caveats, etc. funny, i've been doing the same thing using qmail (making sure recipient email addresses exist before accepting a RCPT command in the SMTP conversation) for over a year now. Yes. with a patch. I know patches exist. I have nothing against qmail. I will recommend qmail where it is most suitable...as the mta for outgoing mails for a mailing list or as the second stage in the inbound system due to dot-qmail which is a delivery system that is second to none. Uh oh, I feel it coming soapbox Patch smatch, if it's a patch everyone gets to beat qmail up and scream at each other about what a wasted never updated POS qmail is. So patches are bad bad bad. Only software that is poor and decrepit uses patches. But, let someone add that patch to the source code and bundle up a new package and suddenly every new user who posts a question is told You need the latest version. I have seen this many many times on many many maillists. We have not had to make a security update to our qmail installs in the 5 years we have been running them. All it took was running patch somediff a few times ONCE during the initial install. Lets be honest here, most minor version upgrades in OSS are the result of contributed patches (developer or user). Yet no one is claiming that vpopmail/postfix/perl/ruby/python is a patchy POS after we see the developers accepting patches from users and rolling out an upgrade. I propose that someone create a shell script that installs qmail and a set of user selected Modules chosen from a menu. Vpopmail could be a Module, chkuser could be a Module, bigip could be a Module. You could even rerun the script to add/subtract Modules, much like Apache Toolbox. Maybe then people would get over their aversion to patches in qmail. /soapbox Thank you, I feel better, you may return to your regularly scheduled list mail. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: [vchkpw] vpopmail sans qmail.
DAve wrote: soapbox Patch smatch, if it's a patch everyone gets to beat qmail up and scream at each other about what a wasted never updated POS qmail is. So patches are bad bad bad. Only software that is poor and decrepit uses patches. But, let someone add that patch to the source code and bundle up a new package and suddenly every new user who posts a question is told You need the latest version. I have seen this many many times on many many maillists. We have not had to make a security update to our qmail installs in the 5 years we have been running them. All it took was running patch somediff a few times ONCE during the initial install. Lets be honest here, most minor version upgrades in OSS are the result of contributed patches (developer or user). Yet no one is claiming that vpopmail/postfix/perl/ruby/python is a patchy POS after we see the developers accepting patches from users and rolling out an upgrade. I think it would be nice to feel like to owner/author of qmail was actually behind it. And to do that, he should be improving upon it - that is, accepting at least the patches that we all use. Obviously it's not a complete product, unless you can point me to a substantial 'stock qmail' userbase. Nobody can even provide binaries for the 'lessers' among us - so they will never use it. I propose that someone create a shell script that installs qmail and a set of user selected Modules chosen from a menu. Vpopmail could be a Module, chkuser could be a Module, bigip could be a Module. You could even rerun the script to add/subtract Modules, much like Apache Toolbox. Maybe then people would get over their aversion to patches in qmail. /soapbox Check out Matt Simerson's Mail::Toaster - I think the back end is even in CPAN now.. www.tnpi.biz. I've totally felt like a 'Matt schill' lately, but IMHO what he has done just rocks. Rick Thank you, I feel better, you may return to your regularly scheduled list mail. DAve
Re: [vchkpw] vpopmail sans qmail.
Rick Romero wrote: DAve wrote: soapbox Patch smatch, if it's a patch everyone gets to beat qmail up and scream at each other about what a wasted never updated POS qmail is. So patches are bad bad bad. Only software that is poor and decrepit uses patches. But, let someone add that patch to the source code and bundle up a new package and suddenly every new user who posts a question is told You need the latest version. I have seen this many many times on many many maillists. We have not had to make a security update to our qmail installs in the 5 years we have been running them. All it took was running patch somediff a few times ONCE during the initial install. Lets be honest here, most minor version upgrades in OSS are the result of contributed patches (developer or user). Yet no one is claiming that vpopmail/postfix/perl/ruby/python is a patchy POS after we see the developers accepting patches from users and rolling out an upgrade. I think it would be nice to feel like to owner/author of qmail was actually behind it. And to do that, he should be improving upon it - that is, accepting at least the patches that we all use. Obviously it's not a complete product, unless you can point me to a substantial 'stock qmail' userbase. Nobody can even provide binaries for the 'lessers' among us - so they will never use it. Point taken, but the constant qmail is patchy as an excuse to belittle the software and it's users is getting on my nerves of late. I have also found myself falling into the if you can't build an email server, you shouldn't be administering one camp, blame it on the fact that I deal weekly with mis-configured Exchange servers and Barracuda installs. I ranted 8^o I propose that someone create a shell script that installs qmail and a set of user selected Modules chosen from a menu. Vpopmail could be a Module, chkuser could be a Module, bigip could be a Module. You could even rerun the script to add/subtract Modules, much like Apache Toolbox. Maybe then people would get over their aversion to patches in qmail. /soapbox Check out Matt Simerson's Mail::Toaster - I think the back end is even in CPAN now.. www.tnpi.biz. I've totally felt like a 'Matt schill' lately, but IMHO what he has done just rocks. Never feel bad for giving good advice. We already have a standard install procedure we use, or we would likely be running Matt's Toaster as well. I have never heard anything bad about it. DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: [vchkpw] vpopmail sans qmail.
On Mon, 2006-12-18 at 17:44 +0800, Christopher Chan wrote: Darrel O'Pry wrote: I'm currently considering replacing qmail in my mail systems. I was wondering if anyone had tried vpopmail with postfix or exim and what their experiences were. snip I'd like to make the mail server change without changing my user management tool set. I've got too much tied to vpopmail. You can inject mails from postfix one at a time into qmail and then qmail will send it the normal way. Or you get yourself a delivery agent that understands vpopmail or dot-qmail... I'm less concerned about the smtp end of the equation. I'm more interested in the deliver half of the equation. After all that is what vpopmail plays a part in, and that is the part of the system I hope to keep. I do radius and ftp authentication against it. Currently I use vpopmail with mysql. I'm thinking I can use the vpopmail table for delivery from postfix. I was wondering if anyone else had attempted it yet. It seems like it would be an easy thing to do...
Re: [vchkpw] vpopmail sans qmail.
On Fri, 2006-12-22 at 11:02 -0600, Rick Romero wrote: I think it would be nice to feel like to owner/author of qmail was actually behind it. And to do that, he should be improving upon it - that is, accepting at least the patches that we all use. Obviously it's not a complete product, unless you can point me to a substantial 'stock qmail' userbase. Nobody can even provide binaries for the 'lessers' among us - so they will never use it. my rant These couple lines are the crux of the problem for my higher ups. They feel that there is not central driving force behind qmail on a fast moving internet. It lacks user and general support base. It doesn't come with our linux distribution, and it can't receive support from packagers. If they want qmail support its one more vendor in the loop. I've got to interface with the business guys. Qmail's licensing is prohibitive to it's long term viability and Dan Bernstein will drive his own software out of existence by not being a responsible maintainer. I believe he wants it this way. 5 nay 10 years ago almost... qmail was the bomb sniggety in a world of defunct sendmails. It was fast, efficient, and simple to administer. Now it shows its age. It's apparent that it isn't well maintained except for a community that strongly believes in it, and for good reason. The problems with qmail are not technical, they're political. /myrant ne ways, I have to migrate away from my beloved qmail. I'm not too happy about it.
Re: [vchkpw] vpopmail sans qmail.
Darrel O'Pry wrote: On Fri, 2006-12-22 at 11:02 -0600, Rick Romero wrote: I think it would be nice to feel like to owner/author of qmail was actually behind it. And to do that, he should be improving upon it - that is, accepting at least the patches that we all use. Obviously it's not a complete product, unless you can point me to a substantial 'stock qmail' userbase. Nobody can even provide binaries for the 'lessers' among us - so they will never use it. my rant These couple lines are the crux of the problem for my higher ups. They feel that there is not central driving force behind qmail on a fast moving internet. It lacks user and general support base. It doesn't come with our linux distribution, and it can't receive support from packagers. If they want qmail support its one more vendor in the loop. I've got to interface with the business guys. I would contact one of the many commercial entities currently supporting qmail (how about Inter7?). Your example would mean that you have to pay for both developer support and vendor support with something like Redhat. Redhat could always say it's a sendmail issue or it's a Postfix issue. The stated problem of DJB not supporting qmail removes that, it is unlikely that anyone is the qmail commercial support community would say contact DJB, we can't fix that. In my experience just the opposite would happen, the qmail support community would respond sure we can change that. Look at what they already support. Many people point to the myriad number of patches for qmail and proclaim it's out of date, it takes so many patches to do anything. I believe it is more a case of so many patches, I can configure/engineer almost any solution with qmail. Just my thoughts and I should probably let the thread die. But if support is your stumbling block I would contact a commercial qmail support company, like the one running this list, and at least get a quote and a contract to review. No, I don't work for inter7, I've not contracted with inter7 for support, they are not paying me to promote them. Though, I did take their offer for free stuff on the website and got some cool sh*t once ;^) DAve -- Three years now I've asked Google why they don't have a logo change for Memorial Day. Why do they choose to do logos for other non-international holidays, but nothing for Veterans? Maybe they forgot who made that choice possible.
Re: [vchkpw] vpopmail sans qmail.
I'm less concerned about the smtp end of the equation. I'm more
interested in the deliver half of the equation. After all that is what
vpopmail plays a part in, and that is the part of the system I hope to
keep. I do radius and ftp authentication against it.
Currently I use vpopmail with mysql. I'm thinking I can use the vpopmail
table for delivery from postfix. I was wondering if anyone else had
attempted it yet. It seems like it would be an easy thing to do...
Here is how I do it. It is not pretty if you depend on dot-qmail.
courier-authlib 0.58 + maildrop is my tool for local delivery.
You have to patch courier-authlib to get full vpopmail support
(figures...there seems to be animosity between Sam and vpopmail?) which
is a simple patch:
http://wiki.centos.org/HowTos/vpopmail?action=AttachFiledo=gettarget=courier-authlib-vpopmail.patch
You then have to compile maildrop 2.0.2 against courier-authlib so that
it can use courier-authlib to pick up its settings from vpopmail.
So your lda is basically maildrop. The entire dot-qmail/qmail-users
mechanism is completely bypassed :(.
master.cf:
maildrop unix - n n - - pipe
flags=DRhu user=vpopmail argv=/usr/local/bin/maildrop -d ${recipient}
main.cf:
virtual_transport = maildrop
maildrop_destination_recipient_limit = 1
virtual_alias_domains = /var/qmail/control/rcpthosts
virtual_mailbox_maps = proxy:mysql:/etc/postfix/rrm_static
virtual_alias_maps = proxy:mysql:/etc/postfix/valias # if needed
rrm_static:
domain = /var/qmail/control/rcpthosts
hosts = localhost
user = vpopmail
password = vpopmailpass
dbname = vpopmail
query = select concat(pw_name, '@', pw_domain) from vpopmail where
pw_name = '%u' and pw_domain = '%d'
result_format = [EMAIL PROTECTED]
valias:
domain = /var/qmail/control/rcpthosts
hosts = localhost
user = vpopmail
password = vpopmailpass
dbname = vpopmail
query = select valias_line from valias where alias = '%u' and domain = '%d'
Re: [vchkpw] vpopmail sans qmail.
DAve wrote: Christopher Chan wrote: John Simpson wrote: On 2006-12-18, at 0444, Christopher Chan wrote: Darrel O'Pry wrote: I'm currently considering replacing qmail in my mail systems. I was wondering if anyone had tried vpopmail with postfix or exim and what their experiences were. Yeah, I use vpopmail with postfix. Love it. postfix user existence checks mean I don't have large queues. How? I have looked for this several times in the past few years and not seen it. Other than the postfix.txt on the inter7 website, but nothing substantial about how it is done, caveats, etc. Please see my post to Darrel. The caveat for the way I do it currently is you lose qmail-users and dot-qmail. Until someone writes a qmail-lspawn for postfix...you can only use maildrop + courier-authlib. funny, i've been doing the same thing using qmail (making sure recipient email addresses exist before accepting a RCPT command in the SMTP conversation) for over a year now. Yes. with a patch. I know patches exist. I have nothing against qmail. I will recommend qmail where it is most suitable...as the mta for outgoing mails for a mailing list or as the second stage in the inbound system due to dot-qmail which is a delivery system that is second to none. Uh oh, I feel it coming :) soapbox Patch smatch, if it's a patch everyone gets to beat qmail up and scream at each other about what a wasted never updated POS qmail is. So patches are bad bad bad. Only software that is poor and decrepit uses patches. But, let someone add that patch to the source code and bundle up a new package and suddenly every new user who posts a question is told You need the latest version. I have seen this many many times on many many maillists. We have not had to make a security update to our qmail installs in the 5 years we have been running them. All it took was running patch somediff a few times ONCE during the initial install. Lets be honest here, most minor version upgrades in OSS are the result of contributed patches (developer or user). Yet no one is claiming that vpopmail/postfix/perl/ruby/python is a patchy POS after we see the developers accepting patches from users and rolling out an upgrade. 'I' don't mind patches. I, however, would rather point new ones to postfix than go through the whole patched qmail thing because after patching, qmail ceases to be simple. Might as well have them wrap their heads around postfix.
Re: [vchkpw] vpopmail sans qmail.
Darrel O'Pry wrote: I'm currently considering replacing qmail in my mail systems. I was wondering if anyone had tried vpopmail with postfix or exim and what their experiences were. Yeah, I use vpopmail with postfix. Love it. postfix user existence checks mean I don't have large queues. vpopmail + mysql + postfix in my configuration. I'd like to make the mail server change without changing my user management tool set. I've got too much tied to vpopmail. You can inject mails from postfix one at a time into qmail and then qmail will send it the normal way. Or you get yourself a delivery agent that understands vpopmail or dot-qmail... It would be nice if there was an option for vpopmail to manage the /var/qmail/control/* files without qmail actually installed...for postfix I just need the contents of locals and rcpthosts...really just rcpthosts
[vchkpw] vpopmail sans qmail.
I'm currently considering replacing qmail in my mail systems. I was wondering if anyone had tried vpopmail with postfix or exim and what their experiences were. I'd like to make the mail server change without changing my user management tool set. I've got too much tied to vpopmail. .darrel.
