Your brain is not a computer, you are

In an article published on Aeon, Dr. Robert Epstein declared:

Your brain does not process information, retrieve knowledge or store memories. In short: your brain is not a computer

Dr. Epstein laments the emergence and pervasiveness of the IP (information processing) metaphor for the human brain; that is, that the brain operates in the way that modern computers do (though presently with vastly different capabilities). He discusses the difference between a computer’s approach (strict instructions, perfect recall) and a human’s (experiential evolution of knowledge), ultimately concluding that trying to compare a brain and a computer is a flawed undertaking.

Approaching the problem from this angle, Dr. Epstein makes a compelling argument against the ability to compare a brain and a computer directly, though there may be a mismatch in metaphors. A bit in a register and an electrical pulse in a neuron only make sense in the context of a larger system, and it’s the sophistication of that system that determines how those bits and pulses are interpreted. Computer-based systems have a long way to go before matching every level of brain sophistication.

However, when I think about the phrase “the brain is a computer”, rather than approaching the problem from the perspective of algorithms and memory, I think a more appropriate (and more interesting) comparison is with respect to inputs and outputs.

From a computer’s perspective, the concepts of “input” and “output” are straightforward. The device you’re reading this on accepts inputs (via entry points like the touchscreen, keyboard, mouse, or microphone), does *something*, then produces outputs (via exit points like the display, speakers, or vibrating motors). Regardless of what happens in the middle (that is, how the information received via the inputs is changed and turned into information produced via the outputs), the device is, in one way or another, interacting with the physical world.

Computers and humans (and all living beings really) function in a similar fashion, with varying levels of sophistication. Humans, like computers, have several ways to accept information (starting with the five senses) and one fundamental way to produce information (triggering muscles to move parts of our bodies, such as our fingers or vocal chords). The way our brains convert the input that we receive into output via muscle activity is certainly different (for now), but that system is still bookended by physical interactions.

We may be missing the point if we ask the question: “Do computers and humans represent and process information in the same way?” Computers may eventually be designed to process information in the same way as humans and they may not. Instead we should be asking: “Can computers be designed to accept inputs and produce outputs in a way that is increasingly similar to humans?” This is the goal of AI assessments like the Turing Test: to determine if an artificially intelligent system can emulate human cognition and behavior, simply evaluate whether the output it produces can be distinguished from human output.

Ultimately, if you accept that computers are physical objects that accept inputs, process them in some way, and produce outputs, your brain may not be a computer; but you are.

Better Qmail on Ubuntu – now with TLS support

On February 9th, 2016, Google announced that emails received via an insecure connection would be marked with an open red padlock, indicating that the contents of the email could be viewed while in transit. Given the attention that online security is getting these days, it’s refreshing to see that SMTP connections are finally in someone’s crosshairs.

Securing Email Systems

On the server  administration side, email-related encryption comes into play on 3 fronts:

  1. Reading email (POP/IMAP connections)
  2. Receiving email (inbound SMTP connections)
  3. Sending email (outbound SMTP connections)

Regardless of your mail system’s native support for encrypted connections, items #1 and #2 can be worked around with other packages; I’ve used stunnel and courier to secure POP/IMAP connections, and nginx’s reverse mail proxy to secure inbound SMTP connections.

However, fixing item #3 without native support for TLS is trickier – outbound connections can’t be proxied in the same way. Using a persistent secure tunnel to an external relay is possible, but that external relay would likely be a paid service like Mandrill or Sendgrid, introducing an additional layer of complexity into the architecture.

Fortunately a TLS patch for Qmail exists, so to remove the red padlock from outbound emails from my systems, I’ve added the patch to my netqmail package for Ubuntu. It’s been running in production on multiple servers for the last two months without problems, so I’m relatively confident that I’ve correctly translated the patch.

If you choose to install or upgrade to this version of netqmail, please note that there are a couple caveats. I hope to find ways to fix them in the installation, but until then, here’s what you need to know:

1. TLS is *not* enabled by default – you need to generate a private key and certificate

The OpenSSL command will prompt you for information about your system to generate your certificate. The most important item is the Common Name (CN) field: it should match the MX record that points to the server. As long as the certificate doesn’t use weak/outdated encryption, Google (and other providers) don’t seem to be penalizing self-signed certificates.

