Tag: security

Why everybody should use DMARC to prevent phishing

Email is a major source of phishing and malware attacks. The Locky ransomware solely contributed to a 412% increase of malware emails in March compared to February, according to CYREN’s May 2016 cyberthreat report. While I believe that awareness and training is the most universally effective counter-measure, even that is really difficult, according to this recent study. We probably need a combination of training and technological advancements. One of the latter has to do with email authenticity. Can you trust an email’s sender adress? Generally no, but you can with DMARC. Read more.

What is DANE?

DANE does not only challenge the certificate authority (CA) system, but also has the potential to revolutionize email security; namely making encrypted email delivery the norm. Halon Security’s mission is to bring DANE to the world of email and to help maintain data privacy and security on a global scale.

The DNS-based Authentication of Named Entities (DANE) is a proposed standard that binds X.509 certificates to DNS names using Domain Name System Security Extensions (DNSSEC).

Even today (2016), email is being transmitted unencrypted, with very few exceptions. The fact that many servers use TLS doesn’t do much more than create a false sense of security; while it prevents passive wiretapping, the opportunistic TLS mode that is being used today doesn’t protect your email transmissions from active attacks. DANE is currently the most promising piece of technology that might change all that. Despite being (primarily) a DNSSEC-based trust scheme for X.509 certificates, it also provides the means to know if a domain supports encrypted email transfer. That last part is very important; it’s what has been missing all these years.


Public-key cryptography is a fundamental component that makes the modern Internet work the way it does. One of the most widely known encryption protocols is TLS (formerly SSL), used for web browsing, instant messaging, and much more.

Email however, despite being “the go-to form of communication in the Business world” with a constantly growing user base, hasn’t changed much over the years, and is generally not encrypted.

The state of email encryption

Before we start talking about DANE, let’s first look at the differences between transport and end-to-end encryption;

  • Transport encryption works on domain level (an organization) and protects the email transfer. It is similar to HTTPS, used when browsing secure websites.
  • End-to-end encryption works on the individual level (a person) and protects the content of the email for its entire lifetime. The two most popular standards are S/MIME and PGP, but none of them have achieved widespread adoption.

While I would certainly love to see widely deployed end-to-end email encryption in the future, having transport security in place would be a very good start. When visiting your bank’s website, it’s surely encrypted. Still, when sending them an email, the transport from your email server to theirs, likely isn’t. Why is that? Since email transfer (SMTP) supports TLS, why not use a PKI such as the CA system, like we do for the web? Unfortunately, there’s no standard defining a way for the sending server to know whether to use encryption or not. For the web, you type https://, and there’s simply no equivalent for email. Until DANE.

Introducing DANE

DANE is proposed in RFC 6698 by Hoffman and Schlyter as an alternative to CAs. The CA system has been subject to criticism during the last years, following compromise and mishaps of several major CAs. To make things worse, the revocation systems doesn’t work very well in practice. DANE builds on DNSSEC which provides a hierarchal scheme (the root, TLDs, domains and so on), as opposed to the flat CA system where any trusted CA can issue a certificate in the name of anyone.

Is the general consensus that DANE should replace CAs all together? As always there are arguments for and against. While a hierarchal system is preferable, the transfer of control and responsibility to the DNS system’s owners (governments, DNS admins) is a topic much discussion. There’s also work to improve the CA system with supplementary techniques such as key pinning and added perspective. Nevertheless, DANE stands strong to improve the security in many areas, such as email.

DANE for email

Postfix was probably the first email server to support RFC 7672 (DANE for SMTP), and Exim support is underway. The fact that those two are the most widely used SMTP servers, and the somewhat strong DNSSEC adoption, is a solid foundation for DANE. Halon’s MTA supports DANE since 3.4-rocky-r2.

Start using DANE

Most of our customers can start sending email with DANE right away, by simply changing TLS mode to dane. We recommend that you use the built-in DNS resolver Unbound with DNSSEC enabled, instead of relying on an external DNS server’s AD-bit. In the logs you can identify DANE-verified connections by

Connecting to [2001:1900:2254:206a::19:1]:25 (DNSSEC)
X.509: /OU=Domain Control Validated/OU=Gandi Standard SSL/ issued by…
DANE: validated successfully
Connection is now using TLS

If you or your customers’ domains are DNSSEC signed, you should look into receiving email with DANE as well. In theory, it’s no more difficult than publishing your SMTP servers’ certificate signatures as TLSA records in your DNS using the same name as the MX points at, but prefixed with _25._tcp, for example: IN A IN TLSA 3 0 1 2B73BB905F…

