[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problem with Postfix port



On Fri, 25 Dec 1998, Theo de Raadt wrote:

> To be honest, you are forgetting your history.  Until very recently,
> very few people cared all that much about security, or knew how to
> write secure code at all.  Show me any code more than 2 years ago, and
> it HAS MULTIPLE HOLES.

Ok, I'll grant you that.  However, I also remember a period where it
seemed we were doing the sendmail of the week.  That sort of thing really
eroded my confidence in the product.
 
> > However, I'm sure that someone has tried with qmail,
> 
> Thomas Ptacek, Tim Newsham, and I spent a few evenings looking at it.

And besides the usual complaints about the "unique" coding style, did you
have any other observations?
 
> No.  It has to do with a lot of things.  In this particular case,
> qmail is not a drop-in replacement.  It does some things that people
> are very used to doing very very badly.  It doesn't "fit" into our
> system trivially.  And it has other issues.  Trust me -- I looked into
> it before!

Dan has done a lot of things recently to make qmail fit much better, like
.forward support, delivery to /var/mail (via mail.local), and /etc/aliases
support.  It has been a long time since I have converted a
well-established sendmail system to qmail (I did ours long before these
new features were available) so I don't know if it is any closer to being
a drop-in replacement.

While I would personally love to see qmail ship with OpenBSD, I know that
it is not suited to everyone.  For example, it doesn't natively do UUCP,
and the standard delivery mode will kill dialup connections (neither are a
problem for more advanced users).  That's why I never asked why qmail
wasn't the default MTA :-)

> That said, all of the alternative mailers do.  They're so
> concerned about making it easy for admins to replace sendmail, that
> they've completely forgotten to touch onto the issues of correct and
> complete default integration.  I don't want to pick on anyone here,
> but if they don't meet the status quo of how sendmail fits in, they're
> not going to be viable drop-in replacements, in this source tree,
> anytime soon.

That's not entirely fair to at least one of the MTAs you're picking on,
because it was specifically designed not to fit in :-)

Most MTAs were not designed with security in mind, period.  sendmail was
out first, and by far is the most widely used.  So its problems got fixed.
If anyone cares enough, the problems in other MTAs will get fixed as well,
and then it comes down to sendmail still being a bloated pig.

> Apparently you don't know a thing about how OpenBSD tries to be secure.
> We do so by supplying people with things which work together, and we
> make those things work together in a single unified source tree.  As
> soon as you add stupid variables like the above, many of those rules
> walk away.

Sure, but you're including a product that, while you may think is now
secure, many people avoid like the plague, and it's entirely unsuited to
systems of any large scale.  So the people who probably need your help the
most have to replace sendmail anyway, and if they don't like qmail then
they are going to pick one of the others that is full of bugs if not
holes.  I don't think I've ever seen so much anticipation for the release
of a new UNIX app as postfix; I think that says a lot about what people
think about sendmail.
 
> Meanwhile, another way to look at that, is that you're just
> encouraging people to install exim.  Like, duh.

IMHO, leaving sendmail in the base system is what encourages people to
install exim.  If the base system included something that wasn't
poisonned, had a config file a normal person could figure out and could
manage delivering a 50k user mailing list in a reasonable time without
draining every last bit of juice from a system, then we wouldn't be having
this conversatiion :-)

Evan