Browse

Author: Anders Berggren

Meet Halon at Smau Milano 2018

Halon are going to Smau 2018 in Milan on October 23-25, with our new distributor AnswerVAD. We have had the fortune to be introduced to this big Italian event through Massimo, the CEO of AnswerVAD. This is an innovation event, and a great place to be for announcing our presence in the region. We will be in a booth together with AnswerVAD. If you are interested of going there but don’t have a ticket, don’t hesitate to contact us and we will sign you up for free. Hope to se you in Milan!

Halon 4.7 “ahoy” and 4.8 “truly” with live debugging and HELO script

Halon 4.0 introduced a feature we call “live staging” where you can deploy multiple running configurations at the same time, with per-connection conditions. It allows you to reliably rollout changes or new features to a production system for only a few testing IPs, or a select percentage of the traffic. With Halon 4.7, we proudly present “live debugging” using which you can add logpoints to your scripts. It enables you to inspect the full context of SMTP transactions in real-time, using the live staging conditions as connection selector.

Those points are added directly to the Monaco-based IDE, and results are inspected on a per-connection basis. You can create multiple points, triggered by multiple messages, and jump back and forth between them.

We’ve also added a HELO/EHLO phase script, support for ARC in DKIMSign() and a full implementation of draft 18 on Github, EdDSA (ed25519) and a native boolean type with corresponding strict comparison operator. The standard library have many new functions such as rsa_sign() and verify, idna_encode() and decode, aes_encrypt() and decrypt.

We hope that the live debugging will come handy! Please see the changelog on Github for a full list of improvements and changes, or get in touch with us if you want more detailed information.

Using ARC to work around DMARC’s forwarder issues

Authenticated Received Chain (ARC) is a proposed standard that have been developed to help address issues with DMARC and certain forwarders, such as mailing lists. It defines a standard for how to pass authentication results from one intermediary to another, making this information available to the recipient system. It works even in the case of multiple intermediaries, a.k.a. a chain.

DMARC verifies the sender authenticity, as specified by the RFC5322.From header domain name, using SPF and DKIM. Certain indirect email flows such as mailing lists break this by altering the message, while maintaining the original From header. It causes issues for both senders that publish a DMARC policy, and receivers that verify DMARC. The two large mailbox providers AOL and Yahoo published a p=reject DMARC policy for their domains in 2014, causing some disruption for senders on those domains. It occurred when emailing recipients on mailbox services that verifies DMARC via for example mailing lists. This was, and still is, remedied by ad-hoc solutions.

ARC in itself isn’t a reputation system. The specification doesn’t define how the reputation of intermediates should be tracked, nor how public lists should be operated. In other words, as a recipient mailbox provider you still have to operate such systems in order to make use of the information that ARC provides. DMARC.org announced ARC at a M3AAWG meeting in Atlanta, 2015, where it’s been a frequent topic ever since.

include "authentication.header";
include "authentication.arc";

$chain = ARC::chainValidate();
if ($chain["status"] == "pass" or $chain["status"] == "none")
{
	ARC::seal(
			"201805", "example.com", "pki:arc",
			$chain,
			AuthenticationResults()
				->SPF(["smtp.client-ip" => $senderip])
				->DKIM()
				->DMARC()
				->addMethod("arc", $chain["status"], ["header.oldest-pass" => $chain["oldestpass"] ?? "0"])
				->toString()
		);
}

 

We have just released an implementation for ARC (draft 14) on Github, which supports both verification and (re)sealing. It’s written in Halon script, and we’re using it on our own domain to start with. If you’re interested in taking it for a spin, just let us know.

Halon 4.6 “curry” with outbound anti-spam

You probably know from before that Halon’s scriptable SMTP server enable email providers to avoid blacklisting and increase deliverability. The 4.6 release, “curry”, contains Cyren’s outbound anti-spam (OAS). In combination with our cluster-synchronised rate limit function, it provides incredibly effective and accurate abuse prevention. Just like their Cyren’s inbound anti-spam, OAS uses a hash-sharing technology called recurrent pattern detection (RPD) that identifies outbreak patterns. It’s designed to detect spam from internal sources rather than external, and doesn’t report/contribute any signatures since it could blacklist your own infrastructure.

With the flexibility of scripting you can determine customer/sender identities accurately even in mixed traffic. This is used as identifier for rate limits based on classifiers such as Cyren’s OAS, delivery failure rate, queue size, etc. By using IP source hashing and alternative IPs for suspicious traffic, deferring obvious abuse and controlling connection concurrency, you can achieve high deliverability with minimal administration.

