Re: ISPmail Lenny tutorial ready
Christoph Haas wrote:
> 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.
No pb with thousands of users...
> 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).
MySQL replication only works with low loads. In fact, running MySQL over
the network has a HUGE performance penalty.
>> On top of what you describe above, you panel does:
>> - tumgreyspf
>
> A reader suggested to give postfix-policyd-spf-python a try instead.
tumgreyspf doesn't work very well, I'd like to replace it by something
better in fact.
>> - dkimproxy (filtering and scanning)
>
> I have that on my list. Since SPF hardly helps against spam here I can
> as well try that. :)
The issue with DKIM is not about filtering. It's MANDATORY to sign your
email to be able to send to some big providers (namely: yahoo).
>> - some basic DSL stop rules (major source of spam)
>> - basic header and body checks
>
> I find those dangerous. Which do you use?
I filter things like /^dsl.*\..*/, /ppp.*\..*/ and things like that,
known attachments like file.zip, details.zip and such, known X-Mailer
like SmartMailer, Avalanche, etc, subject with medecine names (I wont
write them here to avoid triggering spam filters...), and things like
that. The most efficient is the dsl/ppp/cable one. Nowadays, there is NO
WAY someone with such reverse DNS is sending legitimate emails without
using SASL auth, and it's very efficient.
>> - 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.
I agree that maildrop is not so good, but I was stuck with it because of
the bandwidth usage thing. I'll be happy to use dovecot and sieve now.
As for the SPAM box not seen using POP3, well, that's the point of it!!!
>> - vacation messages
>
> That's fortunately easy with Dovecot+Sieve. Do you use maildrop for that
> purpose?
Also yes, as well as loop-detection and other things.
>> - 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.
Courier-maildrop sends a (configurable) message in the INBOX whenever
the mailbox reaches 90%, so it's fine.
>> - 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.
Oh yes! MLMMJ is lightyears ahead of mailman, that is to me, something
of the past. MLMMJ is really GREAT, and the dev team doing it very
friendly as well.
>> 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.
Just to remove amavis ??? Let me know if you do find a way to remove
Amavis and still have Clamav and Spamassassin running, I'm interested in
doing it as well.
>> 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?
On our system, we do monitor FTP, POP, IMAP, SMTP and web traffic in
real time, so we can disable some accounts if they abuse.
>> 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/].
Well, I perfectly know how to script things, our panel does all of the
setup by itself, and there's nothing to be done by hand by the users.
It's just that it's not really Debian policy compliant, and it cannot be
sent in a postinst.
Now, it would have been great to have some kind of conf.d folder in
Postfix, but when I asked for it in the dev list of postfix, they swear
at me saying I was a useless c**t to ask for such foolish thing. Well,
not that much, but close! Meaning that there are 2 opposing force: the
Debian policy that forbids one to edit another configuration file, and
the authors refusing to make the software configuration/user friendly.
There's nothing we can do EXCEPT convince the maintainer to modify it's
package to "see" other tools.
It's a great pleasure to exchange opinions about all this, what you did,
etc. Thanks for posting in this list, I appreciate your view a lot!
Thomas
Reply to: