Rich Pieri <rich.pieri@prescienttech.com> wrote:
>
>Dave Sill writes:
>
>> 1) The sendmail on the system is probably out-of-date and needs to be
>> replaced with a newer, more secure version.
>
>You might want to look at a modern Unix or Unixalike. Most these days ship
>with reasonably current versions, or have patches available to make them
>current. Even Sun, formerly the biggest offender, ships with current code
>(of course, that is because Sun has been funding Erik Allman :).
Installing sendmail patches is exactly what I meant by replacing the
out-of-the-box sendmail with a newer, more secure version. And it's
Eric, with a "c".
>> 2) For serious sysadmins, the one-time effort to install a new MTA is
>> worth it if it improves performance or makes their job easier
>> overall.
>
>The fact that this argument is occouring at all disproves that claim.
What are you talking about?.
>Besides, there is no such thing as a one-time installation of a new MTA:
>sooner or later, someone will find a flaw.
That's a great example of Sendmailthink. "Of *course* the installed
sendmail is flawed and will need to be updated regularly. It's always
been that way."
qmail is different. It's not bug free, but I ran an early beta on one
machine for two years before I got around to upgrading it--not because
it didn't work, but because it was so old it worked a little
differently than the full release. There was no compelling reason to
upgrade it, I just wanted to.
I'm running 1.01 on my list server, which is a year and a half old and
two versions out of date. It works great, and I don't need any of the
new features added in 1.02 or 1.03.
>But really only a little slower when dealing with fast machines and
>networks. And it is in fact faster when dealing with machines and networks
>that would be throttled by qmail, precicely because it does not throttle
>them.
Do you have measurements to back up that claim?
>> True. But once upon a time the Majordomo+sendmail community was
>> smaller than today's Majordomo+qmail community, and somehow those
>> people were able to get the job done.
>
>Your point to this straw-man?
In what sense is that an "argument ... set up so as to be easily
refuted or defeated"?
>It is a matter of degree. qmail loses because it does not suffer as much
>scrutiny as sendmail. The *ONLY* useful gauge of security in the real
>world is scrutiny.
That's an interesting point of view.
>> This is pretty much cancelled out by the converse. Some people are
>> tired of scrambling around to fix the sendmail bug du jour.
>
>That's funny... I haven't seen much in recent years. Most of the sendmail
>8.8 patches have been minor things; the significant changes have been in
>the anti-spam arena.
Sure, it's been a while since there's been a major sendmail security
problem. That's due more to the fact that it's been a while since a
new class of security problems (e.g., buffer overruns) has been
discovered. The advantage of qmail's design is that even if a new
class of problems is identified, and in the unlikely event qmail is
vulnerable, the damage will be minimized by its compartmentalization.
Sendmail, being one, monolithic setuid root binary, will likely give
away the family jewels, as it has many times previously.
-Dave
References:
|
|
