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 

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 

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 :)


----- 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.


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.

Reply via email to