Re: [SLUG] Sendmail or Qmail?

From: Matthew Moen (mattlists@younicks.org)
Date: Thu Sep 19 2002 - 17:36:13 EDT


This rant isn't directed at you in particular Matt. I'm airing this one
as I've heard a lot about sendmail on this list, but have been biting my
tongue. Besides, the SLUG list has really been lacking in the
rant-traffic department recently. ;-)

Back in it's day, Sendmail was a great piece of software. It could
route e-mail over the internet. It could route it over phone lines via
UUCP. It could do all sorts of cool stuff. More importantly, it tried
real hard to get mail where it's supposed to go. When it couldn't, it
let you know about it. Sendmail made e-mail fairly reliable and was
better than pretty much anything else out there.

Then the Internet took off and became a nasty, cruel place.

Security really wasn't one of Sendmail's design goals. It's
configuration is far too cryptic. It gives you lots of power to do cool
stuff, but for the overwhelming majority of sites in the world, it's not
really necessary any more. The other MTA's provide most of sendmail's
features, and all the features most folks will ever need, and then some.

IMHO, good candidates for Sendmail today are sites that already have
Sendmail configured....and sites that already have Sendmail configured.
Perhaps very large organizations who want to do really weird things with
e-mail as well. Smaller sites, like home users and most Fortune 500 and
smaller companies should probably look elsewhere most of the time for
new installs. Unless of course you like pain.

/Should/ that be the case, I suggest your run sendmail as root, with BIND
on the same host...also running as root. For extra fun, install sunrpc.
A webpage which reads "Please Hack Me" is purely optional. Firewalls
you say? Bah!

If you must use sendmail, it should never be dangling out there
listening to the internet. Even if you're chrooting it, I personally
don't think it's good practice to allow punks with too much time on
their hands to potentially read corporate e-mail. IMO, it's best to
set up an SMTP proxy (that's been throughly audited, of course) in front
of your sendmail server. This practice goes doubly for those folks
unlucky enough to be administering Exchange...But /that's/ another rant. ;-)

Thus spake Matt Miller on the 19 day of the 09 month in the year 2002:

> On Thu, 2002-09-19 at 10:37, Matthew Moen wrote:
> > Sendmail runs as one huge monolithic executable. It is inherently less
> > secure than MTA's which have unprivileged processes listening to the
> > outside world performing bounds checking and then interacting with
> > actual guts of the MTA via a well-defined interface. qmail and Postfix
> > both have some incarnation of this latter behavior.
>
> While I don't disagree with your analysis, there are a couple of *musts*
> when setting up sendmail.
> A) configure relaydomains to relay only for authorized domains.
> B) use smrsh (sendmail restricted shell) to do local delivery.
> C) use the builtin or a third party plugin's ability to filter mail with
> an accepted e-mail "blacklist".
> D) Most importantly: chroot sendmail -- not only a great exercise, but
> an excellent way to secure a box and potentially your environment. I
> believe the Linux Documentation Project has excellent HowTos on
> configuring this. BIND is also a great candidate for chroot.
>
> There are a few more which I forget at the moment, but here are a couple
> more thoughts:
>
> With the introduction of macros -- the sendmail.mc file, sendmail has
> become considerably less cryptic to configure and manage. I highly
> recommend O'Reilly's sendmail -- there are some great references to
> securing and configuring sendmail.
> http://www.oreilly.com/catalog/sendmail2/
>
> I have used sendmail for years now in several environments without
> suffering any successful hacks. Patching software is the responsibility
> of a diligent Admin and should never be taken lightly -- as is keeping
> up with CERT, SANS, etc.
>
> Matt
>



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:48:52 EDT