Re: ISPmail Lenny tutorial ready
Christoph
Very nice stuff.
I have two questions.
1 - Why don't you use postfixadmin? http://postfixadmin.sourceforge.net/
You can adjust your tutorial to use postfixadmin table styles and you
can mannage quota, users, domains, alias from a web browser.
2 - You said postgrey can also check SPF. How do you make it check for
SPF? Since you're using it for greylisting it'd be cool.
Eden
2009/7/18 Christoph Haas <email@christoph-haas.de>
>
> 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
>
>
Reply to: