Miscellaneous

📄️ Halon configuration deployment and clustering with Ansible

Halon provides built-in configuration clustering using pre-made Ansible roles and although there are alternative approaches to managing this aspect, our usual recommendation is Ansible, particularly for users without established processes for configuration deployment and clustering. The built-in clustering provides both configuration deployment and, if needed, advanced replacement of settings using so-called "overlays" on a per-host basis.

📄️ RFC & standards compatibility

This list presents the most notable standards and RFC that Halon has implemented in regards to SMTP and MIME, and which we aim to support when applicable in order to achieve maximum interopability and compliancy.

📄️ High availability and load balancing

The Halon MTA is agnostic when it comes to strategies and infrastructure around high availability and load balancing, but does support a fair bit of techniques and standards to make it easier.

📄️ How to implement recipient filtering

Recipient filtering is a crucial part of modern e-mail filtering. All edge (fronting) mail gateways should be aware of all e-mail accounts inside the organization in order to prevent back scatter. That is not to say that you should not prevent dictionary harvesting attacks (if that is important to protect your users). Back scatter is when messages to unknown recipients aren't rejected in the edge server, so bounces (DSN) has to be generated on the backend server, which will result in "unnecessary" DSN messages being sent, and also you may be subject to sending DSN spam.

📄️ Check if the sender domain exists

It's somewhat common check if a sender domain exists before accepting mail. This check is technically backed by the standard however in practice it is prune to false-positives, so we can't fully endorse this method of anti-spam prevention. The standard argues that since mail should be transactionally safe, the return/sender address has to be valid so that non-delivered mail can be returned to the sender.

📄️ Rate limting

Rate limiting is a crucial defense method against service misuse. The Halon platform implements this in a global rate controlling service called rated. It handles rate limiting for all processes (HSL contexts), based on an "items per time interval" algorithm. Our implementation features a sliding rate limit (in contrast to leaking bucket; which has a fixed output rate regardless of exactly when the rate was exceeded).

📄️ SPF

You are probably visiting this page because a message was blocked by an instance of the Halon MTA with an SPF error along the lines of

📄️ Implement Sender Rewriting Scheme

The implementation code is available in our code repository.

📄️ Create Data Loss Prevention policies

The Halon platform features a Data Loss Prevention (DLP) engine, that you can use to comply with DLP policy requirements. Our engine operate on a level that is called "data in motion", that is on data (e-mail) that is in-transit between two endpoints (clients and/or mail servers). It features different techniques in order to detect policy violations (all covered below). Once a violation is detected, the administrator may choose an appropriate action such as quarantine, log or reject the message.

📄️ Archiving

Messages can be archived on the system's storage disk; which means a copy of the message stored in what we call a "quarantine" while still being delivered.

📄️ Responsible Disclosure

At Halon, we take security very seriously for ourselves, our clients, and the wider community. We are firm believers in responsible disclosure of vulnerabilities. If you find any security issues or flaws in our services or software we encourage you to contact us immediately. We continuously strive to improve and resolve any issues as fast as possible.

📄️ Configuration versioning

All our YAML configuration files (e.g., smtpd.yaml, smtpd-app.yaml) include a "version" property. This property ensures backward compatibility when upgrading to newer software versions. Later versions of the configuration may introduce new features, syntax changes, and/or updates to default behaviors; these changes are documented in the release notes for each version. If you use a newer software version with an older configuration file version, the specific configuration version will always maintain consistent behavior.