Re: problem with Postfix port

[Theo de Raadt <deraadt@cvs.openbsd.org>]

> >People and projects learn from their mistakes, you know.  Even
> Sendmail.
> 
> Hum.  So how many CERT advisories were required before sendmail learned?

Lots.  Too many.  But Eric eventually learned, to at least some level of
"learned".

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.

Standards were raised, very significantly and very recently.

You're more than welcome to go find a new sendmail hole.  You do get
the source, right?  Really.  Or even just a simple source level bug.
But you won't, will you...

> And are you really sure that sendmail is clean now?

I'm pretty sure that sendmail is really clean inside.  I've spent
about, dunno, 30 hours perhaps, searching for new things.  I found
some bugs which I have pointed out to Eric.  Every now and then I go
back inside it and poke around a bit.  (Do you?)

> >I'd rather have sendmail then any of these new fangled MTAs touted as
> >"secure" that have never been audited or tested by fire.
> 
> Hum.  Apparently exim has never been audited,

Thomas Ptacek says he has done some snooping inside it.  From what I
heard, it sounded like it was headed towards disaster.  Thomas
believes in the same type of auditing as I do: if you can spot bugs,
there will be holes.  An experienced auditor can just look at some
code and immediately think "this code was written in a completely
careless fashion".

Thomas rather firmly gave exim two thumbs down (basically, he ran out
of thumbs).

> and postfix is too new.

> However, I'm sure that someone has tried with qmail,

Thomas Ptacek, Tim Newsham, and I spent a few evenings looking at it.

> and there are other
> MTAs as well.  There have been alternatives to sendmail for years; I
> can't believe no one has audited any of them.

I have also looked at zmailer.  Based on my past experience with "if I
can spot things which look like bugs, then there probably are bugs,
and therefore there probably are holes"... my suggestion is that
people stay away from it too.

> Personally, I think the problem of leaving sendmail has nothing to do
> with technology.  It comes down to people who like to keep the status
> quo, and people who want change as long as it's change to whatever MTA
> they're using.

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!  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.

> IMHO the right solution is to not include any MTA, and instead have a
> simple program that only handles local mail.  If you want something
> more, you can walk on fire on your own.  But the chances of that
> happening are probably less than the chances of sendmail being replaced
> with a decent MTA.

Oh give me a break.  That's just a retarded idea.

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.

Meanwhile, another way to look at that, is that you're just
encouraging people to install exim.  Like, duh.

If you don't like what we ship with, replace it.

(By the way, our development team also includes members who strongly
support sendmail.  Sometimes too vigorously on the defense side, but
heck, where are their replacements if we were to ship another MTA?
Just looking at it from that viewpoint, ie. "development support",
they've won, and all the other comments here are just rhetoric...)