However, more interesting were the two medium vulnerabilities, which were initially reported as DoS bugs in the libjpeg-turbo library but on further investigation were found to be issues with the JPEG standard itself. These issues were reproduced across multiple JPEG implementations, can be triggered by entirely legal JPEGs, and so are not easy to mitigate in any JPEG library itself.

You probably have encoding performance in mind, where there's much more liberty to make things very heavy.

[0]: https://www.dovecot.org [1]: https://www.dovecot.org/security.html

https://github.com/dovecot/core/blob/master/doc/securecoding...

This point makes me mad because we have both ways to statically verify that calling conditions are "correct" through the right kind of design, and it should be a zero-cost abstraction but you can't do it in C.

Plus this advice is messy when it comes to things like string escaping. This could easily lead to issues like double encoding. Issues that don't exist if you could set up "proper" type checking in C without having to use things like wrapper structs that incur performance penalties.

Defensive programming is always a bit weird because it always feels un-necessary, but in C it's really necessary because you have so few assurances. Pretty scary

I wonder if there's a tool out there that lets you use Rust-style linear types over C code, and other things that would make some of this advice redundant (because the CI server would check the code). You could still write C, but wrong C would error in the checking step.

> Plus this advice is messy when it comes to things like string escaping. This could easily lead to issues like double encoding.

That's escaping - it's not the same as validation. What they mean is that you shouldn't expect that the invariants you see right now to hold in the future. It still means that you should only escape right before the data sink that requires it. But on the other hand it means: escape it right before the data sink, even if you see that the caller only passes in 2 different static strings - it may change. Or escape even if the current filter before rejects anything apart from digits.

If you could assume escaping, that means you're limiting your input, which seems to go against the advice from my reading.

I gave escaping as an example, but one of the primary ways to reduce bugs is to reduce the scope of possible inputs as much as possible (thus reducing the scope of output to manage).

The requirements are different depending on the use case, but for application-internal code, not relying on that means that so much more global knowledge about the project is necessary to work on it. And, of course, a greater possibility of mistakes (because your requirements are more vast)

But more notably I think, a whole bunch of custom functions and data types to be used in place of more typical C coding practices. The document references a number of (presumably custom) header files (lib/buffer.h, lib/str.h, lib/strfuncs.h, lib/array.h, lib/data-stack.h, lib/mempool.h), the Boehm GC, and use of "GCC Extensions".

Also, there seems to be one person contributing an overwhelming proportion of commits (just going by the "contributors" page). Hmm, this seems to be an example of largely a single person implementing a program in C with a priority on code safety. Impressively successfully. But with substantial effort and individual discipline employed to avoid the pitfalls of C.

I'm not sure how scalable/transferable this kind of approach is. Perhaps the takeaway here is

i) This is an impressive (mostly) individual achievement.

ii) Dovecot may have some useful libraries for improving code safety if you're forced to or are committed to using C.

iii) The effort and discipline required to achieve code safety in C in this case, might also be interpreted as a validation of the effort and time required to achieve code safety by adopting newer alternatives like Rust and SaferCPlusPlus[1] when those choices are available.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

It's a great product, inside & out.

First sentence: "Dovecot is an open source IMAP and POP3 email server for Linux/UNIX-like systems, written with security primarily in mind"

But, given that dovecot just got a glowing security audit, perhaps there are other software projects that should be prioritized higher in the "rewrite everything in rust" list..

All those languages are garbage collected or use automatic reference counting. Rust is unique in using its type system to automatically allocate and free memory. For the use cases where the overhead of GC is too high - Wich are the same use cases that generally call for C or C++ these days - Rust has no competition. I think this explains why Rust is still in the explore phase.

It's hard to take Eric S. Raymond seriously. He starts by claiming to be responsible for the open source development model, continues to make some generic remarks about library quality that applies equally to many other established languages (including C), then has the gall to offer advice to the designers of a language that he is openly struggling with [1].

His arguments aren't all wrong, but it's weirdly presumptious to level them so unequivocally at a new language/community that is still finding its feet and whose adoption rate hasn't even reached the point where you can talk about library curation/fragmentation being a huge problem. One has to give Rust some slack just for being young and immature.

You also have to give Rust some slack for just being more different and complicated than the languages you are used to. If you read his previous post about Rust, it's clear that he's blaming Rust for his inability to grapple with its fairly advanced concepts, and his complaints mostly amount to knee-jerk reactions, not carefully reasoned criticisms.

While it's true that Rust doesn't offer a learning experience that's as friendly as Go, by far, Go has the benefit of having a head start of several years, a larger organization funding its development, and of being a much, much simpler language. Based on his skill level, it sounds like Go would be a better fit for him. (I use Go myself and see a huge benefit being that it's easy to learn for any developer, not just highly experienced ones.)

