I'll leave the compressed mailbox thing till last, since that's a bit disjointed
The wildcard locals is useful, no arguments here, I could see it screwing some smtproutes up though What if List.domain.net is routed to blahblah But in the locals is .domain.net Then the sender would get a "no mailbox here by that name" (since the ldap server wont have any addresses @list.domain.net) But that is more of a admin sloppyness issue, since a good admin wouldn't do that :) Maybe another compiletime or /controls option ? ----------- Ok I just thought this after typing all that The concurrency limits how many people can be receiving/retrieving mail at a time, so if that is more limited it might not be that bad to cpu, but if you wanted to remove a spam message from every mailbox, it isn't that easy I had to grep an entire maildirs directory for a certain email, then delete those once found That would be many times harder with compressed messages (below is what I typed before I thought of "point 1") ------ But you'd need to upgrade the cpu to handle the processing of the de/compress of the mail messages Especially for 100000 customers :) Inbound mail needs to be compressed, outbound decompressed And it isn't that hard to add space to a server, add a second hard-drive and move the mailboxes to it (especially easy on qmail-ldap, just stop the local deliveries, and tar cf - | tar xvf -the maildirs in then out onto the bigger drive) But ldap modifies aren't that hard either :) ... Nice little php script (since php has ldap "built in" on most redhat, and easily added into source compiles) Granted it's useful, maybe even if it could be enabled on a (mail)box by box basis, but I don't know if it's that useful in production -----Original Message----- From: Franky Van Liedekerke [mailto:[EMAIL PROTECTED]] Sent: Sunday, 10 March 2002 19:48 To: [EMAIL PROTECTED] Subject: Re: feature request it's more of a nice feature to have: think about when you have one machine with 100000 customers and the management suddenly changes the max mailboxsize from 5 mb to 50 mb. It's not that easy to "add space" in a server. And splitting the accounts over 2 servers, requires 50000 ldap modifies :( Now the latest qmail-ldap patch allows for one machine to have multiple "mailhost" names, so then it is easier to split: you invent a new name every 10000 clients and when time comes, you can split whatever and however you like. Consolidated storage stays expensive ... No remarks on the second feature request (wildcards in rcpthosts/locals)? It's a nice thing to have if you have more than 3000 subdomains to handle ... Franky On Sun, 10 Mar 2002 17:08:56 +1000 "Kosh Naranek" <[EMAIL PROTECTED]> wrote: > Looks like it's compiler-time optional in the patch > > But it would mess up the mail download bar in netscape (the STAT > returns the compressed sizes), and as you said "hdd is cheaper than > cpu". A 100gb drive is now like 300usd, and ldap supports clustering > (really really well too :) ). > > -----Original Message----- > From: Mike Jackson [mailto:[EMAIL PROTECTED]] > Sent: Sunday, 10 March 2002 05:16 > To: Franky Van Liedekerke > Cc: [EMAIL PROTECTED] > Subject: Re: feature request > > > Franky Van Liedekerke wrote: > > > > Hi all, > > > > it's so quit on this list, so I'm reading over my old mail and see > > some features that would be nice to see in qmail-ldap: > > > > 1) transparent maildir compression, see: > > http://www.jedi.claranet.fr/qmail-compression.patch > > Hi, > Although maildir compression sounds like a nice idea to save hard > disk space, disk space is usually cheaper than processor speed. On a > heavily used IMAP server, all of that compressing and uncompressing > would probably kill a machine. On a personal mail server, this could > be quite nice. So, if this patch is integrated then please make it > optional to use, for example by the existence of a > /var/qmail/control/compression file. > > Mike >