The server certificate is also symlinked to the client certificate file; the same certificate can be used to secure both inbound and outbound connections.

2. dh2048.pem and rsa2048.pem are not immediately generated

Diffie-Hellman parameters are necessary for the server side of the connection, and can either be cached or are generated on the fly when new connections are initiated. Generation of these parameters is expensive, however, and can take a long time, so normally they’re regenerated daily by a cron job. This cron job is included in the netqmail package.

Given that parameter generation takes an indeterminate and potentially long time, it’s not performed as part of the installation. Therefore, prior to these parameters being generated and cached for the first time (within 24 hours of installation), server connections may take (much) longer than normal. After installation, I recommend immediately generating these parameters:

Other Notes

The Launchpad repository now upgrades the qmail-run package as well; the overhead of TLS support increases the memory required for the SMTP server. Hence, the tcpserver softlimit has been increased.


Got all that? Great! Your Ubuntu Qmail installation is now capable of sending and receiving email securely. There are additional configuration directives that impact qmail-smtpd and qmail-remote, but the defaults should be fine for most installations.

Using Better Qmail on Ubuntu? I’d like to hear about your experiences with it in the comments.

Better Qmail on Ubuntu

I make it a goal to do as little custom configuration work as possible. No building from source, no third-party package repositories, and restricting myself to use a core, stable subset of system features when building software. Performing a package or OS upgrade only to find that some bleeding edge feature you were using has changed is frustrating at best, a lurking security hole at worst.

As a result, my preference for Qmail as a MTA may seem odd, given that Qmail is perceived as challenging to configure. However, when it comes to secure, set-and-forget software, Qmail is just about as good as it gets. It’s the Fort Knox of MTAs: highly efficient and designed to be secure. While it may appear a bit difficult to get started, once you understand the way Qmail approaches mail delivery, you’ll never go back to any of the other buggy MTAs.

But for those of us that use Ubuntu, there’s a problem. The Ubuntu package for Qmail, though stable, is somewhat outdated. It lacks several important patches such as the CNAME patch,  which simply makes DNS lookups more efficient. Why is this important? Because if you don’t apply this patch, sites with large DNS records will trigger temporary failures (“CNAME lookup failed temporarily”) until Qmail finally gives up and bounces the outgoing message. There are workarounds (editing the smtproutes configuration, in this case), but they’re tedious and require ongoing oversight.

The list of useful Qmail patches is fortunately rather short, but would require a custom build of Qmail, which in my case is unworkable. I use Puppet to configure all of my servers, so handling custom package builds becomes a more serious challenge, not to mention requiring the entire suite of build tools on the server.

With a just-in-time custom build ruled out, the best remaining option in the Ubuntu ecosystem is to create a Personal Package Archive on Launchpad, Canonical Ltd’s third-party package repository. With a PPA, I can upload my patched Qmail source package, at which point Launchpad will build and host packages that are easily imported into the Ubuntu package manager.

In the interest of simplicity, instead of modifying the original Qmail source, I followed the package manager’s convention and applied the changes as a series of patches. Some applied cleanly, without any additional modification. Others (particularly the Qmail Authentication patch) required extensive rework to accommodate changes from the other patches.

In the end, I added 6 additional patches to Qmail:

  • 0004 – Remove the CNAME lookup (per DJB himself: “It’s safe to simply skip the CNAME lookup: i.e., have dns_cname simply return 0”)
  • 0005 – Handle large DNS responses (would also have solved the above problem – I applied both since the CNAME lookup is no longer useful and is extra work)
  • 0006 – Return “Unrecognized” instead of “Unimplemented” for non-existent SMTP commands
  • 0007 – Screen for and reject email addresses with relay characters
  • 0008 – A host of inbound and outbound SMTP AUTH authentication patches
  • 0009 – Support for external recipient validation via the RCPTCHECK environmental variable

The source is on Github and the packages are built and available via Launchpad; instructions for incorporating them into your Ubuntu install are there as well. I’ve been running the new build in production on a handful of servers and haven’t experienced any problems yet. If you find one though, send a pull request on Github and send me an email. I’ll incorporate it, rebuild, and republish the package.

« Older posts

© 2021 Ryan Buterbaugh

Theme by Anders NorenUp ↑