On Mon, 5 Jun 2000, mouss wrote:
> Paul D. Robertson wrote
> >
> > Historical defects would be proof, not sure how rigorous you need, but
> > it's a no-brainer in my opinion. Sendmail's design and history carry a
> > lot of baggage that doesn't have a good place in a security solution.
>
> I have no problem with this. I know sendmail's past experience.
> but I'm not convinced that "if security is needed, then sendmail
> _MUST_ be replaced with qmail".
My direction to others (when I've been in teh position to direct such) is
that sendmail _MUST_ be replaced with something better. As I stated,
qmail isn't my favorite, but it's a great deal more well-written than
sendmail from a security standpoint. I also say "You can't use the 'r'
services even internally." Statements like this have saved a great deal
of reactionary patching and clean-up over the years. YMMV.
> in other words, I am not arguing that sendmail is the best MTA,
> or that qmail is bad.
I *am* arguing that sendmail is an inappropriate MTA for a security
environment based on it's historical performance and architecture.
> If you understand it in the sense that there ar many nice guys who
> know what security is, and who still use sendmail, then that's an
> argument, unless you can prove they are wrong.
Those are many of the same people who've had to patch a fairly large
number of remote exploit holes in sendmail, so it's proven pretty well
historically. Both WZV and DJB have pointed out architectural weaknesses
in sendmail that force certain performance and permission limitations.
When I ran a large mail gateway, performance was important for not getting
DoS'd.
> In other words, to change a habit, you have to prove that it's bad,
> even if you are right.
That's the same argument that's gotten us decades of cigarette smokers :(
I'll accept "likely to be bad" or "evidence of being much more healthy"
for my security infrastructure. Your paranoia may vary.
> > It's stupid. I've *never* relied on the smap/sendmail combination, even
> > on Gauntlet.
>
> I don't like smap/smapd but the minimality of the code makes them more
> secure than direct use of the MTA, provided you don't need unsupported
> functionalities.
>
> > Anyone with a good clue who was still using smap when
> > anti-relay code became necessary probably switched to somethign else then.
>
> some guys have simply added anti-spam code.
The first cut of that supported in the community required rejected hosts
to be compiled in. It's like using a screwdriver to open a bottle of
beer, you can do it, but it wasn't designed for the task and there's a
chance you'll cut your hand, especially after a few successful openings.
> > People who were stuck not modifying installs probably stuck a different
> > MTA on the outside as the primary MX.
> >
> > I prefer Postfix to qmail, but both are easily better soltuions to
> > mail gatewaying that sendmail. Exim would probably be my third choice.
> > If you need a specific feature of sendmail, then by all means use it, but
> > if you don't, a smaller more modular MTA is preferable, most especially on
> > a firewall.
>
> there's another argument for sendmail. I know a little about it, a little
> which
> is still more than what I know of qmail. and that makes a difference. It
> makes
> me reluctant to switch unless I am convinced to do so. and, I am not yet
> convinced
> to switch.
That's your risk to take, however I think taking a risk yourself should be
different than advocating others take that risk. Back in the past eons of
time when I used to rock climb, I'd free solo on a semi-regular basis.
I'd *never* advocate and indeed actively discourage people from
climbing unprotected.
Same thing; The risk for most people simply isn't worth the cost of error
historically. Many people aren't armed with enough experience to make a
significant judgement call like that for themselves.
For the record, I'm not a qmail fan, and I jumped at the postfix alpha
because there were things I didn't like about qmail's licensing and
project methodology. That said, the quality of code is very good from a
security perspective, and I wouldn't have a problem running it if it were
my only alternative to sendmail- fortunately it isn't.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
