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 to look at. i fit is possible done
>by chkuser or another way (qmail-ldap)
>
>Thank you
>
>Peter M.