The 4.6 release comes with many additional features and improvements. It adds SNI support to the TLS functions. The Monaco-based code editor now have additional code completion, built-in documentation, tabs, and a mini-map.

For more information on the release, see the full changelog on GitHub. If you want to try Cyren’s outbound anti-spam, contact our sales team.

Halon 4.6 “funny” supporting our SMTP LANG extension

In the beginning, everything was ASCII and English. Since then, we’ve seen Unicode (international character sets) and IDN (international domains names) become widely adopted. Last year we implemented SMTPUTF8 that enables international mailboxes.

So why not support other languages in text-based protocols? We give to you “The SMTP Service Extension for Protocol Internationalization” RFC draft, introducing the EHLO keyword LANG. It will be the first SMTP software to support our to-be submitted RFC draft. Initially it will support Swedish, Spanish and Australian, and will default to Swedish when talking to supported systems.

EHLO example.com
250-LANG SE ES AU
LANG SE
250 Ok
BREV FRÅN:<>
250 Tack
BREV TILL:<hå[email protected]än.se>
250 Tack
INNEHÅLL
Subject: asdf

Hej!
.
250 Togs emot
HEJDÅ
250 Vi ses!

If you made it this far, April fool! We will publish information on the upcoming 4.6 release some time after the 1st of April.

Happy easter!

Halon 4.1 “teamy” with scripting modules

We’ve shipped the 4.1 “teamy” release, and we’re happy to see that the majority of our users have already updated. The 4.0 release brought several major changes, and 4.1 includes many improvements to it. The web administration in general, and the script editor in particular, have received lots of attention. The new live staging functionality that was introduced in 4.0 now extends to queue (pre- and post-delivery) scripts as well, using the _stageid metadata field. You can employ even more aggressive caching now that the API includes a hslCacheClear() function, and we’re opened up a wide range of possibilities via the new setBody function in the DATA script’s MIME class, such as URL rewriting.

The most anticipated addition however, is a new language feature often referred to as modules. The Halon scripting language is highly email-centric. We strive towards keeping it as simple as possible, which is a great recipe for stability and high, predictable performance. At the same time, we’re designing it after the principle of least astonishment, and consequently it shares many characteristics with established languages. Having researched both namespaces (found in languages such as C++ and PHP) and modules (found in for example Python and Perl), we decided that modules was the best fit for our language and its users. It’s great when working in larger teams, since it introduces file-wide symbol (variable and function) scoping. Modules are regular script files, which becomes modules the moment you import them. It’s similar to include, except an imported file has its own scope. You explicitly choose which symbols to “import” to the parent file using the syntax

import { Foo as X, $bar as $y } from "test";

Variables are imported by reference, hence all changes to the variable in the module will be reflected by the imported variable. As modules have their own global scope, variables referenced in a module’s function by global or closure points at the module’s scope, as per the example below

$x = "hello";
function foo($bar) {
    global $x;
    echo $x;
    $bar();
}

imported by

import { foo } from "test";
$x = "world";
echo foo(function() closure ($x) { echo $x; });

which will echo

hello
world

We hope that the modules concept will be helpful in both smaller and larger projects, and we promise that much more is to come as Halon 4.2 “classy” hits the servers.

Live staging and SMTPUTF8 coming up in Halon 4.0

Halon 4.0 a.k.a. “forty” is around the corner, and it has a strong focus on developer friendliness and deployment. Let’s take a peek on what’s about to happen!

Most of the work has gone into the SMTP server. Most notably, it now supports running two different configurations, complete with compiled scripts, in parallel. We refer to it as “live staging”, since it allows you to try out new code on a production host, for only some select traffic, based on conditions, such as IP address. We’ve also introduced a new persistent connection $context variable to all the SMTP server’s scripts, including the new MAIL FROM script, which can be used to pass data between SMTP stages or even RSETs, like

