[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: qmail is officially public domain. have at it lads!
* Erwin Hoffmann <feh@xxxxxxxxx> wrote:
> Hi
>
> At 14:45 04.12.2007 -0500, John Simpson wrote:
> >
> >a perfect example is validating RCPT commands so you don't accept mail
> >for non-existent mailbox names. the "chkuser" patch is popular, but it
> >only works with vpopmail, and it doesn't work well in multi-server
> >situations. my own "validrcptto.cdb" patch can work with any back-end
> >and works well in multi-server cases, but it requires an external
> >process to rebuild the .cdb file whenever it changes. both approaches
> >already have a lot of people using them, and i'm sure there are others.
>
> (a) As far as I am concerned (the RECIPIENTS extension) version 0.5 will
> allow to call a PAM to do a RCPT TO verification (per domain).
>
> >the same goes for handling AUTH commands. the various command-line
> >patches (based on the old patch by "mrs brisby") require an
> >appropriate "checkpassword" program, but those are slow because they
> >fork other processes to do the work. i wrote a patch which uses an
> >"auth.cdb" file, but again it requires an external process to update
> >the file whenever it changes. qmail-ldap has its own way of handling
> >this, and i'm sure there are others.
>
> (b) Unless you use an internal SASL approach, calling an external program
> is 'the' solution. The problem comes if you try to combine (b) and (a) and
> perhaps a (c) POP3/IMAP4 userid verification.
>
> I will redo my "Auth" implementation and perhaps add CRAM-MD5 support for
> qmail-remote. This is necessary.
>
> >it's going to be interesting to see what people develop now. i don't
> >think any of it can be said to be "official" unless it's developed or
> >sanctioned by djb- in my mind, he owns the name "qmail", and nobody
> >should be doing anything to dilute the reputation of that name.
> >however, the group who developed "netqmail" is recognized as the "next
> >best thing", so whatever they do, people are going to pay attention to
> >it.
> >
> >i suspect the first thing we'll see is a netqmail source tarball which
> >has djb's code with their patch already applied (instead of the
> >tarball, the patch, and a script) and probably binary packages built
> >from that... and then MAYBE a discussion here about whether, and how,
> >they want to expand on it.
>
> Yes. I believe so too. But I will stay with my 'minimalistic' approaches to
> add code to qmail.
>
> Anyway. I am suffering the same fate as DJB: My university lessons I have to
> give, leave (me) very little time for qmail enhancements.
>
> Whats lacking in qmail (from my persective):
>
> 1. Uniform (+high speed) user verification at any level (SMTP/POP3/IMPA4).
> 2. Propper AUTH implementation.
> 3. Propper SSL for qmail-remote.
And DKIM.
--
regards, TR