Libraesva Email Security Gateway

How the Libra ESVA URLSand sandboxing service works

163 views September 15, 2016 August 3, 2017 rsa 1

What is the Libra ESVA URLSand sandboxing service

It is a service available on all Libra ESVA appliances starting with version 4.0. You can enable it in System -> Content Analysis -> Sandbox Filters  by checking the “Enable URI Sanbox” checkbox.

This option can be customized for each domain, which means that you can enable it for the whole appliance and disable it for some domain or keep it disabled by default and enable it only for some domain.


How it works

If the option is enabled for the recipient domain, the Libra ESVA appliance rewrites the URIs it finds inside emails so that when the final recipient clicks on the link it doesn’t go to the original URI but, instead, to the EsvaLabs URI Sanbox service.

Here is an example:

Original URI:

Rewritten URI:

When the user clicks on the link, the EsvaLabs URI Sanbox will analyze the target URI in real time by performing lookups on known malware/phishing URI lists and by actively analyzing the contents of the page looking for malicious behavior.

If the URI has recently been analyzed, the response of the Sandbox will be immediate and, if classified as “clean”, and immediate redirect is performed.

If the page has not been recently analyzed, it will be retrieved and scanned, if redirects are found the checks are repeated for all the intermediary URIs. This can take up to a few minutes depending on the number of intermediary pages and the speed of the servers serving those pages.

The user is allowed to skip the checks but warned about it, and the complete URI is shown to allow the user to decide whether to trust it or not.

If the URI is classified as “dangerous” a blocking page is displayed.

The option “I accept the risk and want to follow this dangerous link” can be disabled with the ESVA configuration flag “Do not allow users to skip URI Sandbox checks”.

If the URI is classified as “suspect” a warning page with the website screenshot preview is displayed to allow visual checks of the requested website.

The option to show suspect website preview to the user can be disabled with the ESVA configuration flag “Show preview for suspicious pages”.


We gather the absolute minimum amount of information we need to provide the service. In the rewritten URI you can see that there are only three parameters:

  • The original URI
  • A unique ID of the Libra ESVA appliance that has rewritten the URI
  • A checksum that guarantees the integrity of the data

The last two parameters are required to verify that only legit URIs are processed by the service (i.e. URIs rewritten by Libra ESVA appliances) and that the URI has not been tampered with.

The identity of the recipient of the email is not provided to the Sandbox. Of course the original URI may contain parameters that could identify the recipient, this is inevitable. For example, a URI to unsubscribe from a mailing list might contain the email address of the recipient.

The Sandbox service is accessed via HTTPS which protects the whole conversation between the user’s browser and the sandboxing service.

The Sandbox engine may forward the requested URI to external services to improve the detection.


Libra ESVA provides and maintains a list of exceptions via it’s usual update service. This list instructs the Libra ESVA appliance not to rewrite URIs that match these exception list. Only highly reliable services where no user content is available are included in such list.

The administrator of the Libra ESVA appliance can add exceptions via System -> Content Analysis -> Phishing Highlight. All URIs for the sites added as “safe” to the “Phishing Sites List” are not rewritten.

Was this helpful?