$context[$messageid][$recipient] = lookup($recipient, ...

since $messageid is regenerated with each RSET. Another major feature is SMTPUTF8, which allows for international (and emoji!) email addresses.

The scripting language itself has a new resource value type, used by the Socket() networking class which, in turn, is used to implement various extensions such as a memcached client. Another new scripting features is bitwise operators, which you can see in action by viewing the TOTP example’s code.

In addition to the live staging, management is significantly more distinct and reassuring thanks to a checkout/commit pattern, and a more expressive configuration format. As you begin to make changes, already tested using the live staging, as larger commits with descriptive messages, browsing the configuration revision history will become much more enjoyable. It also supports larger teams much better.

Halon 4.0 user interface

As usual, it’s based on the latest FreeBSD version; 11.0 in this case. It features LLVM’s LLDB, Receive Side Scaling (RSS) in some Intel network drivers, unmapped IO in Xen and VirtIO, Amazon AWS SR-IOV networking, Tx/Rx multiqueue in VMware VMXNET3, and much more.

Check out the changelog for more detailed information, and try out the new web interface at demo.halon.io!

Top 10 reads on email security 2016

It’s been an exciting year in email security and infrastructure, and the Halon team has tried to cover some of the interesting stuff we’ve come across. In case you missed any of it, these are our top posts on email, security, tech and encryption. If  you have questions around any of it, just shoot us an email!

You can also download Top 10 reads on email security 2016 as a pdf-document.

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.

To start with, an email has two sender addresses;

  1. The “envelope” address, used as return address in case the email cannot be delivered. It’s communicated between MTAs in the MAIL FROM SMTP command.
  2. The address written in the letter itself, that you see in your email app. It’s communicated as a so-called header named “From”.

Take this email for example, that our CFO Helena received a few months ago.

Spoof email sender

In Helena’s email app, it looks like an email coming from Peter, our CEO…

Screenshot spoof email

…when it in fact comes from someone else.


MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
DATA

Received: from p3plwbeout18-06.prod.phx3.secureserver.net (unknown [173.201.193.192])
by mail.halon.se (Halon) with ESMTPS
id 05170a12-7012-11e6-bc86-0050569a261d;
Mon, 23 May 2016 11:00:50 +0200 (CEST)
Received: from localhost ([173.201.193.152])
by p3plwbeout18-06.prod.phx3.secureserver.net with bizsmtp
id xl0p1s0013Hkz8V01l0p7m; Mon, 23 May 2016 02:00:49 -0700
X-SID: xl0p1s0013Hkz8V01
Received: (qmail 23080 invoked by uid 99); 23 May 2016 09:00:49 -0000
X-Originating-IP: 31.3.154.150
Message-Id: <20160523020047.47e0dcfe1d347a73e[email protected]>
From: "Peter Falck" <[email protected]>
Reply-To: "Peter Falck" <[email protected]>
To: [email protected]
(cut)

The envelope address, in this case “channelforlove.com”, is protected by a thing called SPF. It’s an over 10 years old and widely deployed standard that prevents spammers and phishermen from spoofing the envelope address. SPF was a major achievement for email, because it enabled receivers (email administrators, spam filters, whitelists, etc) to trust the envelope’s sender domain.

The from address, in this case “halon.se”, has not been possible to verify, until DMARC came along. Because it’s the address that the user see in the email app, DMARC is a great tool for helping prevent scamming attacks.

This particular scam is pretty easy to see through, because of the poor language and the reply-to address. Other scam emails can obviously be quite effective. A recent study by a cybersecurity company suggests that ransomware is a billion-dollar business.

DMARC is already widely deployed by senders that would otherwise see their domains abused by scammers, such as PayPal and Facebook. The fact that it’s backed by large, influential enterprises and based on the existing standards SPF and DKIM, has probably been a contributing factor to its success. The specification was published in 2012, and within a year 60% of consumer mailboxes were protected. Support in software is quite good, and Halon implements it since 2013, as it’s part of our open source DKIM library.

Halon recommends that you start using DMARC, to help protect yourself and others from getting scammed. Contact us, and we’ll help your organisation set it up.

Traveling from Ace to Monaco (editor)

Microsoft revealed a project called “Monaco” in November 2013 as a part of the online version of Visual Studio. A few years later, the open source Visual Studio Code editor was released, which also used it as foundation. Finally, in June 2016, Microsoft released a standalone version of the Monaco Editor on GitHub.

Amazed by its snappiness and the look ‘n feel of its diff utility, we added it to our script language‘s IDE right away, publishing a sneak peek complete with IntelliSense code completion just a few days later. You can check it out on our demo system.

We’re very happy to announce that the Monaco integration is part of our Halon 3.5-r3 release that we shipped in early August (2016). The Ace editor (by Cloud9) have served us very well during many years, and remains an important part of our product as it continues to be used in for example the “flow chart” block’s scripting area.

Finally we like to thank Alexandru Dima and everybody else who has been working on Monaco for this excellent piece of software.