Re: Let's write a system admin friendly mail server packaging system
Mario 'BitKoenig' Holbe wrote:
> So far this is independent of third packages which is IMHO fine and
> desirable. So far, this could be solved by a postfix-conf.d-snippet
> shipped with the amavis package.
Quite not. You also need to configure the incoming and outgoing ports of
amavis the correct way.
> That's pain, indeed, and should IMHO be avoided at all.
> A clean way to conf this would be
> * postfix ships to amavis
> * amavis ships back to postfix
> * postfix ships to dkimproxy
> * dkimproxy ships back to postfix
> I don't know if this is possible with postfix yet. The sendmail milter
> approach is way cleaner regarding such stuff.
No, it's not any cleaner, and it's slower. As I wrote previously, we
really don't want to have lower performances on a mail server if we want
to do things seriously. And by the way, you wrote:
postfix -> amavis -> dkimproxy -> postfix
when what we really want to do is:
postfix -> dkimproxy -> amavis -> postfix
for obvious performance reasons.
>> This is a LOT less trivial than what you pretend.
>
> That's not just less trivial, it's horrible :)
>
> And this is probably one of the reasons why newer amavis is now able to
> perform DKIM signing on it's own. So, this specific chaining should be
> historic sooner or later.
I do not agree, for a very simple reason. Amavis is a dog, and you might
want to remove it completely (depending on your setup/needs/mood). As
much as I could see, each amavis instance is taking about 80MB of RAM!
Back running sarge, it was a way smaller. I am quite stunned about the
fact that, under Lenny, running amavis + clamav + spamassassin is taking
about 6/700 MB of RAM when the server is idle. I quite don't understand
what happened between Sarge and Lenny (or even, between Etch and Lenny).
We used to run these 3 plus apache, mysql and others with just under
200MB of RAM + same amount of swap, on small footprint VMs. Currently,
512MB of RAM + same amount of swap is hardly enough.
Also, running amavis is slow, very slow. So that's the one you want to
run the last, after all other checks have been performed. To what I
could see, dkimproxy performs very well. Others reported that it ran
very well under such heavy load as 100k+ email a day (which is the type
of traffic we always should keep in mind).
> Do you have another example where such a chaining is unavoidable?
Sure. clamsmtp for example. That makes 3 software that are used as SMTP
proxies, and that could be chained. All of them would need dynamic
configuration depending what is installed on the system. And this is
only the one that I know/use. There must be more than this in the archive.
The current situation in Debian, is that not even the default incoming
and relaying ports are set correctly so the components can work
together. This is quite a real mess.
>> OF COURSE we do care about the performances of a mail server. Some ISP
>> are running servers that are managing 100s of thousands of mail a day.
>
> And of course they use distribution-default configured mail servers for
> that :) scnr.
Are you trying to say that we shall ship a not performing configuration
by default, because big ISP are capable of reconfiguring? If you are,
sorry, I don't agree.
I think we shall try to release the best distribution as we can, with
correct, performing values by default, and even, if possible, have a
default configuration that you never even need to edit, because it's
just right by default. We should at least have this goal in mind,
otherwise it slowly leads to an unusable default system, which is really
not wanted here (and which I believe is the current state of many of the
mail components in Debian, and that is the reason of my original post).
Maybe I'm being too idealistic here. What's your opinion?
Thomas
Reply to: