[CentOS] Re: Kind of OT: internal imap server

Thu Aug 31 12:56:13 UTC 2006
Les Mikesell <lesmikesell at gmail.com>

On Wed, 2006-08-30 at 22:18, Feizhou wrote:
> > The problem is that MTA's typically have to mesh with a lot of other
> > tools, so you'll see people raving about one vs. the other because of
> > some almost-unrelated management wrapper or it's ability to do
> > SMTP AUTH against some oddball password database.  Also, if you are
> > looking for long experience, sendmail is pretty much the only one that
> > has been around for what I'd call a long time - but you can't really
> > compare its capabilities before the milter interface stabilized with
> > the current version.   A lot of people got things working with qmail
> > or postfix and haven't looked at the new capabilities of sendmail with
> > MimeDefang as a milter.
> > 
> 
> maybe because they don't like the idea of perl as an inbetween. how 
> large are your sendmail processes?

Sendmail chats on sockets with the milter process and thus
doesn't become any larger.  And the milters can be written
in any language.  Mimedefang uses a combination of C and
perl.  If you are going to run spamassassin you are stuck
with perl regardless and that's going to be your slow step
anyway so you might as well have it pre-loaded and use it
as the parser for your control steps.

> sendmail's fork a process per connection + perl in some situations make 
> people have nightmares whereas the same could be done in a much more 
> efficient manner especially with postfix. 

Like I said, most people don't bother to understand how it
currently works.  Sendmail runs one milter process which
all the sendmail processes use via socket connections. In
MimeDefang's case the controlling milter is written in C
and runs multi-threaded, multiplexing connections to some
small number of slaves that do the work in single-threaded
perl.  There is no extra fork per sendmail involved and
a much smaller number of perl processes than sendmails.
Also, the multiplexer manages the slave processes by
restarting them if they crash or exceed memory limits
and will inform sendmail to retry on timeouts.

Any way you look at it, it is a much nicer design than
making the receiving process handle everything itself
or fork additional processes per message or run.

> most probably won't think of 
> mysql as an oddball password database. Maybe a cdb one.

If you are used to having normal users on a unix-like
system you would.

> sendmail + mimedefang is overrated. Now that postfix 2.3 is the stable 
> line now...postfix + mimedefang will probably be interesting depending 
> on how it is done...

We can pick up the discussion when/if some large volume users
equivalent to those on the MimeDefang list start using it.  A
big value in using existing, working software is that you can
take advantage of other's previous experience with it.

-- 
  Les Mikesell
   lesmikesell at gmail.com