Author: Anders Berggren

The DKIM replay attack, and how to mitigate

The DKIM replay attack is a way that spammers try to bypass spam filters by impersonating reputable organizations, exploiting the way that some mailbox providers use DomainKeys Identified Mail (DKIM) to build domain reputation. This can severely affect the reputation and deliverability of those organizations being impersonated. In this post we will look at DKIM replay; what it is, why it’s on the agenda, how it can be mitigated on both the sending and receiving side, and what’s happening next.

DKIM replay is nothing new. It is discussed in one section of the DKIM RFC 6376, and Word to the Wise provided recommendations back in 2014. But it looks to me as if the problem is growing. In December 2021, the privacy-focused mailbox provider ProtonMail experienced delivery problems to Gmail as a result of a DKIM replay attack, and we speak to email marketing companies that are fighting attacks more or less constantly. 

First some background. DKIM is a widely used technology to prevent email spoofing. It does so by adding a digital signature linked to the sender’s domain name, for each outgoing email message. This allows the receiver’s email server to check if an email claiming to be from a certain domain is in fact authorized by the owner of that domain name.

Email often travels in multiple hops: it is sometimes redistributed by for example mailing lists or forwarding rules. Therefore, DKIM is designed so that signed messages can be relayed (and consequently, replayed) by any server. It’s a feature of the standard. This feature is however becoming increasingly problematic, as so-called domain reputation is now playing a bigger part in large mailbox providers’ set of anti-spam measures.

What is domain reputation? Many of our readers have probably heard of IP reputation, which is the practice of keeping track of IP addresses that are distributing large volumes of spam. If an IP address is the originator of much spam, it will lead to a poor reputation, and email from that IP address is more likely to be treated as spam. Conversely, an IP address that is known to send much legitimate traffic and very little spam could have a better-than-neutral reputation, and email from that IP is unlikely to be treated as spam. Domain reputation is similar, but considering domain names instead of IP addresses. DKIM is an attractive source of domain information since it is proven by a digital signature. 

What’s the problem? The issue with DKIM and domain reputation is that the DKIM signature only guarantees that the email was once sent from the domain name owner’s server. The same email can be re-sent many times, from any source, and the signature is still valid. As mentioned above, this is a feature of DKIM, necessary for common use cases such as mailing lists to work.

