Rejecting some recipients after DATA?

Vernon Schryver
Sun Apr 21 03:02:38 UTC 2002

> From: "Brian J. Murrell" <>

> ...
> > It strikes me
> > as foolish to rely on code that has been around fewer decades than
> > sendmail and reviewed for security problems by far fewer people.=20
> Well all of that does not seem to have helped Sendmail at all.
> Obtuse' SMTPD has a couple of advantages:

I'm trying not to get into an MTA war, but can't resist one more reply.

> - it does one thing, SMTP serving; it is not trying to be the swiss
>   knife of e-mail

Off hand, I can't think of anything that sendmail does that isn't required
by people like you (intending no offense).  Regex's, filtering of all
sorts, vacation programs and delivery to other programs, LDAP, SMTP-AUTH,
SMTP-TLS, and so on and so forth are not optional.

> - it does the "dangerous" parts (receiving data from the remote) in a
>   chroot so that it does not have access to sensitive data should
>   there be an exploit in it

The big sendmail holes I recall have not involved receiving data
from the network, but delivering mail locally.  It's hard to have
a security hole while doing only the on-the-wire part of SMTP.
It's harder to do all of the fancy and strange delivery stuff
everyone demands without having gapping holes.

You must be root to use port 25 on must UNIX-like systems, and
you must some special privileges to write to users' mailboxes.
The new sendmail scheme of not using SUID and having a special
delivery program may help, but I'm too experienced to be sanguine.

> - it is small enough that it can actually be reliably audited

Have you personally audited smtpd?  
Most security audits of "replacement seucrity" software are like the
snake oil that has sold TCP wrappers for more than 10 years or the
self-important and self-deceiving advertisements for OpenBSD.
Tcpwrappers is not a bad package for what it does, but if you think
wrapping IP addressed based ACL's around an arbitrary program makes
it secure, then I have a great one-time pad unbreakable cryptographic
random number generator that I'll sell you cheap.
(In case you've not paid attention to cryptography, such a thing
is as good as the deals on the Brooklyn Bridge.)

> ...
> I disagree.  Sendmail is a behemoth and as such it's more difficult to
> audit.  Additionally it is constantly having new things "hung" onto
> it with every new feature a potential security hole just waiting to be
> exploited.

That's a problem, but which MTA doesn't suffer from freaping creaturism?
How have you avoided sendmail's serious problems by gluing smtpd in
front of it?  In my world, the security holes in a combinatino of two
programs is usually at least as large as the sum of the holes in either.

Searching on for "sendmail" is or should be
illuminating to those who honestly think that sendmail is full of
holes.  Look at the dates and which of the holes involve SMTP and
which involve delivery.

> ...
> That is because I never made claims of speed.  I know I am taking a
> performace hit using an SMTP proxy, but one I feel is necessary given
> Sendmail's history.
> ...

I think sendmail's history measured in exploits per machine-hour or
per SMTP transaction is orders of magnitude better than any of the

Vernon Schryver

P.S. Could I interest you in a constant sending address?  Each of
  your messages requires manual approval.  I'm constantly affraid
  I'll poke the wrong button and drop it.

More information about the DCC mailing list

Contact by mail or use the form.