Sun Apr 21 03:02:38 UTC 2002
> From: "Brian J. Murrell" <firstname.lastname@example.org> > ... > > 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 http://www.cert.org 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 alternatives. Vernon Schryver email@example.com 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