Browse

Tag: tech

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.

Let’s meet at M3AAWG #43 in Munich

M3AAWG meetings are an exceptional opportunity to discuss the latest in messaging security with other professionals in a focused environment of working sessions and educational panels. This time we meet in Munich, Germany. Leading industry experts, researchers and public policy officials address such diverse topics as bot mitigation practices, social networking abuse, mobile abuse and pending legislation.

As an official supporter member, we will of course participate in the Munich meeting on June 4th-7th. If you want to meet up, just get in touch!

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!

The birth of Halon’s scripting language

April 28th marks the date for Halon’s 10th anniversary and I would like to share with you the story about Halon’s scripting language, HSL. In order to understand why we created our own scripting language you have to look back at what it was intended to do, and the landscape of embeddable languages in 2007.

HSL started out as an idea of having a dynamic configuration. We wanted people to easily be able to weight the results of different anti-spam engines (Cyren’s RPD and SpamAssassin). Hence, we came up with the idea of having a simple language with functions, ScanRPD returning the spam score from the Cyren engine, and ScanSA returning the result of SpamAssassin. The configuration could look like:

if (ScanSA() > 5 and ScanRPD() > 0) Reject();
if (ScanSA() > 3 and ScanRPD() >= 50) Reject();

In order to facilitate this, we needed a simple scripting language. At the time, the intent was not to allow any general purpose programming features. We didn’t even want loops, in order to prevent runaway programs.

Creating a domain-specific scripting language

If you’re not into programming languages, I should explain that creating a simple domain-specific scripting language is easy. There are tons of guides and it doesn’t take more than a few lines until you get simple arithmetic to work (5 + 6). The hardest and most important part of creating a language is the design, also called the syntax. You want to make it as easy as possible to read and write.

Domain-specific languages are no a new phenomena, as they have existed in a lot of different applications. I believe that custom application scripting DSLs are getting less common today, as a few selected embeddable scripting language engines are getting more traction. A few years ago you would probably pick Lua to be the embedded language of choice, while nowadays JavaScript (v8) is the language everyone knows.

Why not choose an established scripting language?

Over the years, people have asked me why we developed our own language and not used e.g. Sieve, Lua or JavaScript. Here’ why:

  • Sieve (rfc3028), could technically have been an alternative, but in 2007 we hadn’t heard about Sieve. It crossed our paths a few years later. Speaking against it; Sieve was created by Mirapoint, an email gateway competitor at the time. Looking back, it was probably good that we didn’t end up using Sieve. Having our own language made our own platform evolve way beyond Sieve, and what you would expect of a traditional email gateway.
  • Lua, it just didn’t happen and I suspect that if we would have considered Lua it would had been too large and unfamiliar as a language for our initial goal. Despite the fact that arrays starts at one 😃.
  • JavaScript wasn’t just that common as an embeddable language and v8 wasn’t released at the time. And to be honest, in 2007 no one expected JavaScript to be where it is today.
Easy to learn and easy to build upon

Today we try to make HSL as familiar and easy to learn as possible, which is really important when you have a custom language. Everything we add or change is by the principle of least surprise. The language has copied a lot of syntax and good ideas from different languages. It may look a lot like PHP, it may even be mistaken for PHP, while other major concepts are from JavaScript and Python. Development of new language features are in many cases intentionally slow, as they needs to be well thought through. From a language designer perspective I would say that there isn’t much syntax in HSL that I don’t like. However we continuously add modern features. In the recent year or two, a lot of time has been put in to the language and it has gained features such as closures, classes and modules. They allow our language to be easily extendable so that you can build reusable modules on top of it. Our entire examples collection on GitHub can be imported as modules and a lot of them are written as classes.

One of the most innovating features of HSL is the cache statement as it allows you to cache the result of any function call based on the input arguments. Sure, the same functionality can be built in other ways, but having such a powerful tool so easy at hand in HSL makes it stand out. It gets really neat when you do network lookup queries, such as API lookups using http() or ldap_search().

cache [] http("http://api.example.com/v1/?param=$1", [], ["foo"]);

I personally really like the concept of custom languages, I think it’s important to try to evolve and challenge the concept of established languages, and by doing so we progress and learn from each other. I think every new language brings something new to the table; it can be a specific feature or the entire concept of why it was created in the first place.

Haven’t tried scripting in HSL yet? Download Halon and give it a go!

Halon to sponsor M3AAWG 42nd General Meeting in San Francisco

M3AAWG is the Messaging, Malware and Mobile Anti-Abuse Working Group, a trusted global forum that focuses on operational issues of internet abuse, including technology, industry collaboration and public policy. They host three general meetings per year, two in the US and one in Europe, and Halon will be one of the sponsors at this years first General Meeting in San Francisco in late February.

With over 200 members worldwide, including giants such as Apple, Google and Microsoft as well as many smaller companies, M3AAWG  is the largest global association of the industry. Companies can apply for different levels of membership, Sponsor, Full Member and Supporter. Halon became a supporter one year ago today and is represented by CTO Erik Lax and CPO Anders Berggren:

I’m very proud that we got accepted into M3AAWG. Halon is committed to help driving email transport encryption adoption, and we participate in the Special Interest Group for pervasive monitoring.

Halon 4.5 – gettin’ certy with it

The main focus in Halon 4.5 release is TLS, hence the name “certy”. Check out the the new features and functions and try them out. Also, the knowledge base is growing with a lot of good how-to’s to help you around.

