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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bfeec27.1070...@goirand.fr