[1] http://esr.ibiblio.org/?p=7294

Criticizing a low-level language that makes it cheap and easy to directly call C APIs directly for not providing special syntax for select/kqueue/epoll when he could just call epoll if that's what he wants makes it clear that he wants to be writing some other, higher level language entirely.

It tells us nothing interesting about whether or not Dovecot, a project that wants low-level direct binding to POSIX APIs, is not suited for Rust.

On the one hand, the audit is a bit of a counter to "writing C is the same as writing unsafe code". On the other hand, there are a number of potential efficiency (as in, time-to-develop, maintenance effort required) gains for using a language, such as Rust, which provides the abstractions used in the C code out of the box and "for free" (in terms of implementation time--not necessarily execution performance). For a mature and stable project, especially one that has already built-in the effort to set up and maintain the appropriate abstractions, the effort to re-write is probably not worth it.

"Rewrite all the things in Rust" is asinine in general, but in this particular case it's especially bad. It would be much better to focus on C and C++ projects with actual problems.

EDIT - Answer to the budget appears to be $500k to start: https://blog.mozilla.org/blog/2016/06/09/help-make-open-sour...

That's the yearly budget for the whole Open Source Support program.

The Secure Open Source "pillar" which saycheese was asking about is just one of three (the other two being Foundational Technology and Missing Partners) which presumably split that $3 MM.

This is one more thing pushing me in that direction.

