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] onchange
On 2006-12-21, at 0330, Rick Widmer wrote: I think I remember you saying that you had your onchange script write to a pipe, and a program running under daemontools c reads the pipe and does the work. If so wouldn't it be a lot faster if vpopmail just wrote to the pipe? faster, perhaps... but not a lot faster, and certainly not enough to make up for the additional overhead of having to set up a pipe- listening service, or having to learn how to deal with named pipes to begin with. i see much confusion about setting up and using named pipes, but just about anybody can write a shell script. for my own needs, the shell script is a stub which writes the command line arguments to the pipe, and then my pipe-listening service does the actual work. this works for me, because the pipe-listening service runs as root, while the pipe itself can be chown()ed, chgrp() ed, and chmod()ed to be writable by non-root processes. yes, i understand that there is the overhead of fork()ing, exec()ing the shell, and parsing and running the script... but i don't think the overhead is as major an issue as you seem to think, unless you're running an ISP with hundreds of thousands of users and several changes (accounts added, deleted, and passwords changed) per second. I think it would be worthwhile to have --enable-onchange-pipe=/path/ to/pipefile. --enable-onchange-file=/path/to/file should work too. Both should have a reasonable default. that would involve adding the pipe-writing code to the patch... and for safety the code would also have to verify the existence of the pipe, plus stat() it and make sure that it IS a named pipe (rather than a regular file, directory, symlink, device, or some other kind of filesystem entity) before writing to it... i think it's easier to just leave it as running a shell script- the concept is a lot easier for people to understand and administer. and again, unless you're running a huge ISP and have a steady stream of changes, the script isn't run so often that the overhead is worth worrying about. i'm not against the idea (it would make my own server run a wee bit more quickly when accounts are added, for example) but i don't think the issue is critical enough to hold up releasing version 5.4.18. if anybody else is interested in this feature, i'll write a post-5.4.18 patch which adds the functionality, and you can do the ./configure option for it... but don't hold up the 5.4.18 release for this. -- | 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] onchange
On Dec 22, 2006, at 5:02 AM, John Simpson wrote: i think it's easier to just leave it as running a shell script- the concept is a lot easier for people to understand and administer. and again, unless you're running a huge ISP and have a steady stream of changes, the script isn't run so often that the overhead is worth worrying about. I'd have to agree with John. This fits well with djb's principle of having small programs interact with each other. There's no need to us to maintain pipe writing code like that in vpopmail. -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
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] Re: vpopmail sans qmail.
On Fri, 2006-12-15 at 21:01 +, Robin Bowes 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. I'd like to make the mail server change without changing my user management tool set. I've got too much tied to vpopmail. Which bit of the mail server do you want to change? And why? I think you'll struggle to remove the local delivery part as vpopmail is pretty much tied to qmail, but you could always use a different smtp server as a front end to a system running qmail internally. Personally, I run qmail/vpopmail with qpsmtpd as the smtpd server. R. The whole shoot and shebang. It seems the powers that be have decided that Qmail is 'unmaintained', and no longer consider it a viable option for our businesses' long term needs. I don't have any say in this unfortunately. I just get to plan and execute the migration. .darrel.
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.
