[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.
[vchkpw] qmail tap + john simpson combined patch
Hi list: Have anyone of you achieve to patch qmail source with john simpson combined patch (version stable 6) and then apply the qmail-tap patch without getting any errors?? or any one know how to do it, combine both patches and have a successfull qmail compiling?? Thanks in advance -- _ Facundo Agustin Barrera -- www.openlabs.com.ar Let the penguins do the work - Buenos Aires - Argentina _
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] Re: vchpw/onauth connection types
Joshua Megeman wrote: It sets the connection type based on a list of known ports (25/465/587 for SMTP, 110/995 for POP and 143/993 for IMAP), and defaults to POP on an unknown conenction. Sorry, this isn't an actual thread reply, but I just came across an issue with the vchkpw program itself. I use Dovecot for my IMAP server, and to get last auth to work properly, I have to call the vchkpw program. LastAuth works now, but since vchkpw defaults to pop, a pop restriction causes IMAP (and webmail) not to work ;) Now I'll admit this is probably a mistake in how Dovecot does vpopmail authentication - but I was wondering if we could also set the connection type based on the binary name. For example, vchkpw-imap would set the type to imap. vchkpw-smtp would set it to smtp, etc. This seems like a trivial change, and would only require a softlink back to vchkpw to enable. Am I thinking straight, or am I way offbase? Rick
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
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 user existency on remote server ? FYI: rsync of passwd.cdb is ok, but how check against aliases ? Please, I need some pointing where
Re: [vchkpw] Re: vchpw/onauth connection types
Joshua Megeman wrote: It sets the connection type based on a list of known ports (25/465/587 for SMTP, 110/995 for POP and 143/993 for IMAP), and defaults to POP on an unknown conenction. Sorry, this isn't an actual thread reply, but I just came across an issue with the vchkpw program itself. I use Dovecot for my IMAP server, and to get last auth to work properly, I have to call the vchkpw program. LastAuth works now, but since vchkpw defaults to pop, a pop restriction causes IMAP (and webmail) not to work ;) Now I'll admit this is probably a mistake in how Dovecot does vpopmail authentication - but I was wondering if we could also set the connection type based on the binary name. The connection type is based on the value of the TCPLOCALPORT environment variable, which defaults to 110 if it's not set. I don't know exactly how dovecot works, but if you're not calling it from tcpserver, that's probably what's happening. For example, vchkpw-imap would set the type to imap. vchkpw-smtp would set it to smtp, etc. This seems like a trivial change, and would only require a softlink back to vchkpw to enable. Am I thinking straight, or am I way offbase? It's not an unreasonable way of doing things, although vchkpw will try to figure out what the connection type is based on argv[1] if the port is unknown. Maybe the best solution is to eliminate the default setting of LocalPort to 110 if TCPLOCALPORT isn't set, allowing vchkpw to look for true (smtp) or imap (imap) in argv[1]. I would think that if the local port variable isn't set, we should leave it as an unknown, and not force it to 110 (thus forcing a pop connection down the line). Anyone else? -- Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics [EMAIL PROTECTED]
Re: [vchkpw] qmail tap + john simpson combined patch
you can try merge both patch on one... 'cause each one have much similar things, and when the second try to patch the code, aren't the same code where the patch was created... it's a little work, but must be done... -- []'s Rafael 'fumasa' Giorgetti On 1/11/07, Facundo Barrera - GMail [EMAIL PROTECTED] wrote: Hi list: Have anyone of you achieve to patch qmail source with john simpson combined patch (version stable 6) and then apply the qmail-tap patch without getting any errors?? or any one know how to do it, combine both patches and have a successfull qmail compiling?? Thanks in advance -- _ Facundo Agustin Barrera -- www.openlabs.com.ar Let the penguins do the work - Buenos Aires - Argentina _
Re: [vchkpw] Re: vchpw/onauth connection types
Joshua Megerman wrote: For example, vchkpw-imap would set the type to imap. vchkpw-smtp would set it to smtp, etc. This seems like a trivial change, and would only require a softlink back to vchkpw to enable. Am I thinking straight, or am I way offbase? It's not an unreasonable way of doing things, although vchkpw will try to figure out what the connection type is based on argv[1] if the port is unknown. Maybe the best solution is to eliminate the default setting of LocalPort to 110 if TCPLOCALPORT isn't set, allowing vchkpw to look for true (smtp) or imap (imap) in argv[1]. I would think that if the local port variable isn't set, we should leave it as an unknown, and not force it to 110 (thus forcing a pop connection down the line). Anyone else? I'd be very nervous about changing the default action. I've already learned my lesson (the hard way) about making tiny changes to existing functionality - even when you think it shouldn't matter to anyone else... it probably does. It seems to me that since vchkpw uses TCPLOCALPORT to determine how it is called, and Dovecot wants to use vchkpw for password checking, then Dovecot should handle setting the environment variables properly. Possibly it is a matter of the way Dovecot is being started that is hiding the environment variable. Maybe you can set the environment variable before calling vchkpw. You are running on a standard imap port, right? If Dovecot has a constant value passed into argv[1] I would be willing to add that to the guessing code in vchkpw, but I don't like the idea of adding _another_ block of testing for argv[0]. I believe the best answer is to have the right port in TCPLOCALPORT when you call vchkpw. Rick
