Daniel Bernstein: ten years of qmail security

FWIW, I didn't mean 'built on Apache' as in 'runs as part of an Apache HTTPD'; Apache is in
part a very nice framework for writing generic server apps these days.  (Maybe this is
technically part of APR, I haven't followed where exactly they're drawing that boundary.)

On a further look, though, I see that you're right, when qpsmtpd is not running under httpd,
it uses a different home-brew network framework rather than APR.  I was misled by looking at
the first anti-malware plugin linked on their homepage:
  http://svn.perl.org/qpsmtpd/trunk/plugins/check_earlytalker
which contains a bunch of code using APR -- but it turns out that's because there are two
copies of all that code, one that works when being run under Apache and one that works with
the home-brew.  I don't know how typical this is of qpsmtpd's codebase, but it doesn't strike
me as The DJB Way either.

(If I were them, I'd consider just using Apache in all cases, even if it is a big hunk of
scary C that makes baby DJB cry, but I don't actually know what I'm talking about so *shrug*.)

Interestingly, djb's paper talks about maintaining security expectations even in the face of
having to run untrusted, random codebases as part of secure application.

The basic idea is compartmentalization: for each component (especially those from a third
party) you should clearly define the input, the output, and set up access and resources
restrictions in which the component must operate. Finally, after it does its job, you
shouldn't trust it but do some validation to check the sanity of the result.

For instance, if the purpose of the component were to extract recipient address of the email,
then the component can only read the email, produce one string as response, not access
anything outside that email and have to run in limited time and memory. Once something comes
out, it must look like an email, for instance match the famous rfc822 pattern.

To achieve this, one might have to run untrusted components under a virtual machine and/or use
the operating system's primitives to constraint cpu, memory, available system calls, etc. I'm
not sure how well Linux can do these things, but the basic idea is that it should be possible
to run even completely random code safely provided that these relatively simple constraints
are worked out first.