Enter Halon

We have been pioneering email security in our scriptable SMTP server for a long time; being early adopters of DMARC, DNSSEC and much more. If you’re curious, go ahead and download the software from our website.

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.

Considerations regarding DMARC forensic reports

DMARC is a great step forward for email, as it finally enables us to trust an email’s From address.

Because of the way that most mailing lists are currently implemented, we believe that email receivers who implement DMARC verification (mail hosting companies in particular) should avoid sending forensic DMARC reports (ruf=).

The problem can be replicated by

  1. Someone requests to have forensic reports sent to their domain (adding DMARC with ruf=)
  2. He then sends a message to a mailing list
  3. The message is distributed to all subscribers
  4. The subscribers’ mail servers might respond with a forensic report
  5. The report contains the subscriber’s address

This results in information leakage. Lets say somebody is subscribed to a mailing list without participating, believing that his membership isn’t easily disclosed. Therefore, as of today, you probably don’t want to enable the sending of forensic reports when implementing DMARC verification. This is what a forensic report could contain:

Received: from (localhost [])
	by with ESMTP id ...
	for <SUBSCRIBERS-MAIL-ADDRESS>; Fri, 13 Dec 2013 09:02:45 -0700 (MST)

Are we disclosing a vulnerability? No. The mailing list problem is well understood and discussed by the DMARC community. For example, most DMARC adopters don’t send forensic reports for various reasons. Also, because mailing lists typically violates the DMARC policy, there’s an ongoing effort to change mailing list software so that these issues are resolved. The purpose of this article is simply to raise awareness among potential DMARC adopters, such as mail hosting providers. The concept of forensic reports is powerful, but you need to be aware of this issue.

During some testing that we did, we found a few major hosting companies that did send forensic reports on their user’s behalf, thus leaking information about their users’ mailing list subscriptions.

Anyway, please start using DMARC, for everyone’s sake.

  • As for verification and sending reports;
    • Everyone should enable DMARC verification
    • High volume hosting companies in particular should contribute by sending aggregated reports
  • As for signing and receiving reports;
    • Most organisations could benefit from activating DMARC in monitoring mode (p=none, rua=mailto:…)
    • Organisations which identity is subject to spoofing such as phishing (institutional domains, banks, web services) should enable DMARC fully (p=reject)
    • Never-sending domains (which aren’t used to send mail) should enable DMARC (p=reject)

Sending aggregated reports from a Halon system

Building upon our library libdkim++ we had one of the first on-premise e-mail security products with DMARC validation. It’s however important that mail servers (high volume receivers, such as hosting providers, in particular) contribute by sending validation reports.

Instead of re-inventing the wheel, we’ve evaluated OpenDMARC‘s reporting tool. We’ve been using it for some time, and decided to write an integration script which you can download from GitHub. The installation is pretty straight forward by following our guide; which boils down to aggregating logs using remote syslog, and process/report them daily using logrotate.

Why should you start sending reports? Well, first of all it’s one of DMARC’s strengths (which is reflected in in’s name; Domain-based Message Authentication, Reporting and Conformance). For example, reporting is crucial for DMARC’s “monitoring mode”, which is helpful as a first step of deploying DMARC. Further, it enables senders to analyse what’s spoofed in their name. As quoted from;

DMARC addresses these issues, helping email senders and receivers work together to better secure emails, protecting users and brands from painfully costly abuse.

We encourage all our high-volume customers to evaluate DMARC reporting. Feel free to contact us if you have any questions!

Halon released with DNSSEC root trust

Today, on the 2nd of September we release Neat, right?

Among the new features you’ll find the DNSSEC trusting the newly signed root anchor, administration user interface improvements and the usual stability and performance enhancements.

Now why would you care? Well, this could be your first step into the next generation of e-mail security. Why not start DKIM tagging when you’re at it?

There are small, yet useful features are well. Let’s say you want to implement a reporting rate control in your outgoing recipient flow, so that users or servers doesn’t send outgoing spam. In this example, we do this per-username ($saslusername, a pre-defined variable in the recipient flow) limiting the number of e-mail to 100 every hour, while sending at most one warning e-mail to the administrator about this every day and per user.

function myrate {
  if (rate("outbound", $saslusername, 100, 3600) == false) {
    $msg = "Rate "+$saslusername+" spam outbreak";
    if (rate("outbound-report", $saslusername, 1, 86400) == true) {
      mail("[email protected]", "[email protected]", "Rate", $msg);

and then using it in code like

if ($saslauthed) {

Take care folks!