Hacker News Reader

Comment by cenal | Hacker News Reader

Probably a dumb question but why did the world need another SMTP solution? What was OpenSMTPD supposed to do better?

It's a lot simpler to setup and configure than Postfix or qmail. It promises all the nice privilege separation of those daemons too. The appeal for me initially was that it would be small, simple, and very secure.

Could people have just improved the configuration or setup of already rock-solid qmail?

Since when has qmail been simple to setup? LOL

Let me repeat the question with highlighting on parts relevant to your reply.

"Could people have just improved the configuration or setup of already rock-solid qmail?"

improved the configuration or setup

IMPROVED the CONFIGURATION or SETUP

Do you have an answer to my question about refusal to improve an already secure and proven solution? Or do you have another strawman point ready?

I suppose that could be done, but email itself is a very complicated thing to deal with with a lot of moving parts. OpenSMTP was supposed to have a much simpler scope of operation.

Think of the configuration method as using duct tape to permanently set the switches/levers of an f1 race car instead of just getting an automatic Toyota car that is simpler for almost all people to drive.

A lot of the security and simplicity is supposed to come from not having so many options/knobs/levers of operation.

Good points. I'd say in that case I'd try to draw on the code or architecture of qmail that was beneficial while ignoring anything unnecessary. Better than trying to get the hard stuff right twice.

I think that qmail's design is based off of being super modular. So much that most people don't actually run the qmail-smtpd because it had some security issues (It's been a while but this was around the time they started work on the OpenSMTPd).

I assume 5 years later it's much improved but at the time forking the code of an SMTPd that had security vulnerabilities didn't seem like a worthwile investment and everything else has a OpenBSD prohibitive license.

Edit: It was all pretty thoroughly discussed on various mailing lists and whatnot if you're curious

Qmail's security advantage came from a number of design decisions detailed here and easy to copy in even clean-slate programs:

http://cr.yp.to/qmail/qmailsec-20071101.pdf

Far as their decision, that makes sense. I still think they should've leveraged proven design principles or tactics in the other software. I've just seen enough of these situations where I believe what you say about how their evaluation and decision process went. I figured licensing would factor into it, too.

The qmail code and configuration are both quite unlike what many people are used to. It definitely wasn't being imported with the config/service model it uses, and reworking it to be like every other daemon would involve a lot of code changes.

Appreciate another insider viewpoint. Going by this:

http://cr.yp.to/qmail/qmailsec-20071101.pdf

Do you think they could apply any of that to current project? Particularly in sections 3-5. I defer to you here as your experience is directly relevant. Would any of his approach, on top of looking for top 10 C issues, have improved the security of this app? Or was none of that applicable?

I think the approach is quite similar, but the devil's in the details. From looking at a couple bugs, the efforts to reduce TCB were not as effective as hoped.

Both postfix and qmail have quite thorough privilege separation.

Most people run Postfix out of the box (apt-get install, answer which domains you want to route mail for, done) and it's completely solid. Wietse Venema had a name for himself in security circles long before he started writing it. DJB too. Neither is likely to be the vulnerable link in your system.

And "a lot simpler" meaning A LOT simpler. It is the first mail server that I as a non-professional sysadmin could understand and configure correctly the first time using just the man page.

Reply on news.ycombinator.com