TLS information has been made accessible in the Halon Platform scripting language, both on the receiving and sending side. Support for X.509 client certificates has been added, allowing you to both verify the sender identity in the SMTP server, as well as identify yourself when sending email through an SMTP client.

Experiment: we configured a busy email system to ask for a client certificate for all inbound connections, and found that approximate 5% of all traffic provides a client identity. Most of the traffic is from Gmail and Office356. We did not collect the percentage of domains, which we leave as an exercise for you.

$peercert = GetTLS();
$haspeercert = isset($peercert["peer_cert"]);
stat("peer-cert", ["yes" => $haspeercert, "no" => !$haspeercert]);

How to enable this feature and start authenticating clients was documented as KB article.

Implementation and facilitation of TLS reporting (tlsrpt) has begun. It is a new standard for reporting TLS failures, mainly focused on MTA-STS and DANE.

The TLSSocket() class now have a getpeercert() function and the ability to specify a client certificate. Now you see why we called it” certy”?

Support for custom SASL authentication mechanism has been added. This allows you to build authentication schemes such as OTP, OAUTHBEARER or CRAM-MD5, but also EXTERNAL to facilitate the client certificate features. The procedure is documented in our knowledge base along with two sample implementations.

If you haven’t found our knowledge base before, the KB is a place to find how-to’s. The dev team is expanding it as fast as we can, adding topics that customers have asked about.

Finally, I want to highlight the big effort we’ve done to simplify, modernize and overall improve the web administration. This is an ongoing project, and something that we’re paying a lot of attention to. We want to thank, and congratulate, the Bootstrap team for providing such a awesome framework. We managed to get the Bootstrap 4.0 release in, with just a few days of work.

You can read the full changelog on our GitHub of all the other features big and small.

Halon 4.4 “lofty” packed with small improvements

The 4.4 release “lofty” is all about fixing bugs, boost existing features, and improve performance and memory management in the Halon script engine. And like macOS “High Sierra”, it’s fully baked.

The unusually long changelog contains many small improvements. We’ve given the pre/post-delivery script a slight overhaul. It’s now possible to tailor the bounce behaviour via the the SetDNS() function. Additionally, we’ve added $action and $context, as well as functions to set MAIL/RCPT parameters. Finally, the SetSouceIP() enables you to choose an IPv4 and IPv6 address pair, which is a great when you want to provide customers with a private IPv4 and IPv6 or if you want to use diverse address pools.

The improved “Listen on” directive on the Server > SMTP listener page enables more fine-grained control over listen ports and IPs; such as listening on different ports for different IPs.

Quirks and fun trivia
  • We recently revised our LDAP implementation, and realised that our own syntax and mechanism for failover between hosts is rather superfluous, since OpenLDAP supports that natively. Consequently, we adopted the standard LDAP URI’s in our configuration, and existing configurations will be automatically migrated.
  • While we support the PROXY protocol (v1) that passes client source IP information from load balancers, we thought it was mostly as HAProxy thing. Apparently, it’s used by many other load balancers such as Amazon ELB, Citrix Netscaler, and F5 BIG-IP. Most of them implements the version 1 (which is human readable), but there is a second version of the protocol that’s binary-packed, and have a quite smart feature: its magic string (protocol identification) is \x0D\x0A\x0D\x0A\x00\x0D\x0A\x51\x55\x49\x54\x0A which translates into literal "\r\n\r\nQUIT\r\n", a string chosen specifically to case an error and disconnect against servers not supporting this protocol. Clever!
  • If you have a IPv6 only datacenter, but still want to process IPv4 clients, you can do so with a SIIT-DC gateway which uses IPv4-mapped-IPv6 addresses. In Halon, you can use SIIT-DC while still performing IPv4 reputation (such as DNSBL), by extracting and setting the IPv4 address in the CONNECT script. If that doesn’t make the point that we’re very scriptable, then what does?

Image from Tore Anderson’s SIIT-DC presentation

If you ever had problems signing in to a Halon using Firefox, it can be because a recent change in how “secure cookies” are handled. When signing in over HTTPS, we set the secure cookie flag, which forbids the cookie to be send over a unencrypted HTTP connection to the same host. That is all great, but if you then try to sign in over HTTP (for whatever reason) Firefox will not be able to login because there is already a cookie for that domain with the secure flag and it cannot be replaced, nor accessed. We addressed this by using different cookie names for HTTP and HTTPS. Regardless of this fix, you should not use HTTP when administering your Halon hosts.

Halon invited as speaker to ETIS Community Gathering 2017


Each year the ETIS Community Gathering brings together European telecommunication professionals to share knowledge and best practices in a trusted environment. The theme of the ETIS Community Gathering 2017 is ‘Shaping the Digital Ecosystem of the Future’.

Halon co-founder Jonas Falck will be speaking about DANE, SMTP STS and more, together with senior software engineer Erik Lax.

Erik Lax

The meeting is this year held on October 5-6 in Tallinn, Estonia. ETIS believes that Estonia, the first country to allow online voting in a general election, is a perfect place for a debate on the ‘Digital Ecosystem of the Future’, and we agree. It has the world’s fastest broadband speeds and holds the record for start-ups per person.

Its 1.3 Million citizens pay with their mobile phones, have their health records stored in the digital cloud, and file their annual tax return online in 5 min. Moreover Estonia will be holding the presidency of the EU council in the second half of 2017. Therefore ETIS invites relevant parties and start-ups to discuss lessons learned in e-Estonia.