Re: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz"
Dave Richardson wrote: Guys, in the interest of advancing the science of vpopmail, would you please consider taking this discussion/argument/difference-of-opinion offline? +1 I'm keenly anxious to see the possible new directions that vpopmail may grow given the several threads of recent activity. Your energy and wisdom applied to that end would be most excellent! If you are interested in the gory details you should probably be watching the vpopmail-devel list too. I try to keep as much of the internals discussion and all the patches over there. Rick
Re: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz"
Guys, in the interest of advancing the science of vpopmail, would you please consider taking this discussion/argument/difference-of-opinion offline? I'm keenly anxious to see the possible new directions that vpopmail may grow given the several threads of recent activity. Your energy and wisdom applied to that end would be most excellent! Cheers, Dave.
Re: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz"
QMAIL was a secure product and a good academic programming model, ten years ago. Now, a modern MTA facing millions of emails has completely different problems from the ones Bernstein faced. But he made a closed architecture, not a modular one, adding a no-sense license. Hmm...qmail is STILL a secure and a good programming model. I don't see how it has become unsecure. I said "it was" because at that time it was the unique one to be so safe. Now that other products give good security, the lack of features outperforms the need of security. I do not see how that makes it a 'was secure'. Even you make the point that its problem is the lack of features and not that it has somehow become insecure. Features is not the same as security. Anyway, programming model is horrible, despite of other considerations. You have not made any qualifying statements on this other than your insistence on your opinion. Saying the programming model is horrible does not make it so. I have pointed out that the code is readable. Let me explain that a bit more. The flow is readily discernible and I doubt that is a mark of a poor programming model. Perhaps you can enlighten us on that. As for programming model, I don't see a problem. The only problem I see is the lack of certain capabilities and qmail's current architecture. Actually, not a problem with the design of the architecture but the state of it. postfix uses the same architecture with certain improvements like persistent daemons in the manner of httpd and a more advanced queue manager. If postfix had dot-qmail support, it would become rather complete. You call that "same architecture"? I don't see why not. One can always swap out the tcpserver and qmail-smtpd combination with something else similar to postfix's master + smtpd combination. So it becomes a matter of the components. If that does not show that it is the same architecture then I do not know what you mean by architecture. One can do the same for qmail-send qmail-lspawn qmail-rspawn qmail-local qmail-remote. QMAIL has a lot of problems; the mail world has changed but QMAIL is designed to be impossible to change because of the presunction of Bernstein of being a perfect designer. qmail does not have a lot of problems. Quite bug free and secure :D. DJB is a perfect designer. The fact that Wietse uses the same basic design speaks for itself. We are only complaining that he has stopped and not continued. If the architecture cannot grow, designer wasn't that good. Bah! You claim that the architecture cannot grow. I call nonsense on your assertion. postfix uses the same basic design, the difference only being the components and postfix has demonstrated quite clearly that the design is good and efficient one. Just because qmail's components are lacking in certain behaviours and features does not mean that the architecture design was bad. QMAIL is no more mantained because Bernstein is prisoner of his wrong architecture. He cannot improve it, because he should change all the architecture, and none would follow him today on the same licensing scheme. I am sorry but I really doubt you can do any better. Do you plan to show us by writing your own MTA? I've not fear of that. I'll have spare time (I have to work, I'm not that rich) I will do. Funny that. DJB too had to work when he wrote qmail and I believe he is still working. ROTFL. When you manage a software project that has as clean a record as qmail with respects to bugs, come back and let us know. Are you speaking of Open Source or professional projects? I can tell you about projects I worked on: transactional systems, telex switching systems, and so on. Millions/hundreds thousand lines of code, zero final bug (and very few during development) because of a very good design of systems. Great. I await your qmail replacement. Bug free does not mean anything, when software is hard to change and makes easy to add new errors. And difficult code does not mean good code, as in this case. You find qmail code to be difficult? Now that is a laugh...I find it rather readable compared to other stuff I have looked at. Not even postfix can claim anything near qmail's record. Postfix takes the risk to grow, while qmail is perfect (according to you) and dead. Since when did I say it was perfect. I have quite clearly pointed out that I am complaining of DJB's lack of continued development of qmail. I have gone so far as to advocate postfix in replacement of qmail in a wide variety of environments but not a lot on this list. You however have called to question not its lack of features/development of features but its architecture and programming model without any case for such criticisms other than your opinion.
Re: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz"
At 14.14 15/01/2007, you wrote: People has not the courage to say that Bernstein design and coding is horrible. ??? QMAIL was a secure product and a good academic programming model, ten years ago. Now, a modern MTA facing millions of emails has completely different problems from the ones Bernstein faced. But he made a closed architecture, not a modular one, adding a no-sense license. Hmm...qmail is STILL a secure and a good programming model. I don't see how it has become unsecure. I said "it was" because at that time it was the unique one to be so safe. Now that other products give good security, the lack of features outperforms the need of security. Anyway, programming model is horrible, despite of other considerations. Perhaps you can enlighten us on that. As for programming model, I don't see a problem. The only problem I see is the lack of certain capabilities and qmail's current architecture. Actually, not a problem with the design of the architecture but the state of it. postfix uses the same architecture with certain improvements like persistent daemons in the manner of httpd and a more advanced queue manager. If postfix had dot-qmail support, it would become rather complete. You call that "same architecture"? QMAIL has a lot of problems; the mail world has changed but QMAIL is designed to be impossible to change because of the presunction of Bernstein of being a perfect designer. qmail does not have a lot of problems. Quite bug free and secure :D. DJB is a perfect designer. The fact that Wietse uses the same basic design speaks for itself. We are only complaining that he has stopped and not continued. If the architecture cannot grow, designer wasn't that good. QMAIL is no more mantained because Bernstein is prisoner of his wrong architecture. He cannot improve it, because he should change all the architecture, and none would follow him today on the same licensing scheme. I am sorry but I really doubt you can do any better. Do you plan to show us by writing your own MTA? I've not fear of that. I'll have spare time (I have to work, I'm not that rich) I will do. ROTFL. When you manage a software project that has as clean a record as qmail with respects to bugs, come back and let us know. Are you speaking of Open Source or professional projects? I can tell you about projects I worked on: transactional systems, telex switching systems, and so on. Millions/hundreds thousand lines of code, zero final bug (and very few during development) because of a very good design of systems. Bug free does not mean anything, when software is hard to change and makes easy to add new errors. And difficult code does not mean good code, as in this case. Not even postfix can claim anything near qmail's record. Postfix takes the risk to grow, while qmail is perfect (according to you) and dead. Regards, Tonino Just my 1 eurocent. Soon I will have my 1 plastic HK Dollar.
Re: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz"
People has not the courage to say that Bernstein design and coding is horrible. ??? QMAIL was a secure product and a good academic programming model, ten years ago. Now, a modern MTA facing millions of emails has completely different problems from the ones Bernstein faced. But he made a closed architecture, not a modular one, adding a no-sense license. Hmm...qmail is STILL a secure and a good programming model. I don't see how it has become unsecure. Perhaps you can enlighten us on that. As for programming model, I don't see a problem. The only problem I see is the lack of certain capabilities and qmail's current architecture. Actually, not a problem with the design of the architecture but the state of it. postfix uses the same architecture with certain improvements like persistent daemons in the manner of httpd and a more advanced queue manager. If postfix had dot-qmail support, it would become rather complete. postfix code is however harder to follow than qmail's. Plugin is slow, and does not let do anything important, just side checks. The core is untouched, and here the problem is the core. Yes, the core can do with some improvements for certain scenarios. QMAIL has a lot of problems; the mail world has changed but QMAIL is designed to be impossible to change because of the presunction of Bernstein of being a perfect designer. qmail does not have a lot of problems. Quite bug free and secure :D. DJB is a perfect designer. The fact that Wietse uses the same basic design speaks for itself. We are only complaining that he has stopped and not continued. QMAIL is no more mantained because Bernstein is prisoner of his wrong architecture. He cannot improve it, because he should change all the architecture, and none would follow him today on the same licensing scheme. I am sorry but I really doubt you can do any better. Do you plan to show us by writing your own MTA? No one follows him on the licensing because corporations have made sure that things have become so muddied that no one would risk not specifying a license...but others have taken it a step further and made licenses to 'fight' back like the GPL. I find it ludicrous that software is 'licensed and not sold'. I can very do anything I like with a book I bought and that goes for software. Qmail is only an academic example of programming, that in real life should never be used by expert programmers. ROTFL. When you manage a software project that has as clean a record as qmail with respects to bugs, come back and let us know. Not even postfix can claim anything near qmail's record. Just my 1 eurocent. Soon I will have my 1 plastic HK Dollar.
Re: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz"
At 18.16 11/01/2007, you wrote: Look at QMAIL-SPP ( <http://qmail-spp.sourceforge.net/>http://qmail-spp.sourceforge.net/ ). It provides a plugin for vpopmail and gets away from this patching situation. The idea is great, the implementation is good. A mix of this and the existing patches you may have is probably the best way to go. QMAIL-SPP is an old style answer to an old style problem. People has not the courage to say that Bernstein design and coding is horrible. QMAIL was a secure product and a good academic programming model, ten years ago. Now, a modern MTA facing millions of emails has completely different problems from the ones Bernstein faced. But he made a closed architecture, not a modular one, adding a no-sense license. QMAIL-SPP has the same problems of qmail, and from my point of view it uses a terrible approach speaking about performances and impossible sophistication of wanted features. In the end, you make a perl script or something on the RCPT command that: a. matches a line with the domain of the RCPT command in the smtproutes file (making sure it has access to read it) b. if it exists, then opens a socket connection and begins connecting c. returns an accept, reject, or defer based on the output of the program- also possibly adds headers accordingly. The plugin infrastrucutre is really key. It's not as fast due to performance hits of launching these plugins, but it still makes it faster than many applications. Plugin is slow, and does not let do anything important, just side checks. The core is untouched, and here the problem is the core. It makes adding plugins as easy as adding a line to the text file. Think about even just a sleep() command in a shell file could be easily implemented. qmail has been around for a long time and hence has series of feature additions upon feature additions. But remember, these patches aren't fixing problems with qmail. There are very few actual PROBLEMS with qmail, and they're relatively minor and things that softlimit and equivalent fix. QMAIL has a lot of problems; the mail world has changed but QMAIL is designed to be impossible to change because of the presunction of Bernstein of being a perfect designer. People add patches because they want features. Because there is no active development by the creator these have to be added themselves. QMAIL is no more mantained because Bernstein is prisoner of his wrong architecture. He cannot improve it, because he should change all the architecture, and none would follow him today on the same licensing scheme. You add the features you want in your qmail installation. Others have differing opinions as to what should be added. If you want to manipulate simple perl/shell/C scripts to SMTP conversations, install qmail-spp. Qmail doesn't have a need to change. It's still doing the task it was intended to very well. If another product suits your needs better, by all means go to it, but that doesn't mean qmail is bad. Also, patches allow you to add those features that others have wanted. In the old days, you had to program them yourself :) Qmail is only an academic example of programming, that in real life should never be used by expert programmers. Just my 1 eurocent. Tonino -M - Original Message From: tonix (Antonio Nati) <[EMAIL PROTECTED]> To: vchkpw@inter7.com Sent: Thursday, January 11, 2007 6:31:40 AM Subject: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz" I'm thinking to extend chkuser, and add an smtp fake delivery for checking recipients existance on end systems (i.e. when domains are external and use me as proxy SMTP). But I'm really tired to fight with qmail. Bernstein programming is accademic and heavy to use, license is criminal. Programming with patches over patches is painful. There is no fun to put new features on this old and overextimated product. You have to run several chained programs just to make an SMTP acceptance... I feel is time to migrate to another product, or is there anyone available to start a new project, that should rewrite a little by little qmail, and free all of us from this criminal license? Project should start with a "programmed way" to add new features and patch, then making a decent "configure", then starting to write new libraries and then substituting the old code, until we have a free mail system. Of course vpopmail would be a library integrated in this new product. I have thrown the first stone. Tonino At 00.25 11/01/2007, you wrote: >Hello all, > >I have this setup : mail coming to relay server located in DMZ, and >this server is relaying x domains to internal LAN mail server. >Im receiving lot of unwanted mails for nonexistent addresses. > >Ho I can handle it ? Chkuser is working fine when are domains on >server, but how I can "check&q
Re: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz"
Look at QMAIL-SPP ( http://qmail-spp.sourceforge.net/ ). It provides a plugin for vpopmail and gets away from this patching situation. The idea is great, the implementation is good. A mix of this and the existing patches you may have is probably the best way to go. In the end, you make a perl script or something on the RCPT command that: a. matches a line with the domain of the RCPT command in the smtproutes file (making sure it has access to read it) b. if it exists, then opens a socket connection and begins connecting c. returns an accept, reject, or defer based on the output of the program- also possibly adds headers accordingly. The plugin infrastrucutre is really key. It's not as fast due to performance hits of launching these plugins, but it still makes it faster than many applications. It makes adding plugins as easy as adding a line to the text file. Think about even just a sleep() command in a shell file could be easily implemented. qmail has been around for a long time and hence has series of feature additions upon feature additions. But remember, these patches aren't fixing problems with qmail. There are very few actual PROBLEMS with qmail, and they're relatively minor and things that softlimit and equivalent fix. People add patches because they want features. Because there is no active development by the creator these have to be added themselves. You add the features you want in your qmail installation. Others have differing opinions as to what should be added. If you want to manipulate simple perl/shell/C scripts to SMTP conversations, install qmail-spp. Qmail doesn't have a need to change. It's still doing the task it was intended to very well. If another product suits your needs better, by all means go to it, but that doesn't mean qmail is bad. Also, patches allow you to add those features that others have wanted. In the old days, you had to program them yourself :) -M - Original Message From: tonix (Antonio Nati) <[EMAIL PROTECTED]> To: vchkpw@inter7.com Sent: Thursday, January 11, 2007 6:31:40 AM Subject: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz" I'm thinking to extend chkuser, and add an smtp fake delivery for checking recipients existance on end systems (i.e. when domains are external and use me as proxy SMTP). But I'm really tired to fight with qmail. Bernstein programming is accademic and heavy to use, license is criminal. Programming with patches over patches is painful. There is no fun to put new features on this old and overextimated product. You have to run several chained programs just to make an SMTP acceptance... I feel is time to migrate to another product, or is there anyone available to start a new project, that should rewrite a little by little qmail, and free all of us from this criminal license? Project should start with a "programmed way" to add new features and patch, then making a decent "configure", then starting to write new libraries and then substituting the old code, until we have a free mail system. Of course vpopmail would be a library integrated in this new product. I have thrown the first stone. Tonino At 00.25 11/01/2007, you wrote: >Hello all, > >I have this setup : mail coming to relay server located in DMZ, and >this server is relaying x domains to internal LAN mail server. >Im receiving lot of unwanted mails for nonexistent addresses. > >Ho I can handle it ? Chkuser is working fine when are domains on >server, but how I can "check" user existency on remote server ? >FYI: rsync of passwd.cdb is ok, but how check against aliases ? > >Please, I need some pointing where to look at. i fit is possible done >by chkuser or another way (qmail-ldap) > >Thank you > >Peter M.
Re: [vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz"
Alle 12:31, giovedì 11 gennaio 2007, tonix (Antonio Nati) ha scritto: > I'm thinking to extend chkuser, and add an smtp fake delivery for > checking recipients existance on end systems (i.e. when domains are > external and use me as proxy SMTP). > > But I'm really tired to fight with qmail. Bernstein programming is > accademic and heavy to use, license is criminal. Programming with > patches over patches is painful. There is no fun to put new features > on this old and overextimated product. You have to run several > chained programs just to make an SMTP acceptance... > > I feel is time to migrate to another product, or is there anyone > available to start a new project, that should rewrite a little by > little qmail, and free all of us from this criminal license? > > Project should start with a "programmed way" to add new features and > patch, then making a decent "configure", then starting to write new > libraries and then substituting the old code, until we have a free > mail system. Of course vpopmail would be a library integrated in this > new product. Hello tonix, hello all also i thinks it's time to create a new MTA compatibles with qmail (but more important is vpopmail). The only motivation for use qmail today is vpopmail and related tool (qmailadmin, vqadmin,...). Patch over patch isn't a good way to procede. Bye
[vchkpw] Rethinking qmail : was Re: [vchkpw] how use chkuser on "dmz"
I'm thinking to extend chkuser, and add an smtp fake delivery for checking recipients existance on end systems (i.e. when domains are external and use me as proxy SMTP). But I'm really tired to fight with qmail. Bernstein programming is accademic and heavy to use, license is criminal. Programming with patches over patches is painful. There is no fun to put new features on this old and overextimated product. You have to run several chained programs just to make an SMTP acceptance... I feel is time to migrate to another product, or is there anyone available to start a new project, that should rewrite a little by little qmail, and free all of us from this criminal license? Project should start with a "programmed way" to add new features and patch, then making a decent "configure", then starting to write new libraries and then substituting the old code, until we have a free mail system. Of course vpopmail would be a library integrated in this new product. I have thrown the first stone. Tonino At 00.25 11/01/2007, you wrote: Hello all, I have this setup : mail coming to relay server located in DMZ, and this server is relaying x domains to internal LAN mail server. Im receiving lot of unwanted mails for nonexistent addresses. Ho I can handle it ? Chkuser is working fine when are domains on server, but how I can "check" user existency on remote server ? FYI: rsync of passwd.cdb is ok, but how check against aliases ? Please, I need some pointing where to look at. i fit is possible done by chkuser or another way (qmail-ldap) Thank you Peter M.
Re: [vchkpw] how use chkuser on "dmz"
On Jan 10, 2007, at 3:25 PM, Miki wrote: Ho I can handle it ? Chkuser is working fine when are domains on server, but how I can "check" user existency on remote server ? FYI: rsync of passwd.cdb is ok, but how check against aliases ? rsync ~vpopmail/domains but have it ignore any directory with "Maildir" in the name. That way you won't be syncing gigabytes of email. As Rick mentioned, mirror the /var/qmail/control/* and /var/qmail/ users/* files, *except* for /var/qmail/control/virtualdomains. -- Tom Collins - [EMAIL PROTECTED] Vpopmail - virtual domains for qmail: http://vpopmail.sf.net/ QmailAdmin - web interface for Vpopmail: http://qmailadmin.sf.net/
Re: [vchkpw] how use chkuser on "dmz"
Miki wrote: Hello all, I have this setup : mail coming to relay server located in DMZ, and this server is relaying x domains to internal LAN mail server. Im receiving lot of unwanted mails for nonexistent addresses. Ho I can handle it ? Chkuser is working fine when are domains on server, but how I can "check" user existency on remote server ? FYI: rsync of passwd.cdb is ok, but how check against aliases ? Please, I need some pointing where to look at. i fit is possible done by chkuser or another way (qmail-ldap) Follow up: You could mount the /home/vpopmail/domains/domain.com dir via NFS or rsync it hourly to keep it in sync if needed (rather than have to add all new users and aliases on both machines.) Regards, Rick
Re: [vchkpw] how use chkuser on "dmz"
Miki wrote: Hello all, I have this setup : mail coming to relay server located in DMZ, and this server is relaying x domains to internal LAN mail server. Im receiving lot of unwanted mails for nonexistent addresses. Ho I can handle it ? Chkuser is working fine when are domains on server, but how I can "check" user existency on remote server ? FYI: rsync of passwd.cdb is ok, but how check against aliases ? Please, I need some pointing where to look at. i fit is possible done by chkuser or another way (qmail-ldap) One option would be to create a duplicate of the domain, users and aliases, on the relay server and then remove the domain.com entry from virtualdomains. chkusr will check the duplicate for required users but qmail-send will use the smtproutes to send the mail on to the final destination. An unintended ability but it works very well all the same. We use it here for pre-filtering Exchange servers for clients. They can even login to qmailadmin and add users. Cheers, Rick
[vchkpw] how use chkuser on "dmz"
Hello all, I have this setup : mail coming to relay server located in DMZ, and this server is relaying x domains to internal LAN mail server. Im receiving lot of unwanted mails for nonexistent addresses. Ho I can handle it ? Chkuser is working fine when are domains on server, but how I can "check" user existency on remote server ? FYI: rsync of passwd.cdb is ok, but how check against aliases ? Please, I need some pointing where to look at. i fit is possible done by chkuser or another way (qmail-ldap) Thank you Peter M.