[oal]

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!

[nickpsecurity]

I think you stumbled onto the recurring problem:

"we can't expect Gilles to be able to do it all alone"

Just like with GPG. In FOSS circles, there's all kinds of people that want to take the code but few to create it. So, people gripe about the state it's in while putting no effort in to improve it. At least the author contributes significantly. However, gotta wonder how many users it has vs how many are contributing code/audit.

Bet the difference has an impact on the situation. It's why I spend time here and there investigating proprietary, open-source models that require money or contributions to use the software. Doesn't even have be a lot: at least enough for a significant product to support at least one developer. That way the users are always investing into it and esp bug fixes happen.

[stsp]

gilles operates in a community where problems like this are taken very seriously, and where enough developer resources exist to sweep the smtp code base several times over. I expect a lot of fixes coming up over the next few weeks.

The real problem is that the OpenBSD community didn't realise the state of things internally, because gilles and eric were trusted to not fuck up. This happens, since not everybody has time to follow every corner of the tree all the time. But when focus on a particular area is needed we can do it.

It's good that Jason pointed out these problems, however the manner in which this was done creates huge public exposure which puts pressure on all of us (especially gilles and eric) to produce results very quickly while we prefer moving slowly and being careful because that produces better results in the long term.

[nickpsecurity]

To be clear, I wasn't smearing any developers or the project relative to others. Just noting a common problem in OSS development that probably hurts their project to some degree.

Appreciate you adding detail on the project's situation. Also on how you all view the post and its effects. As HN gets exposure, do you a specific, alternative approach for anyone reading that might end up Jason's shoes to get the OpenBSD team focused on a particular project and digging into it? I'm guessing he didn't make an attempt outside the public disclosure or made an ineffective one.

[stsp]

Find out who's been involved with the area of the code base recently, and mail all their @openbsd.org addresses directly in one mail.

If they don't reply after a few attempts, or give unsatisfactory answers, try mailing Theo. He acts as arbitrator in such situations.

If even that doesn't help, your last option is to write good fixes yourself, and keep submitting them as diffs to tech@ until you're either banned from posting to the list (at which point you should just give up) or your diffs end up being commited.

[nickpsecurity]

That's crystal clear: now anyone reading knows the best approach. Makes sense, too. Except that last part.

I agree it's the best option to rollup the sleeves and just fix the problem you're griping about. However, a write-up like Jason's is a valid option, too, if person doesn't have time/resources/skill for that option. Because, at that point, known issues would've been ignored by everyone up to Theo despite it being in default install and under OpenBSD's quality image. A write-up drawing attention to the issue would be justified to prevent users from placing unjustified trust in that component. Being informed lets them take action either on improving the component themselves, limiting damage it could do, or just avoiding it altogether.

Still agree that the gripe should go to the developers and Theo first.

[stsp]

But Jason did send diffs, and we are discussing his situation as an example.

Anyway, like it or not, in the OpenBSD community, working diffs, especially ones that fix a security issue, are the best way of winning an argument. You can try to blog about it but you probably won't be taken as seriously. So if you really care to convince the community from the outside and everything else has failed, and you can't code C youself, find a friend who can and ask for help.

[protomyth]

I tried OpenSMTPD / Dovecot for an environment with about 120 e-mail accounts (even promised to write it up afterwards). It just didn't quite work out. Filtering was a pain and it crashed a couple of times. I switched back to Postfix since I know its configuration pretty well.

On the other hand, as shipped, I have had no problems with it on non-mail server. I will probably try again next time I need to revise my mail server.

[sandGorgon]

what do you think about the Lamson[1]/Salmon[2] project (originally by Zed Shaw)? It seemed really cool but seemed to have fizzled out.

[1] https://github.com/zedshaw/lamson

[2] https://github.com/moggers87/salmon

[nickpsecurity]

I like the concept and some attributes of it. Some good ideas might come out of those projects. The thing I can't overemphasize here, though, is that this kind of application might be attacked or just fail in many ways. So, whatever people do, they need to keep the main functionality simple for human and/or machine analysis. Python helps with readable logic but obscures how it's actually implemented (attacker's focus). A similar project in Go might be a better idea as it's easier to see what assembler comes out of it and Go is often the replacement for Python in server apps.

Regardless, the main worry areas are parsing, protocol handling, formats, and limiting effects of any given external action on system's state. Making sure those are correct should knock out most issues. Not that it will be simple or easy. ;)