After the typical host hardening stuff (which isn't much work with modern OS defaults), I have configured SPF, DKIM, DMARC policy, opportunistic TLS for server-to-server, and mandatory TLS for IMAP client connections.

From a data privacy perspective, I know that nobody is mining the contents of my mailbox (except the messages I send to Gmail, etc. users!), and my server is not a high-value target for compromise. (Yes, DigitalOcean could snoop on my non-GPG-encrypted messages if they wanted. I guess I could migrate the server back to my own hardware.) I also encourage friends to use GPG, though this is orthogonal to one's choice of email host.

For clients I use Thunderbird on desktop and K-9 Mail on Android. Mobile push via IMAP IDLE works out of the box. (I also run a CalDAV/CardDAV server to sync contacts/calendar/todo across devices, but that is technically separate.)

Overall I'm really happy with the arrangement. The only annoyance was having my messages to Gmail users consistently marked as spam, but after doing everything suggested by mail-tester.com, I think I'm making it through most of the time.

I've been hosting my own email for about 3 years now, in an even worse-for-my-domain-reputation way: by using SRS.

Basically any email that arrives at my domain gets forwarded to my Gmail account.

And because I use SRS, it will re-write the envelope so it's something like hash-original_domain=user@mydomain.

Yet I've never had a problem with my emails getting marked as spam.

Actionable advice:

- setup DMARC and use something like dmarcian[1] so you have a pretty dashboard of your DMARC reports (otherwise you have to find some tool that will read the XML and aggregate the reports).

- use mxtoolbox to verify your IPs aren't blacklisted, you aren't an open relay, etc.

- if you have enough email traffic (not likely if you're using it for personal email only), signup for Google's Postmaster[3]

Ask if you need any help.

[1] https://dmarcian.com/

[2] http://mxtoolbox.com/

[3] https://postmaster.google.com

I know someone who does his own mail and does less than me (e.g. no SRS), and yet he doesn't have problems and thinks I'm doing something wrong...

My best hypothesis is that Google doesn't like the network that my server is in (Hetzner, various neighbours in the network are listed on a couple blacklists). When I find the time I'll set up a server with a different provider and see if it improves things. Other hypotheses are the software used (buddy uses OpenBSD and its mail server instead of Linux and QPSMTPD/Qmail+patches, perhaps they care about software headers or are doing OS fingerprinting), the fact that I'm using a fallback server on another continent (US), network timings, and plain noise (perhaps they use some kinds of machine learning that have persistent low-level irregularities).

PS. yes I'm not doing DMARC yet, but neither does my buddy.

I wonder why.

Having an honest reason to belong to a minority that is on average very dishonest is one of the worst things that can happen to you.

This is a real dilemma, not just with spam filtering.

I bet that's not the whole story. There was a reason they were lazy in the first place, but I bet there's another reason why they stay lazy. Punishing decentralization is a great way to get more users, after all: sent from gmail? works. Sent from little provider? Doesn't work.

The only way out of this I see right now is the generalization of the Freedom Box. Though even then, one would need to run protests to be able to send email from home. Between ISP wide firewalls, interdictions on home servers (by contract with some ISP), or the blacklisting of all residential IPs (Hotmail), it will take a lot of collective action before we can send mail from home again.

I very much doubt that Google sees decentralization as a major threat to Gmail at this point.

Since Snowden, people know they are being spied on. The only reason so many of them still use Gmail is because they don't know how not to. Give them a little box that's as usable as Gmail, and they will use it.

While I agree decentralization is hardly a threat to Gmail right now, it could be, and I don't see them taking any step to make it even more threatening.

Perhaps a spammer with a new server could gain Gmail's trust by passing genuine-looking correspondence, but this would stop working as soon as they start to send bulk messages.

Seems to me that tuning Gmail's filters to recognize and trust small-volume email servers would not be difficult or time-consuming.

However, I fear if Google were to try harder, spammers would also jump on that opportunity. It's easier to mimic the patterns of a small legit SMTP server than to pose as one of a few big well established email providers with known IP ranges. They could potentially use millions of compromised PCs, each sending spam in low volumes mixed with non-spam traffic.

1: http://radicale.org/

https://github.com/Kozea/Radicale/issues/266 https://github.com/Kozea/Radicale/issues/388

I'm told that using a dedicated HTTP + WSGI server solves this, just haven't done the work yet.

Moreover, systemd has a OnFailure directive that activates other units when the process exits uncleanly. Upstart has a similar directive. With a more classical approach, `respawn' is a utility that can invoke and maintain the running status of a process launched from System V Init, or you could use the regarded inittab solution.

I've seen answers to questions similar to this on StackOverflow respond with scripts that are nothing more than a while(true) loop that checks to see if a PID exists in languages ranging from Bourne shell to Python and NodeJS. This is the wrong way to do it, especially the Node one. Lets take a language intended to be used inside a web browser client and slap it onto a server to be used for process monitoring. I'm sure it does a fine job with it's while loop, but we're hitting copper pipe with a tire iron wondering why our lightbulb isn't turning on here.

Started using it after Owncloud/Nextcloud broke their ldap auth.

https://nextcloud.com

But now I might try it again some time.

If you’re lucky, the IP in question hasn’t previously been used to spam & by very slowly ramping up your email rate Google will eventually decide that you’re probably OK. Getting this right appears to be something of a black art however :(

https://news.ycombinator.com/item?id=9855030

It is certainly still valuable work to audit the software used for the mailserver. But the challenges lie elsewhere. The biggest chunks are configuration issues and - if you have users that aren't very security savvy - stolen passwords and subsequent abuse of mail accounts for spam.

This is where having a mail server with a sane configuration file comes handy. OpenSMTPd is simply awesome in that regard. Plus, it too was recently audited and vulnerabilities fixed so it should be secure.

OpenSMTPd + Dovecot makes for an awesome combination for a mail server.

I wouldn't worry too much about running many services. They all run as their own unprivileged users. (Of course chroots or even jails/containers would be better.)

I just recently set it up to use TLS on port 993. It was easy to do.

Do they have a rules checker? Are they running static analysis? Which security-related compiler flags are they enabling? Other tools they use to achieve this? Or is it just a lead developer who really groks C and security, and who reviews all PRs?

It'd be interesting to see what that other projects can learn here to improve security...

[0] https://www.dovecot.org/security.html

Beyond that, the main deliverability improvements, in approximate order of value, are: PTR record with the hostname you send mail from; DKIM; SPF; DMARC.

My mail server runs all of these, and I've yet to encounter trouble sending to anyone, including Gmail, which is often mentioned in threads like these as being a special issue. Admittedly I've been running mail from that IP since 2004, so have a long history of not being a spammer, but as long as you start out with a clean IP and keep it so, and make sure all your sender legitimacy boxes are properly checked, I don't see any reason why you should have undue difficulty.

Another option if you just don't want to deal with it, but do want to run your own mail server is to use something like MailGun which can act as an SMTP relay and will be approved by those webmail providers out of the box.

[1]: http://www.qmail.org/top.html

[2]: https://www.opensmtpd.org/

[3]: https://www.opensmtpd.org/security.html

Don't use qmail unless you really want to, as you need to patch it up a lot in any modern setting. And don't use sendmail if postfix will suffice. Exif will also do the job but there's really nothing it does better than the others.

> Mozilla sponsored Dovecot audit complete; auditor Cure53 “extremely impressed”

But you have given me an idea :)

EDIT: Doh, cannot edit. Email sent.

Dovecot audit: Mozilla sponsored complete. Auditor Cure53 “extremely impressed”

Dovecot audit complete: Mozilla sponsored auditor, Cure53 "extremely impressed"