DKIM replay attack. The so-called DKIM replay attack is used by spammers to bypass spam filters at popular mailbox providers known to utilize domain reputation (like Gmail). The spammer does so by sending a single spam to themselves from a provider with a good reputation, and then re-sending that DKIM-signed spam to tons of recipients using the spammer’s own infrastructure.

  1. Identify a popular mailbox provider known to use domain reputation (like
  2. Identify an email provider (let’s call it X) with a good reputation
  3. Sign up for an account at provider X, and send a single spam to yourself
  4. You will now have a spam message which is DKIM signed with X’s domain name
  5. Re-send (replay) that spam message to millions of recipients at, hoping that the good reputation of X’s domain name will result in those messages not being detected as spam
  6. If the domain reputation of X deteriorates, pause sending and wait for X’s reputation to improve before resuming sending

In several cases, the spammers sent many times the provider’s own volume worth of spam. During the Protomail incident in December 2021, the spammers sent 50 times Protonmail’s own volume at one point. 

What can be done? There are some countermeasures and good practices that can be applied by both senders (that DKIM sign) and receivers (that do domain reputation), but no silver bullet as of writing.

On the sending side, both mailbox providers (like telcos or web hosting) and senders (email marketing, ESPs) might be vulnerable, especially if they provide online sign-up. As long as user-generated email messages are DKIM signed with the organization’s domain name, there is a risk. These are some recommendations and mitigation ideas we’ve picked up:

  • Consider a separate domain for new customers if you allow unvetted sign-up.
  • Set an expiration (x=) as short as feasible to limit the time during which replay can be performed, preferably shorter for newly created or suspicious accounts. While the RFC states that the x= tag is not intended as a replay defense, it has proven an effective countermeasure. We did an analysis of the effective lifetime specified by x= for a few large ESPs and noticed that several are using lifetimes of a few days, and in some cases as little as hours or minutes.
  • Re-sign messages in the defer queue as they are being retried, as a way to reduce the expiration time (x=) further. See the example below of how to do that with Halon MTA.
  • Oversign important headers like Date, Subject, From, To, and CC to make sure that they cannot be added after being signed if they are missing from the original message.
  • Sign with the customer’s domain if possible, which is feasible for most email marketing and web hosting companies where customers bring their own domain name. Even if you also sign with your own (provider) domain, the receiver performing domain reputation is likely to use the customer domain if it aligns with the From header.
  • Add a user identity (i=) if you are unable to use a customer domain.
  • Signing the entire message and as many headers as possible to prevent the spammer from changing the message to be even more “spammy” after being signed by your server.
  • Make sure you have a DKIM rotation system in place so that you can easily rotate keys, in the unfortunate event that you need to do so quickly. That being said, the expiration time (x=) should be the primary way to control expiration.
// Re-sign deferred email as they are being retried in pre-delivery script
$mime = MailMessage::File($message["file"]["modified"]);
$dkim = $mime->signDKIM($sel, $domain, $key, ["return_header" => true]);
Try(["additional_headers" => ["DKIM-Signature: ".$dkim]]);

On the receiving side, it’s important that mailbox providers that use DKIM for domain reputation try to detect DKIM replay attacks. I think it’s fair to say that the way mailbox providers use DKIM for domain reputation is the source of the DKIM replay problem. Detecting DKIM replay attacks can be difficult, however. Identifying unusually large volumes of messages with the same signature could be part of the equation, which is also suggested by the RFC. It can be tricky however since legitimate mailing list volumes can be very large too.

I think that the DKIM replay issue highlights why industry groups like M3AAWG are very valuable. They bring organizations together to solve issues and make the internet safer, even if those organizations are competitors or have unaligned business motives. The next meeting is in London, this June. Please let us know if you are interested in collaborating!

Halon’s year in review, looking back on 2021

Image by Ian Schneider

First of all, our industry has just celebrated a great anniversary. 2021 was the year that email turned 50 years! The MIT graduate Ray Tomlinson introduced the convention of the ‘@’ symbol to identify a message recipient on a remote computer system. In October 1971, he sent the first email. Today, 50 years later, email remains the most ubiquitous form of communication, and de-facto business communication medium. Email addresses are one of very few widely used, vendor-agnostic, independent addressing schemes, together with phone numbers of physical addresses. We believe that email aligns very well with the principal design of the open internet, and we don’t really see any viable alternatives around the corner. Improving email is at the very heart of everything we do. We’re continuously working hard to make email service providers all over the world more competitive, to avoid unhealthy domination by a few.

It’s also been another year with the pandemic lingering. While we have all been doing our best to enjoy our home offices, meeting each other whenever possible, and being safe, we must highlight how much we miss meeting up with our customers and other people in the email industry. We have been lucky to meet up with a few, but we cannot stress enough how much we’re looking forward to seeing everyone in person again. However, in terms of exchanging great ideas and knowledge within the email space, we’ve been happy to participate in several virtual and hybrid events such as it-sa, Black Hat, Cloud & Cyber Security Expo, Certezza, Inbox Expo, MailCon, Cloudfest, three M3AAWG meetings, and JPAAWG.

We have also had a busy year on the development side, with a focus on supporting DevOps processes, containers, and orchestration. This can improve both speed and reliability for service deployment, especially with larger teams. This effectively makes your email infrastructure more agile. A new plugin architecture that complements Halon script allows us and our customers to employ a greater level of componentization, made convenient through Visual Studio Code extensions and new package repositories. Developing in Halon script can be made more efficient with Docker Desktop templates, and debugging Halon script running within the MTA directly from Visual Studio Code by leveraging its breakpoint interface. Communication between components is designed to work with the dynamic scaling of orchestration tools, and we now provide Docker and Kubernetes templates.

On top of that, we have released a plugin for BIMI verification. It does the heavy lifting for mailbox providers looking to show brand images in their users’ inboxes. We have also compiled Halon MTA for the ARM processor architecture, evaluating performance and feasibility to run on for example AWS Graviton.

When looking back at the year we also need to highlight our growth – and, what a year it has been in terms of welcoming new Halonites to the Halon team! We’re beyond happy to have been welcoming so many new, ambitious and knowledgeable talents. It feels fantastic to be growing and to see just how much we can accomplish together.

These are just some of the things we have been up to in 2021 and we are very happy to call this another successful year. Now, we are beyond excited for the year ahead. It will be an eventful one with lots of things planned. Already now, we have lots of open positions in engineering, marketing, and sales. So, if you are interested in joining a fast-growing tech company, we would love to hear from you.

Halon 5.8 with container orchestration

Image by Phil Roeder

The snow is deep, Christmas is just around the corner, and so is our next quarterly Halon MTA release 5.8 codename “packy”. It comes packed with improvements for both senders and mailbox providers; most notable around packaging and container orchestration readiness with for example Docker and Kubernetes.

It all starts with added componentisation aided by our new RPM and APT/deb repositories. The MTA and its different components can now be installed and scaled separately. There is no need for a 1:1 mapping between for example MTA and rate limiting or content filtering instances. Communication between components is designed to work with the dynamic scaling of Kubernetes. In order to get started quickly, we provide templates for Docker and Kubernetes. The new repositories also includes pre-compiled plugins from the extension library for quick and easy installation. This is the natural evolution of the previous release’s DevOps orchestration focus, allowing you to deploy and scale Halon MTA in a way that is just as flexible and modular as the software itself. The result is a more economical and scalable deployment that can respond to changing demands instantaneously.

Our large-scale senders will appreciate our new performance-optimised HTTP submission API. It’s ideal for injecting pre-formatted RFC822 messages directly into the end-of-DATA script hook. It’s configured just like SMTP endpoints, and accepts options in JSON format:

$ curl --request POST \
   --header "X-API-Key: badsecret" \
   --form "[email protected];type=application/json" \
   --form "[email protected];type=message/rfc822" \

Speaking of sending performance; now that DKIM signing with EdDSA (ed25519) is becoming more popular, we’ve added capabilities for faster dual signing using the additional_signatures options to signDKIM(). Halon is one of very few to offer this optimisation, which provides a significant boost for one of the most CPU-intensive parts of email delivery.

The native plugin (C ABI) system has received many additions. We’ve added APIs for creating Halon script classes/objects, throw Halon script exceptions, executing Halon script callback functions and two new functions for encoding/decoding JSON directly from Halon script variables. You can see many of those new APIs hard at work in the halon-extra extension library on Github.

As usual, the release comes with tons of other improvements. It’s now possible to configure multiple queue spool paths, which can be useful when scaling queue storage performance in certain environments. The active queue policies have received multiple updates, including a shortcut for creating lists of items (like domains) in order to avoid repetition, as well as the ability to pass properties from matching policies to the post-delivery script which is useful when creating custom backoff rules. Analysing realtime process metrics and tuning performance-related settings is now easier with the halontop command.

We hope that you will enjoy this new quarterly release. Don’t hesitate to reach out if you have any questions or want to learn more about what we do!

Discussing email encryption at JPAAWG #4

Photo by Luca Sartoni

Halon is presenting at, and sponsoring, the 4th general meeting of JPAAWG. It’s an independent regional offshoot of the global Messaging, Malware and Mobile Anti-Abuse Working Group backed by long-time M3AAWG members IIJ and TwoFive. M3AAWG is where the industry comes together to work against botnets, malware, spam, viruses, DoS attacks and other online exploitation. It’s the largest industry association, with more than 200 members worldwide, bringing together all the stakeholders in the online community in a confidential, open forum.

I will be speaking about the latest email authentication technologies together with Hackim Farrell from Proofpoint; specifically transport encryption with DANE and MTA-STS. Until recently, there was no widely deployed technology for properly protecting email communication from eavesdropping. We have been advocating for improved email encryption for a long time at conferences and industry meetings all over the globe. We’ve nudged and encouraged, and is very happy to see that there’s now 3 million email domains with DANE, and that both Microsoft and Google has enabled MTA-STS for their consumer mailbox services.

Are you interested in taking part, and happen to know one of the members? If so, I recommend reaching out and applying to attend an upcoming meeting as their guest! If not, we’re happy to guide you through the process. Don’t hesitate to contact us if you want to know more about what we do at M3AAWG, or want to talk about email in general.

Adding BIMI to your mailbox service to improve security and user experience

Image by Valimail

BIMI (Brand Indicators for Message Identification) is an emerging industry standard which attempts to drive adoption of strong email authentication, to help fight phishing, spoofing, and fraudulent emails by displaying verified brand images in the inbox. Several mailbox providers, including Gmail, AOL and Fastmail, are now live with BIMI. Are you looking to increase the security and experience for the users of your mailbox service by implementing this new standard as well? With Halon MTA, you’re ready to get started. Our BIMI module does the heavy lifting; verifying the indicators for inbound email and attaching the images to the email for display in the users’ inbox. Currently there are very few MUAs with BIMI support, but if you develop your own webmail or app the BIMI group has guidance for how to display the verified logo in your user interface.

What BIMI is, and how it works

In short, BIMI displays verified brand images in users’ inboxes, visible even before messages are opened. It builds upon the existing email authentication standards (SPF, DKIM and DMARC), and incentives email senders to embrace those technologies by increasing their brand impression. According to Agari, only 24% of Fortune 500 sending domains are authenticated. BIMI improves visibility and engagement for the brands, while at the same time increasing security for users. It roughly consists of the following steps;

  1. The brand sending the email first needs to implement email authentication (enforcing DMARC) for their domain name.
  2. The brand then creates an appropriate image of their trademarked logo, optionally applies for a Verified Mark Certificate (VMC), stores it on a HTTPS location, and points at it with a BIMI DNS record.
  3. When a BIMI-enabled mailbox service (like Gmail) receives an email from the brand to a specific recipient, the mailbox service’s MTA first verifies that the email is in fact from the sending brand using email authentication like DMARC.
  4. If the email is successfully authenticated, the mailbox service’s MTA checks if the sending brand’s domain has BIMI, and if so, verifies that logo against the VMC certificate authorities or using some other reputation system.
  5. If the brand’s BIMI logo was successfully verified, it is attached to the email (for example as a header), before the email is shipped off the recipient’s inbox.
  6. Finally, the recipient looks at her inbox using the mailbox service’s webmail or app, which displays the brand’s logo next to the address and subject in the email listing.
Getting started with BIMI validation on Halon MTA

Halon was the first commercial MTA to add support for many great new security standards such as DMARC, EdDSA DKIM (elliptic curve), DANE and MTA-STS. To our knowledge, we’re the first to add BIMI validation as well. Our BIMI validation module is only 182 lines of Halon script, which I think is pretty impressive (especially considering that it includes a basic ASN.1 parser). To get started with BIMI on Halon MTA, just check out the BIMI module to your configuration repository, add the following to your end-of-DATA script hook. The module uses some X.509 functions from the unreleased Halon MTA 5.8, please let us know if you want to try it out. As for showing the images in your webmail or app, we’re happy to provide guidance and examples.

import $calist from "bimi/ca.crt";
import { bimi, bimi_vmc } from "bimi/bimi.hsl";
import { dmarc } from "dmarc/dmarc.hsl";

$dmarc = dmarc($mail, $senderip, $senderhelo, $senderdomain);
$bimi = bimi($mail, $dmarc);

// Verified Mark Certificate (VMC)
if ($bimi["record"]["a"]) {
	$bimi_vmc = bimi_vmc($bimi, $calist);
	if ($bimi_vmc["indicator"]) {
					$bimi_vmc["indicator"])[1], "\r\n ")),
			["encode" => false]);
	} else
		echo "BIMI VMC error: $bimi_vmc; $bimi";
} else {
	if ($bimi["error"] and $bimi["class"] != "dmarc" and $bimi["class"] != "dns")
		echo "BIMI error: $bimi";

Thank you for reading, and don’t hesitate to reach out if you want to learn more!

Halon 5.7 brings DevOps to email engineering with Visual Studio Code

The Halon MTA is the most developer-friendly platform for email transport and security. With version 5.7 “catchy” we’re very happy to introduce an even better experience when using Halon together with Visual Studio Code and Docker Desktop.

Visual Studio Code is one of the most popular source code editor applications, made available for free and open source by Microsoft. It includes many features such as version control with Git, and has tons of available extensions. We have been using one of Visual Studio Code’s fundamental underpinnings, the Monaco code editor, in Halon’s web administration code editor since 2016. In 2018 we released a Visual Studio Code extension for working with both Halon script and YAML configuration files.

More and more customers embrace DevOps processes which combine version control (like Git), provisioning tools (like Chef, Puppet and Ansible) and containers (like Docker). This can improve both the speed and reliability of service development, especially with larger teams and deployments. In order to deliver the best possible experience regardless of which of those technologies our customers’ use, we’re now providing the different Halon components in smaller packages so that they can be integrated into your workflow. For example, you can now have the configuration packer and syntax highlighting in Visual Studio Code, connected to a local Docker instance running the Halon MTA and debugger. The container template enables you to set up a local development environment using Docker Desktop within minutes, complete with all MTA components.

Our extensions deliver syntax highlighting, code completion, built-in documentation, linting (static code analysis), debugging, staging and deployment. One of the most requested features is the debugger, leveraging Visual Studio Code’s breakpoint interface. It can be used on individual modules running inside the Halon script interpreter (hsh), or on a complete deployment by attaching to the MTA process (smtpd) of either a container or VM over SSH. Attaching to the MTA enables you to peek into the full connection and transaction context during not only development and staging, but also during for example troubleshooting of live traffic on production instances. Play the video below to see it in action!

What’s even more powerful is the combination of live debugging with what we call live staging; integrated blue-green testing which allows you deploy a new configuration (complete with all script and modules) for a small, select portion of traffic. It really highlights the unique capabilities which become possible because we develop the MTA, email scripting language and development environment hand-in-hand; as one product with a clear vision.

See the release notes and detailed changelog for a full list of changes. We hope that you will enjoy this new quarterly release. Don’t hesitate to contact us if you want to learn more about what we do, and how we enable email providers to build better services!

More protection with Spamhaus HBL add-on

The Halon MTA provides the widest support for threat protection vendors. It effortlessly integrates with any threat intelligence feed or content filter engine thanks to its scripting language, and we have published several ready-made integrations in our module library. We also sell a bundled license that includes spam, phishing and malware protection from Cyren and Sophos in addition to the MTA platform subscription.

Our integrated package (available as VMs or cloud images) comes with several engines installed, and we just added Spamhaus DQS. It includes support for Spamhaus’ latest developments; the hash blocklist (HBL). It’s a form of anti-virus so that you can filter additional malicious content. Using the HBL in conjunction with IP and domain blocklists, you can secure catch rates of 99.71%* and false positives as low as 0%. You can trial it free for 30 days.

In short, the HBL is a list of cryptographic hashes used to block different elements of malicious email content e.g. a cryptowallet address. Each hash forms a unique string, creating a one-off identifier for that specific piece of content, without using any personally identifiable data. Spamhaus’ HBL includes listings of compromised email addresses, malware files, and crypto wallet addresses. The malware part of the HBL acts like a type of anti-virus protection for your email stream. Typically, to identify malicious email, Spamhaus would assess the sender’s IP and/ or domain reputation. When an email account is from an ESP, like Gmail or Outlook, listings aren’t always possible, otherwise multiple users would be blocked. However, using a hash means Spamhaus can associate malicious email emitting from a specific, compromised email address.

With pioneering collection and distribution methods, Spamhaus’ researchers and engineers hash malware files, listing them in under 20 seconds after detection. By querying the Spamhaus Malware HBL, the return codes will highlight:

  1. If the file is malicious. Here, the file has been assessed by Spamhaus Malware Labs and confirmed as known malware. The return code will also provide the family of malware. 
  2. Or, if the file is suspicious: it has been observed in spam, thereby making it suspicious, though its intent is not confirmed as malicious by Malware labs. Extreme caution should still be taken when handling this file.

Another piece of content used to catch nefarious activity, when IPs and domains can’t be associated with spam, are cryptowallets. Spammers often request payment in cryptocurrencies like Bitcoin and Dash, among others, when trying to extort money from victims. Spamhaus hashes these cryptowallet addresses.  This enables email administrators to easily block the well-known ‘sextortion’ emails. You know the ones…

“I’ve hacked your account. I’ve been watching you visit adult sites. I have made a recording of you from your webcam. Send me money via my Bitcoin address 1N6dubqFmnyQ2DWvi32ppVbc3kKMTYcGW or I’ll share the recording with your contacts”.

To trial the Spamhaus blocklists, including the HBL, sign up for the Spamhaus Data Query Service (DQS). After signing up for the 30-day free trial, you will receive a DQS key. Entering this into the Halon MTA interface will get you protection with IP, Domain, and Hash blocklists. If you are already subscribing to Spamhaus’ IP and domain data, the HBL is available to you free of charge; just tick the HBL box on your Halon interface, and the rest will be done for you!

*Accurate as of March 2021. See here for the latest independent statics by Virus Bulletin.

Halon 5.6 with native plugins and Linux admin

Spring is approaching, and we’re getting ready to ship the next quarterly Halon MTA release, 5.6 “pingy”. For the first time, we’re shipping the web administration interface as separate Linux packages, making it more convenient to setup Halon clusters on Ubuntu and CentOS. This is great news for example if you’re using containers to build an elastic cluster for cost or scalability reasons.

The biggest news however is the new native plugin system, which complements Halon script and FFI. It allows you to add functions to the MTA written in any language compatible with the C library ABI (such as C++ and Go). In addition to adding your own HSL functions, it also enables you to work with the queue and delivery subsystems. Queue plugins can implement things like specific delivery times and customised IP warmup. Delivery plugins can be used to implement for example HTTP delivery to an object storage. Modules should employ the suspend/schedule pattern to avoid blocking, since the Halon MTA is event-based (uses asynchronous IO). This will be described in great detail in an upcoming blog post.

To give you an idea of how it works, consider the example below. It implements a simple sleep function in Go. The Halon_hsl_register function registers a sleep function in HSL. The sleep function itself dispatches a sleepTask, and immediately returns (suspends the script execution). Finally, sleepTask first sleeps, and then wakes the script up again (schedule).

// go build -buildmode c-shared -o sleep.go
package main

// #cgo CFLAGS: -I/opt/halon/include
// #cgo LDFLAGS: -Wl,--unresolved-symbols=ignore-all
// #include <HalonMTA.h>
import "C"
import "unsafe"
import "time"

func main() {}
func Halon_version() {
func sleepTask(hhc *C.HalonHSLContext, ret *C.HalonHSLValue, sec float64) {
    time.Sleep(time.Duration(sec * 1000.0) * time.Millisecond);
func sleep(hhc *C.HalonHSLContext, args *C.HalonHSLArguments, ret *C.HalonHSLValue) {
    var t C.double = 0;
    var arg0 = C.HalonMTA_hsl_argument_list(args, 0);
    if (arg0 != nil)
        C.HalonMTA_hsl_value_get(arg0, C.HALONMTA_HSL_TYPE_NUMBER, unsafe.Pointer(&t), nil);
    go sleepTask(hhc, ret, float64(t));
    C.HalonMTA_hsl_suspend_return(ptr); // go can’t use HalonMTA_hsl_suspend()
func Halon_hsl_register(hhrc *C.HalonHSLRegisterContext) C.bool {
    C.HalonMTA_hsl_register_function(hhrc, C.CString("sleep"), nil); // go can’t easily get the C function point of an exported method. “Nil” will make the HalonMTA_hsl_register_function use dlsym()
    return true;

As usual, the release is packed with other various improvements such as;

  • The FFI now provides the email body (MIME) and other File classes as a C-compatible FILE natively, making it easier to access to the modified email body when integrating with C libraries.
  • The integrated (virtual machine) package now includes Spamhaus DQS which provides additional functionality such as HBL.
  • Support for CSV schemas when using import so that imported CSV files get correctly typed out of the box.
  • Added In-Reply-To header to DSNs to support threaded bounces, which makes it easier and quicker to know which message is associated with what bounce.

See the release notes and detailed changelog for a full list of changes. We hope that you will enjoy this new quarterly release! If you have any questions, or are new to Halon, don’t hesitate to reach out!

Halon 5.5 with DSN extension support

Winter is here, and so is our next quarterly Halon MTA release: 5.5 codename “mappy”. It’s slang for happy on a Monday, which is quite fitting! It comes packed with new features, functions and improvements which opens up even greater possibilities for building differentiated, efficient services.

Our large-scale senders will appreciate additional tools for IP warmup, ensuring deliverability by complying with receiver guidelines. You can now choose the order by which source IPs in a pool are chosen, as opposed to load balancing between all IPs. It allows you to use one IP primarily until it exceeds the threshold for daily warmup for a certain destination. Another feature which is especially useful for senders looking at migrating their email infrastructure to cloud environments (such as AWS) is outbound PROXY support. It enables you to use the powerful HAProxy load balancer rather than NAT, when sharing IPs between MTA instances.

Do you want to leverage the DSN extension to better track email delivery? If so, you’ll appreciate our fully-scriptable RFC 3461 implementation. It allows you to quickly and easily tailor the DSN behaviour exactly to your liking.

The Halon scripting language has been extended with new data storage classes, generator functions with yield, and several new functions for encoding. The strongly-typed Map() and Set() storage classes are performance-optimised alternatives to the more generic array type. Take our revamped DMARC implementation‘s public suffix list lookup for example. It parses a data file, then storing and caching the results in a Set() for efficient lookup of the slightly complex rules:

$rules = memory_fetch("public_suffix_list.dat", function ($k) {
		$rules = Set("string");
		$file = File("file://public_suffix_list.dat");
		if (!$file)
			return false;
		while (is_string($line = $file->readline()))
			$line = str_strip($line);
			if ($line[0] == "/" or $line == "")
		memory_store("public_suffix_list.dat", $rules);
			return $rules;

The integrated (VM) package has received several requested features. First of all, the built-in web server which hosts the web administration and JSON API can now be used to also host custom PHP scripts. It allows you to create additional API endpoints, which can write files used by the Halon script during email processing. One possible use case for this is to receive requests from legal interception systems. Secondly, it is now possible to add local DNS records to the built-in Unbound DNS resolver from the web administration. It can be useful when split-horizon DNS is unavailable, and you need to override some specific DNS record. Finally, it allows you to sort the built-in history on both finished and received time. As usual, the package is based on the latest version of FreeBSD (12.2, which was released a few weeks ago) and comes with updated third-party components.

We hope that you will enjoy this new quarterly release. Please see the release notes for more information, and don’t hesitate to reach out if you have any questions!

Would you like to “like” an email?

Social media and instant messaging (such as Slack) has made reactions like “thumbs up” 👍 and other emojis popular additions to everyday communication. Wouldn’t it be nice if you could quickly press like to confirm or endorse something proposed in an email, rather than having to write a reply?

Dave Crocker, well known for his work on email standards and a senior advisor for M3AAWG, recently submitted the draft “React: Indicating Summary Reaction to a Message”. It introduces email to the world of reaction emojis using an additional email header. It could be implemented in the email clients or webmail (MUAs), and doesn’t require any changes to the transport layer. It’s however an early draft with several considerations yet to be discussed, so I wouldn’t hold my breath just yet.

So, what could it look like? I don’t know, but it didn’t stop me from creating the mockup below!