Thomas Goirand schrieb: > Christoph Haas wrote: >> My new ISPmail tutorial for Lenny is out. Yay! > > I had a look at your tutorial, it's funny to see that it's very close to > what our control panel does. In fact, we do absolutely all of what is > described there, except that we don't use MySQL for postfix as we have > found that flat files are faster: the DB is just dumped into flat files. How many virtual users and aliases do you have? I'm not sure how well it scales with more than a thousand users. I just have 150 accounts here on a server that I used for testing. And I love the flexibility of putting a row into a database table and instantly having the change online. Somehow I don't like batch processes that create text/hash files unless necessary. > The issue with having dbs for Postfix is that in many cases, something > can go wrong with your MySQL server. While this is fine for pop/imap, > it's not at all for mail delivery. If the MySQL service becomes unavailable for Postfix then the sending server will get a 4xx temporary error. In a huge setup I'd probably set up monitoring to get noticed of such outages quickly. And I'd use a load balancer in front of two MySQL instances (master-slave replication). > Also, it's forcing you to have a > wrong db schema as it has to be what postfix expect. I like it that the SQL queries are completely customizable. You aren't forced to anything really. > On top of what you describe above, you panel does: > - tumgreyspf A reader suggested to give postfix-policyd-spf-python a try instead. > - dkimproxy (filtering and scanning) I have that on my list. Since SPF hardly helps against spam here I can as well try that. :) > - some basic DSL stop rules (major source of spam) > - basic header and body checks I find those dangerous. Which do you use? > - delivery in a SPAM imap box (using maildrop) With Dovecot you can use a global sieve configuration file to drop spam into a seperate folder. Maildrop has been a pain here. Seeing that it has a wrapper that catches segfaults (which it throws frequently) convinced me that I don't want to use it. And another problem are users who juse use POP3 because they just get to see their inbox. > - vacation messages That's fortunately easy with Dovecot+Sieve. Do you use maildrop for that purpose? > - mailbox quota Dovecot handles that. Although I don't like that the respective user does not get informed about the limits and just suddenly doesn't get mail any more. > - SMTP and pop3 traffic accounting in real time (if using courier) > - MLMMJ lists management Can you compare that to mailman? I haven't used MLMMJ yet. > And of course: > - root interface to add/remove domains > - virtual admin interface to add/remove email > - email panel so the users can change their mailbox parameters > > Managing emails "by hand" on the shell is just not practical, IMHO. True. I'm currently preparing something for the new database layout. > Over the years, we have found that the biggest issue in this setup is > amavis. It's a dog: it takes an incredible amount of RAM and CPU for > what it does, and often crashes. Seems that the Lenny version is better > than the etch one (that was crashing for no reasons), but still, I don't > consider it a good product. Has anyone ever work with DSPAM? How is it > compared to amavis? I'm totally with you regarding Amavis. It's a resource hog, has cryptic configuration and sometimes just doesn't work for no reason. dspam is very badly documented and barely useable. I now have clamav-milter and spamassassin-milter on my list of things to try. > Also, does one of you know a way to get the traffic information out of > dovecot? We support Dovecot, but don't use it, just because of that. > It's a shame because Dovecot is a WAY faster than courier. And much easier to configure. Not sure about the traffic information part though. Do you intend to limit the number of bytes a certain user transmits? > Last thing: I think it's a shame that, when you setup amavis, clamav, > spamassassin and postfix in Debian, they are not configured by default > to work together. There's a lot of scripting needed to do this setup, > and there's no way (because of the Debian policy) to do this in a Debian > package postinst script. That might indeed be a bit too much to ask for. Postfix does one thing - and it does it well. You can combine it with many other pieces of software and it's hard to tell what you want to do with it. Emmanuel Revah made a step in that direction and is offering DISS [http://diss.manurevah.com/]. Cheers Christoph
Attachment:
signature.asc
Description: OpenPGP digital signature