Re: Trouble using "sendmail" w/ inetd for incoming mail

[Andy Poling <andy@realbig.com>]

On Wed, 31 Jul 1996, Brian Fisk wrote:
> > 	How about integrating tcp-wrapper into the server itself ?
> 
> All the better--it would cut down on the overhead of firing up another
> copy every time there is an incoming connection.

Sorry, but I just *have* to chime in here...

I have a history of working at sites with stellar system loads - especially
mail.  Execution performance is of paramount importance in these
environments - to the point where a significant amount of programmer time
will be spent to gain a little in execution performance because of the
tremendous number of times programs would execute.

I (and I suspect a good number of folks) use Zmailer primarily because it
offers unmatched performance under heavy load (kudos to Rayan and Matti for
sure).  I must urge you, Matti, *not* to include tcp-wrapper-like code by
default.  

Tcp-wrapper was a really good idea, but the implementation is a pig.  It
spends way too much time on disk I/O (reading the wrapper config files) for
every single connection.  I know whereof I speak on this - I liked the
concept sufficiently, and hated the implementation's execution cost
sufficiently, that I re-wrote inetd to include something similar.  I gained
back a *world* of lost performance when I switched to the inetd-based
solution.  Why?  Two reasons:

	1) saved one exec() of a program

	2) restriction info was encoded into the inetd.conf file, read at
		configuration time, and kept in memory - this was *the* big
		gain.

If you feel compelled to include this sort of functionality, I would ask
that it be optional and only enabled by a compile-time pre-processor
definition.  I don't think that many sites would find it a useful feature.
The Zmailer SMTP server was designed to be a lightweight process - let's not
ruin that.


> We use it for avariety of security reasons.  If the machine is a mail
> exploder, for example, then you only want to receive mail from a handful
> of trusted hosts. Using header information isn't very useful, because it
> can be easily forged.  It's more secure to deny service based on their IP
> address.  Rather than allowing from all and then denying certain hosts,
> you deny from all and then allow certain hosts. 

I think what you're looking for here is a packet filter.  That's the easiest
way to ensure this sort of access control, and it doesn't tie up your server
with needless disk I/O and CPU time trying to handle connections that you
have no interest in servicing.

I'm a big fan of "using the right tool for the job"...

-Andy

PS - I also wouldn't advocate spending any more effort on the sendmail
emulation binary.  It only serves 2 purposes: allow programs to send mail,
and allow *really* lazy system administrators to avoid changing their mail
startup scripts.  Adding all sorts of complexity to make it easier for lazy
system administrators just doesn't make sense to me.

(this sig left intentionally blank - too many hats for one sig)