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

Re: ISPmail Lenny tutorial ready

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

> 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

> - 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

> 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


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: