HSL
The Halon Scripting Language (HSL) is the core component in the mail security (SPG/VSP) appliances for configuration of e-mail, authentication and IP flows. The language itself is divided into six different contexts: core, IP Policy, Mail Authentication, Mail Recipient, Mail Content, Mail Transport and System Authentication.
The core functions are "shared", and can be executed in any context. You can think of the other contexts (IP Policy, Mail Content, etc) as language extensions since they both add a few pre-defined variables and functions that can be used in each one of the flows. In practice, the core functions are part of the scripting library, and the contexts are implemented in the respective process: for example, the IP Policy flow process ippolicyd implements functions such as Allow() and Block(), that operates on the IP packets.
Although the syntax and function names in HSL are very much similar to PHP, Perl and C, it is important to remember that it's a completely different scripting language. There are syntax differences, and the performance characteristics of different coding styles are not comparable between the languages.
Contents |
Learning HSL
In order to master HSL you need to know the essence of the language, which is inspired by C, Perl and PHP. This includes the syntax, control structures, data types and core functions. This reference guide assumes you have some basic knowledge on computer programming. One can also learn from the "Show Script" button (the {} icon in the flow tables) which displays the script compiled from the built-in flow blocks.
- HSL language syntax
- HSL variables and data types
- HSL operators
- HSL control structures
- HSL core functions
- HSL code examples
Functions and contexts
Core functions are recognized by their lowercase names, and can be used in any flow (which maps to a script executed by a process). Most functions are indeed core functions, for reusability. Other functions which are context dependent, such as the Block() function, blocking an IP packet, have capitalized names.
Below is a table relating functions and SMTP commands to HSL contexts/extensions
| Context | Process | Description |
|---|---|---|
| Core | all processes | Global functions shared among all processes |
| IP Policy | ippolicyd | Handling IP packets, like a scripted firewall |
| Mail Authentication | mailpolicyd | Handling SMTP AUTH LOGIN (SASL) requests |
| Mail Recipient | mailpolicyd | Handling the SMTP RCPT TO command |
| Mail Content | mailscand | Handling the SMTP DATA command; in other words "the mail message" |
| Mail Transport | mailqueued | Decides what is to be done if a queued delivery fails |
| System Authentication | backend | Handling administration (SOAP API) sign-ins, suitable for RADIUS/TACACS+ integration |
IP Policy flow context
The IP Policy variables and functions are only available when creating a IP Policy flow. It operates on IP packets, and have thus only functions like Block() and Allow(). In order to produce meaningful scripts/flows, network functions from the core component can be used, such as in_network(), dns() or globalview(). The scripts are processed by ippolicyd.
Mail flow context
The mail flows are all closely tied to SMTP, as they are executed in each stage of the SMTP conversation, by different processes. The Authentication and Recipient flows are very much alike (and both part of the process mailpolicyd) but are processed in two different steps (EHLO/AUTH vs. MAIL FROM/RCPT TO). The Mail Content flow is issued when the entire e-mail is received (DATA), and processed by the mailscand process. The Mail Transport flow is issued when the outgoing SMTP transport fails to deliver a message; as a last resort. It's processed in the outgoing queue transport process; mailqueued.
