Category: Blog


Images for EC2, GCE, Azure and others

Most of our customers are hosting providers, who typically run our software bare-metal or on some hypervisor. There are however a growing number of companies in the managed service (MSP) segment that like to offer services such as email security without having to do the actual hosting. Instead, they rely on cloud computing (VPS) providers such as Google, Microsoft, Amazon or Rackspace.

A few years ago, many cloud providers offered only “PV” virtualisation, where the guest OS had to be aware of the hypervisor (and thus, customised). They required custom boot loaders, partition formats, initialisation scripts, agents and PV kernels. Because of our “full image update” method (completely overwriting the system partition from an update partition, making updates are quick and reliable), having custom images wasn’t an option. Every Halon email gateway runs the exact same software image. Consequentially, running on such services isn’t possible.

Now that most providers, even Amazon EC2, offers full “HVM” virtualisation, we decided to create public images for a few of these providers in order to make it easier to launch our software on their platforms. We currently have public images available on

and generic instructions for how to install (write the software image to the root disk) from a live CD/rescue mode on for example Rackspace.


New email gateway release 3.3 “frosty” with powerful queue scripting and transparent proxying

The release candidate of the upcoming email gateway release 3.3 (codename frosty) is currently being tested, and it’s packed with news. To start with, it’s based on FreeBSD 10.1 and compiled with clang/LLVM 3.4.1 which brings overall performance improvements. Seemingly small changes, such as the LSI MegaRAID controller (mfi, found in many servers from Dell) getting unmapped I/O, can make significant impact.

With a completed 64-bit migration which brought all users to the same code branch and database scheme, we have been able to focus on major features that required further database migrations. One example is the SetMetaData() function that enables you to;

  • Pass information between DATA and the queue scripts without having to use barriers; you might want to access for example spam score results (from DATA) when choosing source IP address in (in pre-queue)
  • Hold state in the queue between queue retries
  • Operate on the queue (using the web admin or SOAP) with search filters based on your own metadata fields; for example copying messages from an archive destined for a specific backend mail storage server that might have been restored from a backup

The metadata in combination with the system_nonlocal_source setting enables you operate the system in a much more transparent fashion; spoofing the source IP address, using the sender’s HELO hostname, setting the destination IP address according to an “X” header, and so on. Furthermore, we have published proof-of-concept instructions for how to run the system in a fully transparent mode, which might be useful when capturing SMTP traffic for all clients on a network.

Now that many computers comes with retina/HiDPI displays, we thought it was time to update all icons in the web admin to vectorised counterparts. With this came a major web interface overhaul; upping the overall experience with numerous improvements in design, layout and usability. You can take a look at our live demo system and see for yourself.

Being a major release, it also comes with hundreds of new, small features. To mention a few, there’s the syslog() function to accompany echo, raw strings, $transfertime in the post-delivery script, message size in HQL and adjustable mail_queue_threads.


Unaffected by the GHOST vulnerability

A software vulnerability in the Linux glibc library called GHOST has been discovered by Qualys, in some ways comparable to the highly critical Heartbleed. We have received a few emails from customers asking if the Halon software is affected, and the answer is no. The current release is based on FreeBSD 10, which has its own C library implementation.

We do of course encourage everyone to browse through your server inventory, updating all your affected Linux servers. Every time this happens, I’m reminded and surprised by the large number of Linux server’s that we’ve got running in the periphery.


Seamless migration to 64-bit

AMD announced what would become x86-64 in 1999, and the first CPU was shipped in 2003.

A few years later, we released the first version of our email gateway. At that time, many 1U servers and network appliances used the new “Pentium M” processor, thanks to its energy efficiency. It was 32-bit. That’s how our 10-year-long 32-bit legacy began…

A few months ago, we got tired of having to build, test and release two different binary images of each release; one 32-bit (called i386) and another 64-bit (called amd64). To see what kind of systems were out there, we added the following code to the product, to detect 64-bit CPUs (even though the CPU was running 32-bit software) and displayed a warning on the first page of the web admin, if a 32-bit CPU was detected.

bool cpu_has_64bit_support() {
        uint32_t regs[4];
        do_cpuid(0x80000000, regs);
        if (regs[0] < 0x80000001)
                return false;
        do_cpuid(0x80000001, regs);
        if (regs[3] & 0x20000000)
                return true;
        return false;

Only a handful customers got back to us, saying that they say the warning, asking what was up. Some had 64-bit CPUs, but were running virtual machines on old hosts (for example VMware ESX3) which had a per-VM setting for enabling 64-bit. Other were still running old network appliances with Pentium M, and we encouraged them to go virtual instead (as most companies today have a virtual machine environment).

Satisfied about the results, we researched the different methods for migrating all users to 64-bit. First of all, we made sure that the 32-bit FreeBSD’s first-strage boot loader (that we use for updating in our dual-partition scheme) could load a 64-bit kernel/loader, which it could, fortunately. Then, we had to decide when to convert all the machine-dependent data (PostgreSQL database, RRD, etc). We finally decided to do the migration in “one step”; doing the data conversion during boot of the 64-bit release (only one 64-bit release will contain the migration code; 3.2-r10). By shipping that specific “migration” release with 32-bit compatibility libraries and a 32-bit version of PostgreSQL and other programs, we can dump the data to SQL, XML, etc and then to an import. Once migrated, the customer need to update once more, in order to get to the latest 64-bit release. We make sure that no systems are “bricked” by doing the cpu_has_64bit_support() check in the updated program before downloading the update.

A few weeks ago, we finally released the “32-to-64-bit migration release” (in the form of 3.2-r10) on a request basis, and it will released for everyone (with a CPU that detects as 64-bit) in a week or so.


Security router 3.4 based on OpenBSD 5.6

Although not as catchy as 3.3 on 5.5, we are proud to announce the latest release 3.4 (codename “angel”) of our firewall/router side project. It’s a maintenance release that brings our codebase in sync with OpenBSD’s latest advancements, which includes

  • Added hardware support; most importantly (for a firewall) network adapters
  • Much improved filter syntax in the load balancer “relayd
  • The Unbound caching DNS server

New users can grab the full installation image, and current users updates as usual. However, because of configuration syntax changes in OpenBSD, please take an extra look at the release notes and make sure that you backup/snapshot the system before updating.

We hope you’ll enjoy this new release, and please report any hardware that you’ve successfully installed it on, so that we can update our supported hardware page.