It's an SMTP server, started just two or three years ago, written by people who care about security and hope for it to be included in OpenBSD, written in... C.

(Edit: Corrected by vezzy-fnord, started in 2009.)

The only currently-extant memory-unsafe language.

I... just... argh... when we will finally be rid of this albatross? What hope is there for the world of computer security if we can't even greenfield a solution to what has already proved to be one of the most dangerous security domains there is (thanks, sendmail) in something other than C? Why are the words "buffer overflow" appearing in relation to such young code? What am I doing with my life? Why am I even trying to write secure code in a world where this is even remotely considered an option?

I ran my own mail server using OpenSMTPD and Dovecot for a little over a year, and found OpenSMTPD to be very easy to set up and configure. I needed something light, that I could easily tweak to fit my needs. I mostly got things working reading the man files, and asking for help in the IRC channel (thanks Gilles). I also looked into Postfix, and I'm sure it's great, but the amount of configuration options were a bit daunting.

I think the project deserves more contributors and more eyes to look at the code. A fantastic foundation has been laid, but we can't expect Gilles to be able to do it all alone. This is a diamond in the making!

What worries me is the lack of updates for OpenBSD. Is those issues he's talking about are for real? I run "pkg_add -u" frequently and I don't see any updates. I'm running "stable 5.7". I understand that OpenBSD doesn't provide updates or bugfixes after release, but security updates should be pushed.

I'm casual OpenBSD user and may be I don't understand something.

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

"it threatens the OpenBSD.org frontpage security claim"

This misinformation is my only problem with the article. That claim has probably never been true. If it was, they wouldn't be regularly fixing shit that might be exploitable. Still, I came up with a way to test it years ago on Schneier's blog for anyone that wanted to try:

"Watch mailing list for bug announcements. Quickly determine if it's exploitable. If so, turn it into a payload. Hit target system. Profit." So, it's special in terms of quality focus but still can be hacked if anyone bothered to try. (Few bother.) Especially at layers below kernel that they don't care about, privilege escalation because they refuse M.A.C., in a VM because Theo doesn't worry about those issues, and covert channels because they probably never heard of them.

Note: It's reputation adds more risk as it's often used for "fire-and-forget" appliances. This can be reinterpreted as "they don't patch or they patch very rarely." The more they trust it, the more likely the bad guys get in. ;)"