OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Subject: Re: Postfix snapshot 20001005 available
From: Lars Hecking (lheckingnmrc.ie)
Date: Fri Oct 06 2000 - 08:57:42 CDT

Brad Knowles writes:
> At 1:33 PM +0100 2000/10/6, Lars Hecking wrote:
>
> > AMaViS doesn't scale well. It is quite good for low-traffic sites with
> > beefy hw, but there's no way someone like an ISP could use it right now.
> > Although, the cvs version is lightyears ahead of the current amavis-perl-7
> > release in terms of resource usage, and I plan to release -8 RSN :)
>
> Please understand, my comment was not meant as a dig against
> AMaViS. Frankly, I think you've done a wonderful job under very
> difficult circumstances, but I also believe that there is a limit to
> how much you can do because of architectural issues.

 No worries, I didn't take it as such!

> Of course, if you did all your work on solid-state disk, you'd
> probably still be pretty fast even with all these limitations, but
> there's still a lot of I/O being done and forking/execing/etc... and
> context switches between various programs, etc....

 This is why amavis-perl will become the offical version in the (not
 so far) future. Compared to the shell script version, it cuts down
 tremendously on the usage of external utility programs.

Wietse Venema writes:
> Lars Hecking:
[...]
> On the other hand, if people embrace this sort of milter interface,
> then it's not a big deal to bundle a milter skeleton daemon with
> Postfix that has the same C language hooks, but you can bet that
> it would run outside of the Postfix security perimiter.

 That would be quite interesting :)

> A bit of shared library trickery and one would not even have to
> re-compile Postfix.
>
> What exactly is the problem with running a resident content scanner
> that talks SMTP? It does not have to fork for every message, so the
> cost can be reasonable.

 That's indeed my goal for amavis. The main problem is that I don't
 have an implementation yet ;-) Another problem is that I want to
 continue support for other MTAs, and the software may need some
 redesign to enable all options in an efficient manner.

 I don't even have an implementation yet that fully supports the content
 filtering interface (I have some code that does half the work, i.e. input
 from pipe and output to smtp, but this won't be in -8).