[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: qmail is officially public domain. have at it lads!



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.

Actually, this is/was my agenda for SPAMCONTROL 2.5 (except for (2.)).

In addition, today topics like "Greylisting", "Greetdelay", SPF, and others, 
I would very much like to solve outside qmail.

rblsmtpd is the place where this should happen. 

These are simply my thoughts.

regards.
--eh.

and thanks to DJB for qmail et al. 




Dr. Erwin Hoffmann | FEHCom | http://www.fehcom.de/
Wiener Weg 8, 50858 Cologne | T: +49 221 484 4923 | F: ...24