Service settings

EAS (https://eas.retarus.com) - Administration - Email Services
General settings for the Retarus Email Security services can be configured here.

Overview tab with system parameters

EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Overview

This tab contains information about the general system parameters, including the number of active virus scanners, the number of domains you protect, and how many are configurable by you. In addition, you can also opt to save your external email communications in the Retarus Enterprise Email Archive.

Settings for time zone and language

EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Customer Settings

At the very top of the Settings menu, you will find options for setting the time zone and languages. Retarus Email Security uses different types of notification emails, so you can specify the language of the messages and the time zone used to determine the send time.

If you define these settings company-wide, the Customer settings menu appears in the header. If you set these options at the Profile level, you will see a note above the time zone informing you of the name of the profile currently undergoing configuration.

AntiSpam Management (Inbound) & quarantine settings

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - AntiSpam Management

EAS portal
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Spam thresholds/Quarantine

Here, you may adjust all settings related to Retarus AntiSpam Management and the email quarantine.

Available settings:

• Spam emails – Tag and deliver
  We recommend using tagging (=subject marking with a prefix) for messages with low spam probability. Newsletters are an example of a type of message that could be tagged. Although not necessarily unwanted, they should be differentiated visually from business-relevant messages. Emails with a subject marking are delivered to the recipient as usual. However, the recipient has the opportunity to set email rules for subject marking using a consistent subject prefix, allowing delivery of these messages to a specific folder. This enables the recipient to keep their email inbox organized and optimizes the processing of emails.
  The default subject prefix is [RMX:###]. Depending on the spam probability calculated by the Retarus AntiSpam engine, an email additionally receives a specific number of # characters behind the marking. You may define an individual subject marking as well. Here, %%% may be used as a variable, which will be replaced by the actual spam probability in %. ### may be used as a variable as well; it will be replaced by a specific number of # characters, depending on the actual spam percentage.

• Spam emails – Quarantine
  In addition to or instead of marking the subject, you can set up a quarantine for email messages suspected of being spam. If the calculated spam probability exceeds the configured threshold, emails are sent to the recipient’s email quarantine. The Retarus Email Security Report (digest) informs the user about his quarantined emails. The expiry period of quarantined emails may only be configured by Retarus.

• Spam emails – Discard
  A third option for dealing with messages suspected of being spam is to delete them directly. In order to be able to use this option, a special agreement with Retarus is required. If this option is activated, all messages exceeding the defined spam probability are deleted directly. Neither the sender nor the recipient receives a notification. Deleted emails also do not appear in the user digest. Discarded emails cannot be restored.

• Newsletters – Quarantine
  Although they are not per se spam, newsletters and other marketing mails may be unwanted; therefore, you have the option of quarantining them (classification “Newsletter”). If the newsletters have been transferred to the quarantine, the user will periodically be notified about them via the digest.

• Newsletters – Tag subject
  Instead of quarantining newsletters, you may also tag the subject and deliver the emails. Recipients can use the marking to apply their own sorting and controls to these messages to maintain a “clean” inbox.

• Senders on Blocklist – Discard emails
  By enabling this option, emails from senders appearing on your blocklist – regardless of whether it’s the user-specific or company-wide blocklist – are deleted automatically. Neither the sender nor the recipient receives a notification about the deletion. This option is only available if a deletion agreement is in place with Retarus.

• Senders on Allowlist – Check emails for spam
  If this option is deactivated, emails from senders on your allowlist (company-wide or user-specific) are not checked for spam at all; otherwise, they are still checked for spam. It is advisable to activate this option to avoid spam from known senders. In this case, you may configure the spam probability (percentage) from which on emails from a sender included in the allowlist will be quarantined.

• Senders on Allowlist – Tag subject
  If enabled, a prefix is added to the subject of received emails from senders on an allowlist – regardless of whether it’s the user-specific or company-wide allowlist. This signifies that the message was sent by a trustworthy sender. If you use the default setting, [RMX:AL] is placed in front of the original subject. You may alternatively define an individual marking. Please note that the variables ### and %%% are not working here.

• User AntiSpam Block-/Allowlist
  If enabled, end users are allowed to manage a personal AntiSpam Block- and Allowlist.

• Ignore envelope-from address
  By default, all sender fields of an email are checked against the addresses/domains on your AntiSpam Block- and Allowlist (company-wide or user-specific). This option allows you to have the SMTP-From (Envelope-From) address ignored for blocklist and allowlist checks.

• Ignore MIME-from address
  If enabled, MIME-From address will be ignored for blocklist and allowlist check.

• Ignore reply-to address
  If enabled, reply-to address will be ignored for blocklist and allowlist check.

• Activate Bad Word Filter
  If enabled, emails containing objectionable content (list of keywords maintained by Retarus) are quarantined, but not viewable by users in their personal online quarantine and not listed in the Email Security Report (digest).

Quarantine management settings

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - Quarantine Management

Here, you may configure if your users are allowed to download emails (including attachments) from their quarantine. Important: This functionality is not compatible with Retarus Large Email Handling, as the recipient won’t be able to download attachments received and moved to quarantine due to large attachments if this option is enabled.

AntiSpam Management (Outbound)

It is possible to have also outgoing (Outbound) emails checked for spam. If this feature is activated, emails exceeding a configurable spam probability (percentage) are either rejected, tempfailed or discarded silently – depending on your configuration (default threshold = 90%). An Outbound quarantine option does not exist.

The feature may be configured on all hierarchy levels (customer, domain, profile, user).

If you would like to have the AntiSpam Detection Outbound activated, please refer to Retarus Support, as this is not possible via the myEAS portal at the moment.

Attachment Blocker (Inbound)

Description

The Attachment Blocker feature allows you to block files attached to inbound emails that you consider untrustworthy, or do not want to allow into the company’s infrastructure (e.g., EXE, SCR, or MP3 files).
A wide range of configuration options are available that allow you to choose the notification type, delivery type, and tag emails.

Configuration

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - Attachment Blocker – Inbound

EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Attachment Blocker

The attachment blocker allows you to block certain email attachment file types. Configuration can be done on all levels (customer, domain, profile or user level).

The following settings are available:

• Feature
  Activation or deactivation of the Attachment Blocker (Inbound).

• Filter Mode (incl. Block Lists / Allow Lists)
  You may choose between the “Block-List Strategy” and the “Allow-List-Strategy”. “Block-List Strategy” means that all attachments are allowed to be received, except for the file extensions and MIME types on the block lists below. “Allow-List-Strategy” (recommended from security point of view) means that all attachments are blocked by default and exceptions for allowed file extensions and MIME types are defined explicitly using the provided allow list.
  Retarus recommendations for file extensions and MIME types to block are included in the dedicated admin documentation “Email Security – Attachment Blocker Extensions” available in the EAS portal.

• Blocking Options

  • Block Password Protected Files
    Password-protected files cannot be scanned for malware. If enabled, protected files are blocked in general.

  • Block Suspicious Archives
    Suspicious archive files are highly compressed or multi-nested container files which may contain malicious content (so-called "zip-bombs"). If enabled, these suspicious archive files are blocked.

  • Block Unknown MIME Types
    If enabled, any file not matching a known MIME type will be blocked. For a list of known MIME types, please refer to the dedicated Attachment Blocker admin documentation available in the EAS portal ("Email Security – Attachment Blocker Extensions").

• Attachment – Tag Subject
  If enabled, a short text will be added as prefix to the email subject when an attachment has been blocked. The prefix tag may be configured.

• Admin Notification
  If enabled, a notification email is sent to an administrator whenever an attachment for a user has been blocked.

• Embedded User Notification
  If enabled, the recipient will get a notification about blocked attachments as embedded text in the body of the email. The embedded text may be configured by choosing “Customize Notification”. The text may consist of a header line, main text and footer line. The reason for splitting the text into three parts is that the middle part (main text) may contain the placeholder %filename% for the filename and may be displayed multiple times when using the placeholder, one line for every blocked attachment.

• Store Original Email
  If enabled, a copy of the original email including all attachments is stored in the administrator’s inbox. If this option is set to “Yes”, the target address of the administrator has to be entered and you may choose between the inbox and the quarantine of the administrator as store location.
  Messages may be retrieved from the online quarantine exactly the same way that messages exceeding the file size limit or suspected of containing spam are released.

• Send To User Quarantine
  As an alternative or on top of the setting above, the original mail (including all attachments) may be stored in the recipient’s own user quarantine. This might be useful if you’d like to avoid that a central administrator or service center has to check and release emails with blocked attachments for the users, but on the other hand, you’d like to have a small security barrier, because users have to actively release an email from their quarantine if they know the sender.
  Messages may be retrieved from the online quarantine exactly the same way that messages exceeding the file size limit or suspected of containing spam are released.

Backscatter Protection

EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Domain - Domain Settings (icon on the right side of a domain)

Some criminals use a valid email address of a second person as sender for spam campaigns. In this case, a huge amount of delivery status notifications generated by the receiving email servers (e.g. when the recipient address does not exist) may be sent to the valid address that was used as sender instead of the real sender; this is called “backscatter”.

Retarus provides effective protection against this: If more than one NDR per defined time period (default: 14 minutes) is received for one recipient address, the following NDRs are put into the user quarantine (classified as “NDR Spam”).

Even if the feature has been activated, you have the option to exclude specific addresses from this protection. This exclusion option can prove crucial, for example, if you use specific addresses to send out newsletters and expect to receive delivery status notifications in short intervals.

The settings for backscatter protection are solely available on domain level.

To configure settings for a domain, including the backscatter protection, please click on the icon on the right side of the domain for which you would like to adapt the setting.

To exclude the entire domain from backscatter protection, select Yes. The default setting is No.

In order to exclude individual addresses from backscatter protection, click on the entry field next to Exclude recipient from backscatter protection and enter the relevant email addresses, separating them with commas.

The email addresses entered here must belong to the specific domain you have opened at this point. If you would like to individually assign backscatter protection to the other domains, please do this separately in the Domain menu.

CxO Fraud Detection

Description

This service is part of the Retarus Advanced Threat Protection (ATP) package. It must be booked and activated to take effect.

CxO Fraud Detection is a multi-layered spoofing protection. It includes different sub-modules and algorithms that detect fake senders of incoming emails, e.g. addresses of board members of your organization.

Important: In order to provide accurate results when using the CxO Fraud Detection, valid SPF records are mandatory for all customer domains. “Customer domains” include all domains that are managed by Retarus (see Domain and user management).

Messages classified as CxO Fraud are not delivered to the recipient immediately, but quarantined. The recipient is notified by the Email Security Report (spam digest) and finds the email marked as “CxO Fraud“. The recipient can then decide whether to release the email from quarantine.

The Email Live Search portal provides a separate tracking point for CxO Fraud Detection, including a detailed description of the reason, if an email has been classified as “fraud”.

CxO Fraud Detection consists of different sub-modules analyzing the header information of Inbound emails. (The body is not examined by this module.) Every one of them returns a fraud probability; the highest percentage of them is compared to the configured threshold. If the calculated percentage is higher, the email is put into quarantine as possible fraud.

In the myEAS portal, you may adjust the fraud probability threshold from which on emails shall be regarded as fraud. The default value for the fraud probability threshold is 80%. (If the threshold is set to 100%, Similarity Module is de facto disabled.)

The sub-modules are all designed to prevent spoofing, but each of them addresses a different spoofing technique (attack vector):

• SPF Check: In this first (authentication) module, the sender of an incoming email is checked. If the message has been sent from the customer system itself (EnvFrom contains a customer domain with valid SPF), it is regarded as clean; if the SPF check fails, it is regarded as „fraud“. The following modules are skipped for these emails from customer-own systems. Instead, if the message has not been sent by the customer system, it is now processed in parallel by all of the following modules.

• Similarity Module: Combination of algorithms to detect spoofed domains, e.g. when attackers replace only one letter to make it look similar to the customer’s domain.

• Homography Module: Combination of algorithms to detect use of special character sets to spoof the customer’s domain, e.g. by using Cyrillic letters that look similar to the ASCII ones.

• DisplayFrom Module: Checks, if an attacker makes a customer domain or the name of a person inside the customer‘s organization appear as sender, although the email is coming from another external address – but here, the use case is a more generic phishing attack, where an attacker doesn‘t want to get a reply, e.g. when he tries to trick his victim into making a bank transfer or if he‘s simply announcing a following action like a phone call.

• ReplyTo Module (deactivated by default): The workflow of this module is comparable to the „DisplayFrom Module“, with the only difference that the Reply-To of emails is considered as well for fraud classification. The module checks if an attacker makes a customer domain or the name of a person inside the customer‘s organization appear as sender, although the email is coming from another external address. The use case here is the „classical“ CxO Fraud / Business Email Compromise where an attacker is starting a communication and wants to get a reply from his victim. In this case, the Reply-To plays an important part and is checked by this module: If it contains an external address, the email might be a fraud attempt – but when the Reply-To leads to the valid customer domain, the email is classified as „no fraud“ by this module.

This is also the case if the Reply-To is empty, because in this case, the address from the MIME From is used for replies by default. Therefore, if an attacker leaves the Reply-To empty (because he’s not expecting a reply) and uses a spoofed MIME From including a customer domain, this module does NOT classify the email as fraud

This is the reason why the module is deactivated by default. The ReplyTo module can be activated by enabling the “ReplyTo validation” in myEAS portal.
CxO Fraud Detection Allowlist and Targeted Members Blocklist are considered here as well.

The illustration on the following page describes the processing logic of CxO Fraud Detection in detail.

Legend & implementation details

* MIME-From (= header from): friendly name + email address

** On allowlist: Address/domain is listed on CxO Fraud Detection Allowlist or on AntiSpam Allowlist, depending on which one is configured to be used by CxO Fraud Detection. The customer has to opt for one of the lists as they aren‘t merged. AntiSpam Allowlist is only considered if this is explicitely activated via myEAS portal, otherwise only the dedicated CxO Fraud Detection Allowlist is used.

*** Configured threshold: Percentage configured via myEAS portal, service default = 80%. Configurable on customer, domain and profile level. If calculated fraud probability is higher than the threshold, emails are regarded as fraud attempt and sent to quarantine. (If the threshold is set to 100%, Similarity Module is de facto disabled.)

Configuration

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - CxO Fraud Detection

The following settings are available:

• Feature – Active
  Activation or deactivation of the CxO Fraud Detection.

• Allowlist – Use company-wide AntiSpam Allowlist
  Decide if you would like to use the company-wide AntiSpam Allowlist in addition to the dedicated CxO Fraud Detection Allowlist. If this option is set to “Yes”, all entries on both lists are taken into consideration by the CxO Fraud Detection service.

• Fraud Probability Tolerance – Threshold
  Adjust the fraud probability threshold from which on emails shall be classified as fraud. The default value is 80%. (If the threshold is set to 100%, Similarity Module is de facto disabled.)

• Setup – Mode
  For testing purposes (e.g. when setting up the service for the first time), CxO Fraud Detection may be used in “Warn-only” mode. In this case, no emails are filtered (quarantined or deleted), but you get the classification result via Email LiveSearch and may use it to adjust your settings, SPF record etc. before activating the regular “Filter” mode. If you would like to use the “Warn-only” mode, we recommend contacting a Retarus consultant to support you during the test.

• ReplyTo Validation – Enabled
  This setting activates the “Reply-To” module of CxO Fraud Detection (disabled by default), which means that the Reply-To address of emails is taken into consideration for fraud classification. The use case here is the „classical“ CxO Fraud / Business Email Compromise where an attacker is starting a communication and wants to get the reply by his victim; therefore, the Reply-To plays an important part: If it contains an external address, it is classified as fraud attempt; if it leads to the valid customer domain, the email is automatically classified as „no fraud“ by this module.

CxO Fraud Detection Allowlist

myEAS (https://myeas.retarus.com) - Administration - List Management – CxO Fraud Detection

In order to deactivate the CxO Fraud Detection for certain email addresses or domains, you can list them on the dedicated allowlist for CxO Fraud Detection.

As an alternative to maintaining this allowlist, you may also choose to use your existing global AntiSpam Allowlist as allowlist for CxO Fraud Detection as well. With this option activated, only the AntiSpam allowlist is taken into consideration; entries on the CxO Fraud Allowlist are not regarded any more. This setting can be found in the myEAS portal under Administration > CxO Fraud Detection.
Important

• The CxO Fraud Detection Allowlist will always win over the Targeted Members Blocklist if entries are included in both lists.

• Even for addresses/domains listed on an Allowlist, the SPF check is still performed, therefore a valid SPF record is mandatory for those addresses as well.

CxO Fraud Detection – Targeted Members Blocklist

myEAS (https://myeas.retarus.com) - Administration - List Management – CxO Fraud Detection

Certain attackers use the name of a company CEO or other employee in the MIME-From (e.g. as display name), but without a customer domain as sender address. In order to enable Retarus CxO Fraud Detection to be able to recognize those emails as possible fraud/spoofing attempt, you may put the names of certain managers or other employees on the dedicated “Targeted Members Blocklist”.

To be considered for entries on this list:

• The entries are case-insensitive.

• They may contain only UTF-8 letters.

• If you use umlauts please note that they are not interpreted as the related double vowel and vice versa. So for example the targeted member entry “Eugen Müller” won’t match with a display name “Eugen Mueller”.

• Each entry must not contain more than 3 parts separated by whitespaces. A hyphenated name such as “Muster-Mann” will only count as one part.

• The order of these parts is not important, but ALL parts need to match. If all parts of an entry are found in the From header, CxO Fraud Detection will recognize it as a “targeted member”.

• The CxO Fraud Detection Allowlist will always win over the Targeted Members Blocklist if entries are included in both lists.

Examples of valid entries:

• “Max Georg Müller-Schmidt”

• “E Mueller” → This entry would match with “eugen.mueller@gmx.de“, “Mueller, Eugen”, “EuGEn MuELler” and also “andy@mueller.com” (as “e” is included in “mueller” already!), but not with “Eugen Müller” as “ue” is different to “ü”.

Data Loss Prevention (DLP)

Data Loss Prevention (DLP) checks Outbound emails for certain attachments, defined patterns or in accordance with supervisory recipient controls. This way, confidential information may be prevented from leaving your company via email.

Retarus Data Loss Prevention includes the following elements described in detail below:

• Pattern Recognition

• Sender/Recipient Control (“Data Leakage Prevention” in the EAS portal)

• Outbound Attachment Blocker

DLP – Pattern Recognition

With Pattern Recognition enabled, emails are checked for credit card numbers or bank account numbers (IBAN). If the option is enabled and an email is found to contain this type of pattern, it is not sent out to external recipients.

Administrators can enable or disable the feature, as well as enabling email notification, e.g. to a Security Officer. The notification sent will contain the blocked message as an attachment.
Furthermore, you can activate an option to inform the original sender that the message has been blocked. If enabled, the original sender will receive a notification email.

This feature is available on the company as well as the profile level.

The configuration of this feature is currently handled by Retarus. Please approach your Retarus sales representative or the support for more information.

DLP – Sender Recipient Control (“Data Leakage Prevention”)

EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Data Leakage Prevention

You can use the Sender Recipient Control feature to configure one or more supervisory controls for outbound email communications, allowing you to be aware of what data has been sent and to which recipient. The supervisory controls are configurable at the customer and profile levels and can be customized to meet the differing requirements of individual departments or users.

In order to activate Data Leakage Prevention, at least one outbound email recipient is required to be one of the mandatory recipients. These recipients are specified on the Mandatory recipients list and their inclusion in the email’s distribution list constitutes a supervisory control. At least one of the recipients contained on the list must be entered by all mail users into either the To or the Cc fields in an outbound email. If no mandatory recipient is included, the outbound message gets discarded instead of being delivered.

Mandatory recipients

If a sender has not included a mandatory recipient in the To or Cc fields, the email will be discarded and not delivered to the recipient. Should you want the sender to be notified that their email is undelivered, select Yes in the Notify sender? field. If you do not want the sender to be notified, either select No or leave it on the default setting (which is No). It is also possible to have an administrator notified - select Yes in the Notify administrator? field and then enter the administrator’s and sender’s email addresses.

Restricted recipients

You can use the Restricted recipients list as either a block- or allowlist. If used as a blocklist, communication to all addressees on the list requires the inclusion of a mandatory recipient, otherwise the email will be blocked. If used as a allowlist, all addressees require the inclusion of a mandatory recipient, unless they are on the allowlist.

Outbound blocklist

If your company is required to or wants to block email communication with specific recipients or domains (not senders!), you can enter them under the Outbound blocklist tab. Once blocked, no email delivery is possible to these recipients and domains, even when a mandatory recipient is an addressee.

Outbound allowlist

If you want to block an entire recipient domain while also exempting individual recipient addresses under that domain, you can do this in the Outbound allowlist menu. All emails sent to recipients or domains on the allowlist in any scenario are delivered and do not require a mandatory recipient.

DLP – Outbound Attachment Blocker

EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Outbound Attachment Blocker

The Outbound Attachment Blocker allows you to prevent that defined file types (e.g. EXE-, SCR or MP3 files) are sent to external recipients. To configure it, use the Outbound Attachment Blocker menu under the Settings tab, where numerous options are available to you for choosing the type of notification, and configuring the delivery and marking of emails. All of the configurations made in this menu apply to every mailbox covered by Retarus Email Security.

This feature is available on customer and profile level, and is disabled by default.

The settings for the Outbound Attachment Blocker function are available under both the Settings and Profile tabs. All configurations that you make in the Settings menu are global settings applicable to all mailboxes protected by Retarus Email Security. Any special rules that differ from the global settings are configured in the profile settings.

If you retain the default settings, you will not be able to use the Outbound Attachment Blocker. This means that all messages will be delivered to their intended recipients exactly as your users sent them. If you select Yes in the Activate Attachment Blocker field, several additional configuration options will appear, with which you can configure how unwanted attachments are handled.

If you need to decide whether you want to completely block the transmission of an entire email or only want to delete the attachment, the Block/delete option is available to you. Select Block to prevent emails from being sent (they are discarded completely in this case) or Delete to have only the defined file attachments deleted and the remainder of the email sent without the attachment.

You can also opt here to have an administrator of your choice be informed that an attachment was deleted/blocked by selecting Yes in the Notify administrator? field. A text field will appear in which you can enter the administrator’s email address. In addition, you can also configure whether the sender should be informed by email when attachments are deleted or email messages blocked. To activate this option, select Yes in the Notify the sender? field and enter their email address.

If you have opted to delete the attachments, an additional configuration option will appear: the Activate deletion note feature. When this option is utilized, the recipient of the outbound email is automatically notified that blocked file attachments have been deleted from the message.

There are two tables at the bottom of the menu in which you can enter the specific file types that you want to block (blocklists). You can enter either file extensions of MIME types in the respective tables. If the tables are left blank, all attachments are delivered to their recipients.

Entries in the tables apply to all mailboxes. If you want to exempt certain users from these settings, you can do so by using profile-specific configurations.

Outbound Attachment Blocker at profile level

You can customize the list of blocked file extensions, and/or file types for each profile by selecting Profile-specific from the drop-down menu in the File restriction field. Alternatively, you can opt to use the customer-level settings from the Service settings menu.

A full list of supported file extensions and MIME types is available in Administrator Manual - Attachment Blocker.

Deferred Delivery Scan

Description

Deferred Delivery Scan (DDS) is part of the Retarus Advanced Threat Protection (ATP) package. It must be booked and activated to take effect.

DDS is an additional layer of protection against malicious attachments in emails. The service requests the retarus AntiVirus MultiScan (4-fold) again and performs several re-scan operations within a maximum of 5 minutes. Signatures of new malware that were not available at the time of the first scan can already be available at the time of the next scan. On the other hand, enabling DDS leads to delays for all emails with attachments that are checked by this service.

If a virus is detected, Retarus discards the affected files and informs the addressees via an Email Security Report (digest). Infected emails are listed, but it’s not possible to release them. If no virus is found within 5 minutes of re-scanning, the email is delivered to the addressee’s inbox.

The Email Live Search portal provides a separate tracking point for Deferred Delivery Scan as well as additional information on specific emails.

DDS scans the following attachment types:

• Microsoft Office documents
  *.doc, *.dot, *.wbk, *.docx, *.docm, *.dotx, *.dotm, *.docb, *.xls, *.xlt, *.xlm, *.xlsx, *.xlsm, *.xltx, *.xltm, *.xlsb, *.xla, *.xlam, *.xll, *.xlw, *.ppt, *.pot, *.pps, *.pptx, *.pptm, *.potx, *.potm, *.ppam, *.ppsx, *.ppsm, *.sldx, *.sldm, *.accdb, *.accde, *.accdt, *.accdr

• PDF files
  *.pdf

• Executables
  *.action, *.apk, *.app, *.bat, *.bin, *.cmd, *.com, *.command, *.cpl, *.csh, *.exe, *.gadget, *.inf1, *.ins, *.inx, *.ipa, *.isu, *.job. *.js, *.jse, *.ksh, *.lnk, *.msc, *.msi, *.msp, *.mst, *.osx, *.out, *.paf, *.pif, *.prg, *.ps1, *.reg, *.rgs, *.run, *.scr, *.sct, *.shb, *.shs, *.u3p, *.vb, *.vbe, *.vbs, *.vbscript, *.workflow, *.ws, *.wsf, *.wsh

Configuration

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - Deferred Delivery Scan

EAS portal
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Deferred Delivery Scan

This feature is available on customer, domain, profile or user level, and is disabled by default. In the settings dialogue, you may activate/deactivate it.

Email Live Search: Option to store the subject of emails

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - Customer settings - Data Privacy

EAS portal
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Email Live Search

Detailed information about Retarus Email Live Search is given in Email Live Search.

Only at the customer level, can you configure whether to save the subject line in your in- and outbound emails to make it searchable.

Before activating this option, please clarify internally the legal and data-privacy related impact of giving administrators access to the subject of all emails! For example, this option should be deactivated if your employees are allowed to use their corporate email addresses for private purposes.

Email authentication (Inbound)

In order to validate the sender of an email and that it has not been manipulated during transport, different authentications mechanisms exist. Retarus supports the three common authentication features:

• SPF (Sender Policy Framework)

• DKIM (DomainKeys Identified Mail)

• DMARC (Domain-based Message Authentification, Reporting and Conformance)

The following sections describe the general functionality and how the authentication checks can be configured inside the myEAS portal.

SPF

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - SPF (Sender Policy Framework)

The SPF check function reviews whether the SPF record is valid. Administrators make the decision regarding the handling of these emails; they can opt to

• have the spam probability rating adjusted upwards (SPF = fail) or downwards (SPF = pass),

• quarantine the email directly (SPF = fail) or

• have the email marked with a subject tag (SPF = fail) and have it delivered

Some user groups are candidates for tag and deliver, e.g. departments that take orders or provide external support. SPF softfail isn’t considered at the moment.

DKIM

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - DKIM (DomainKeys Identified Mail)

EAS portal
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - DKIM check

The DKIM check function reviews whether the DKIM signature is valid. There are several reasons why the check would fail, e.g., an incorrect or altered signature, phishing emails, the domain keys not being properly maintained in a DNS entry, or the one of the two email servers is incorrectly configured.

As an administrator, you may opt to have the spam probability rating adjusted either upwards or downwards or you can have the email marked with [RMX:DKIM] in the subject line when it is delivered. Some user groups are candidates for tag & deliver, e.g. departments with lots of external communication. Alternatively, you can have the email quarantined or deleted.

If the DKIM check passes, Retarus delivers the email. In addition, you have the option to have the spam rating lowered by a configurable amount.

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol, extending the SPF and DKIM mechanisms. For incoming emails, Retarus Email Security may validate existing DMARC DNS records of your communication partners and act upon the policy configured by the domain owner. Depending on the validation result and the policy, this means either processing the email regularly, quarantining or rejecting the email.

If an email has to be quarantined due to DMARC, but also fulfils other quarantine criteria (e.g. Spam or Phishing), it may be quarantined with another reason, as Retarus uses a fixed order/hierarchy of quarantine reasons.

If the DNS record of the domain owner cannot be accessed due to technical problems, an incoming email will be temporarily rejected. After 72 hours, it will be rejected permanently and a Non-Delivery Report (NDR) will be issued to the sender.

If you would like to have the DMARC validation activated, please refer to the Retarus Support.
DMARC validation can only be activated for all your domains and requires the use of a dedicated MX record for all your domains. Dedicated MX records include a random number, e.g., “mx-26757099.mail.eu.retarus.com”. Your individual MX record is displayed in the myEAS portal at:
myEAS (https://myeas.retarus.com) - Administration - MX Record.

External Sender Visibility Enhancement (ESVE)

Description

The ESVE feature (disabled by default) can help to sensitize your users for potential spoofing by adding a defined symbol or custom text prefix to the sender field of incoming external emails carrying one of your corporate domains in the sender address (mime-from). This way, the email is not quarantined, but the recipient knows that it’s coming from an external source, despite having an internal sender address.

Important
ESVE is a “tag and deliver” solution. Emails aren’t quarantined or even discarded, a dedicated allowlist doesn’t exist. False positives are possible, e.g. newsletters sent by external service providers, but with internal recipients, are tagged as well if they contain the customer domain as sender.

The following examples illustrate the functionality and limitations of the ESVE feature in comparison to the Retarus CxO Fraud Detection (see 3.8 CxO Fraud Detection):

• From: „John Smith" john.smith@customerdomain.com
  → ESVE recognizes the customer domain, Icon/Text is added.

• From: „John Smith john.smith@customerdomain.com" sender@externaldomain.com
  → ESVE does NOT add an icon/text, because the regex takes the string between the first < and the last >, in this case it extracts the string „john.smith@customerdomain.com> <sender@externaldomain.com“ and compares it to “http://customerdomain.com ”. Retarus CxO Fraud including Targeted Members Blocklist would detect an email like this as suspicious (possible fraud).

• From: „John Smith / http://customerdomain.com " sender@externaldomain.com
  → ESVE does NOT add an icon/text, because ESVE doesn’t check the friendly name in front of the brackets. Retarus CxO Fraud including Targeted Members Blocklist would detect an email like this as suspicious (possible fraud).

• From: „John Smith / CustomerName" sender@externaldomain.com
  → ESVE does NOT add an icon/text, because ESVE doesn’t check the friendly name in front of the brackets – and doesn’t look for company/brand/person names. Retarus CxO Fraud including Targeted Members Blocklist would detect an email like this as suspicious (possible fraud).

• From: „John Smith" john.smith@cust0mer-domain.ru
  → ESVE does NOT add an icon/text, because it uses pure 1:1 pattern matching; misspellings, similarities or suspicious character sets are not recognized. Retarus CxO Fraud Detection would normally detect this, because it uses similarity checks.

Configuration

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - External Sender Visibility Enhancement

EAS portal
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - External Sender Visibility Enhancement

In the settings, you may activate/deactivate the feature and (if activated) choose the prefix header tag that you would like to have added to external emails including one of your domains in the MIME-from. You may write a short prefix text, choose an additional icon (by clicking on it in the list) or combine both.
Available symbols are: The text prefix may contain up to 20 alphanumeric characters.

Inbound Recipient Restriction

By default, incoming emails processed by Retarus may have up to 300 recipient addresses (=user addresses belonging to this customer number). If an email is exceeding this number, Retarus is by default tempfailing the recipients from number 301 onwards. It then depends on the configuration of the sending MTA how this is handled; by default, a retry is done and the remaining recipients are processed in the next session.
The “Inbound Recipient Restriction” feature allows you to configure a lower maximum number of recipients that Retarus accepts for Inbound emails (between 0 and 300 recipients as maximum) and a desired reaction. If the configured maximum number of recipients is exceeded, either the complete email (for all recipients) or only for the exceeding recipients may be rejected, tempfailed or discarded silently.

Important

• A customer-specific MX record for all your domains is mandatory before activating this feature. See MX record for details.

• The feature may only be configured on customer level.

If you would like to have the maximum recipient limit for Inbound emails adapted, please refer to the Retarus Support, as this cannot be configured via the myEAS portal at the moment.

Inbound Sender Restriction

The “Inbound Sender Restriction” allows you to make sure that defined mailboxes of your organization can only be reached by defined external senders (email addresses, domains, IPs or IP nets).

For example, it could be configured that a newsletter sent from a defined external source IP address is accepted for a recipient address used as an internal distribution list containing all your employees, but all other Inbound emails from other IP addresses to this recipient address are getting rejected.

The feature can be configured on customer level only.

This feature is part of the basic Retarus Email Security portfolio. It can be used without additional cost, but has to be configured by Retarus upon request. It cannot be configured via the myEAS portal yet.

Inbound Size Restriction

By default, incoming emails processed by Retarus may have a size up to 250MB (256000kB).

The “Inbound Size Restriction” feature allows you to restrict the size of incoming (Inbound) emails even further, if you want to allow for example a maximum size of 100MB only. Emails exceeding your configured size (between 0 and 256000kB) are either rejected, tempfailed or discarded silently – depending on your configuration.

Important

• A customer-specific MX record for all your domains is mandatory before activating this feature! See 2. MX Record for details.

• The feature may only be configured on customer level.
  If you would like to have the maximum size for Inbound emails restricted to less than 250MB, please refer to the Retarus Support, as this cannot be configured via the myEAS portal at the moment.

Inbound TLS Enforcement

The “Inbound TLS Enforcement” allows you to make sure that Inbound emails from defined senders (email addresses, domains, IPs or IP nets) are only accepted if they are transferred with Transport Layer Security (TLS) enabled.

The feature can be configured on customer level only.

This feature is part of the basic Retarus Email Security portfolio. It can be used without additional cost, but has to be configured by Retarus upon request. It cannot be configured via the myEAS portal yet.

Large Email Handling

Description

In general, messages with a size up to 250 MB are accepted by Retarus Email Security. Retarus Large Email Handling allows you to reliably block emails above a defined size, or alternatively, depending on your settings, to store them securely in Retarus' own datacenters. In the latter case, the recipient is notified by email and may release affected messages individually. This way, sensitive messages of several megabytes in size, such as applications, balance sheet calculations, patent documents, design drawings or credit applications, reach their destination directly without detours via potentially insecure web-based filesharing services. At the same time, unwanted emails above a certain size are reliably blocked, thus significantly reducing the load on your company's email servers.

Configuration

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - Large Email Handling

Available settings:

• Feature
  Enable or disable Large Email Handling. Only if enabled, the settings below are available

• Email Size Limit – KB Limit
  Size limit defined in kilobyte (kb) or megabyte (mb). Maximum size limit is 256 MB.

• Delivery Settings – Move Large Emails to User Quarantine
  If disabled (default setting), emails exceeding the size limit defined above will be rejected and the sender receives a Non Delivery Report (NDR). If enabled, an email exceeding the size limit will be accepted, but stored at Retarus in the recipient’s user quarantine. The recipient will receive a notification and may release the email from the quarantine.

• Recipient Notification
  If enabled, the recipient will be notified when an email exceeds the configured size limit. As sender address of the notifications, antispam.service@retarus.de is used.

• Admin Notification
  If enabled, an administrator will be notified when an email exceeds the configured size limit. In this case, you have to configure a recipient email address of the administrator as well.

• Notification Language
  Choose one of five available languages for the email notifications.

• Notification Timezone
  Choose the timezone for the email notifications.

Outbound Recipient Restriction

By default, outgoing emails processed by Retarus may have up to 600 recipient addresses. If an email is exceeding this number, Retarus is rejecting the email for the recipients exceeding the number; it then depends on the configuration of your email server if/how the end user that tried to send the email is getting notified or if the mail server just does a retry for the rejected recipients and the end user does not notice this at all.

The Outbound Recipient Restriction feature allows you to configure another maximum number of recipients that Retarus accepts for Outbound emails, between 0 and 600 recipients as maximum.

If the number of configured maximum recipients is exceeded, either the complete email (for all recipients) or only for the exceeding recipients may be rejected, tempfailed or discarded silently – depending on your configuration. An Outbound quarantine option does not exist.

The feature may be configured on all hierarchy levels (customer, domain, profile, user).

If you would like to have the maximum recipient limit for Outbound emails adapted, please refer to the Retarus Support, as this cannot be configured via the myEAS portal at the moment.

Outbound Sender Restriction

Description

The “Outbound Sender Restriction” is part of the basic Retarus Email Security portfolio and activated by default (for customers that started at Retarus from 2022 on).

The “Outbound Sender Restriction” allows you to restrict your Outbound traffic to “known sender domains/addresses” only. This security setting is activated by default for all customers that have been onboarded from November 2021 on.

• “Known domains” include the ones that you have registered as Inbound domains, as well as the ones listed on a dedicated "Outbound Sender Allowlist".

• When using the feature, it can also be configured if subdomains shall be included or not; this setting is then applied to all list entries. For all customers that have been onboarded from November 2021 on, by default also subdomains of the “known domains” are accepted.

• Also, a dedicated “Outbound Sender Blocklist” exists to exclude domains/addresses explicitly.

• On both lists, domains (also including subdomains) or email addresses may be added.

• Unlike in other places, the Allowlist does not win over the Blocklist in all cases. Instead, the more specific entry always wins over the more general entry. For example, the setting for an email address wins over the setting for the corresponding domain.

• Outbound emails with empty SMTP/Envelope From sender address (e.g., Non Delivery Reports (NDR)), are not blocked by default, even if the Outbound Sender Restriction is enabled. If this behavior was desired, it could be configured though.

Thanks to these characteristics, different requirements may be implemented. Example use cases:

• If you’d like to allow Outbound traffic for all your Inbound domains only, you may activate the feature. If you would like to include any subdomains (not explicitly registered for Inbound traffic), you may enable this option as well.

• If you’d like to allow Outbound traffic for an additional domain (not registered for Inbound traffic), you may put this domain on the “Outbound Sender Allowlist”.

• If you’d like to block Outbound traffic for one of your Inbound domains, you put it on the “Outbound Sender Blocklist”.

• If you’d like to block Outbound traffic for a certain domain (put on the Outbound Sender Blocklist), but now you would like to make one exception (=allow Outbound traffic) for a sub-domain or a single email address belonging to this domain, you may put the sub-domain or email address on the “Outbound Sender Allowlist”. This way, traffic is allowed for those senders, but blocked for all other senders belonging to the domain on the blocklist.

• The other way around, if you’d like to allow Outbound traffic for one of your domains (registered for Inbound traffic or present on the Outbound Sender Allowlist), but now you would like to make one exception (=block Outbound traffic) for a sub-domain or a single email address belonging to this domain, you may put the sub-domain or email address on the “Outbound Sender Blocklist”. This way, traffic is blocked for those senders, but allowed for all other senders belonging to the domain registered for Inbound traffic or present on the allowlist.

Processing logic/hierarchy concerning block-/allowlist in combination with domains, subdomains and email addresses:

1. Check the email address first (most specific) on the allowlist and, afterward, blocklist.

2. Check the domain on allowlist and, afterward, blocklist.

3. If "subdomain included" option is activated, check for any parental domain on the allowlist and, afterward, blocklist.

Example for a combination of domains and subdomains on Allow-/Blocklist:

• Configuration: http://retarus.com on allowlist, block.retarus.com on blocklist. Option "Include sub-domains" enabled.

• An Outbound email from block.retarus.com is received at Retarus → Result: Blocked.

• An Outbound email from special.block.retarus.com or very.special.block.retarus.com is received at Retarus → Result: Allowed!

Configuration

(De-)Activation of the feature:
myEAS (https://myeas.retarus.com) - Administration - Service Configuration - Customer Settings - Outbound Sender Restriction

Management of the dedicated Allow- and Blocklist:
myEAS (https://myeas.retarus.com) - Administration - List Management - Outbound Sender Restriction

The “Outbound Sender Restriction” is part of the basic Retarus Email Security portfolio and activated by default (for customers that started at Retarus from 2022 on).

The feature can be configured on customer level only.

Outbound Size Restriction

By default, outgoing emails processed by Retarus may have a size up to 250MB (256000kB).

The “Outbound Size Restriction” feature allows you to restrict the size of outgoing (Outbound) emails even further, if you want to allow for example a maximum size of 100MB only.

Emails exceeding your configured size (between 0 and 256000kB) are either rejected, tempfailed or discarded silently – depending on your configuration. An Outbound quarantine option does not exist.

The feature may be configured on all hierarchy levels (customer, domain, profile, user).

If you would like to have the maximum size for Outbound emails restricted to less than 250MB, please refer to the Retarus Support, as this cannot be configured via the myEAS portal at the moment.

Outbound TLS Enforcement

The “Outbound TLS Enforcement” allows you to make sure that Outbound emails to defined recipient domains are transferred with Transport Layer Security (TLS) enabled.

The feature can be configured on customer level only.

This feature is part of the basic Retarus Email Security portfolio. It can be used without additional cost, but has to be configured by Retarus upon request. It cannot be configured via the myEAS portal yet.

Patient Zero Detection

Description

In general, Retarus Email Security is extremely reliable at filtering out infected emails. However, no filter can offer 100% protection. Until now, administrators and recipients of previously unknown viruses have not been informed of the potential threat in their inboxes. This prevents administrators from being able to introduce measures to successfully safeguard their systems against these hidden dangers. Retarus closes this security hole with Patient Zero Detection. With this extension of Retarus’ Email Security Services, such “Patient Zeros” can be identified and dealt with at an early stage. This puts CSOs and administrators in the position to take measures to efficiently counteract threats.

Patient Zero Detection creates and logs hash values (unique digital fingerprints) of each incoming attachment and stores this information with some message details about the recipient, sender etc. in a library. If Retarus detects a virus affecting one of these attachments, IT administrators, and (optionally) recipients are notified immediately or at an interval of your choosing.

Configuration

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - Patient Zero Detection

EAS portal
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Patient Zero Detection

Available settings:

• Feature – Active
  Activation or deactivation of the Patient Zero Detection.

• Admin Notification

  • Admin Notification
    Activate/Deactivate admin notifications.

  • Custom Notification
    If enabled, you may customize the admin notification.

  • Interval
    Here, you can configure the time intervals for administrator notification. An alert will then be sent after it is discovered that emails containing malware have previously been delivered to recipients. If you choose immediate notification, you will receive one alert per hash value. Starting at the five-minute interval, the notifications will be aggregated in a digest. Regardless of the interval, all administrator notifications contain a CSV file that contains additional information such as the hash value of the file, file name, file size, Message ID, etc.

  • Recipient Address
    Email address of the administrator mailbox. We strongly recommend that you enter a central mailbox which is checked regularly, e.g., admin@yourcompany.com.

  • Sender Address
    Define an email address of your company as sender.

  • Sender Name
    Option of specifying the name displayed to the notification recipients.

  • Subject
    Option of specifying the email subject of the notifications.

  • Urgent
    If enabled, notifications are flagged as "high priority/urgent" in the recipient’s mail client.

• User Notification

  • User Notification
    Activate/Deactivate user notifications. User notifications will always be sent immediately and do not contain a CSV file.

  • Custom Notification
    If enabled, you may customize the user notification. This allows you to add additional information such as telephone numbers and email addresses or links to internal IT security guidelines.

  • Sender Address
    Define an email address of your company as sender to generate greater trust in the notification email.

  • Sender Name
    Option of specifying the name displayed to the notification recipients.

  • Subject
    Option of specifying the email subject of the notifications.

  • Urgent
    If enabled, notifications are flagged as "high priority/urgent" in the recipient’s mail client.

An example of an admin notification is displayed below:

Configuration of Patient Zero Detection at profile level

The configuration of the Patient Zero Detection (hereafter "PZD") settings at the profile level is affected by the inheritance of settings at the corporate level (see Section 2 for details). Although data for PZD analysis is collected by Customer Number rather than at the profile level, there are still numerous reasons why your organization may want to configure PZD at the profile level (if you choose, it’s possible to have only profile settings). Here are some possible scenarios:

• Testing PZD for a group of test users before activating it for the whole company.

• Administrator notifications for security purposes at the corporate level, with special user notifications configured at the profile level.

• A separate profile for each subsidiary in a different country, where the language and/or contact person may vary.

• Separate profiles for separate IT security teams in different countries.

• Separate profiles for different departments, because not all user groups need to receive PZD notification.

Patient Zero Detection (PZD) Real-Time Response

In order to process the Patient Zero Detection (PZD) events and move or delete emails automatically (rule-based) from the users’ Exchange inboxes, you may use the PZD Real-Time Response. This application (consisting of a Windows service and an administration interface) is installed locally on your Exchange server, processes Retarus PZD SIEM events and reacts accordingly by moving or deleting the malicious emails in the users’ mailboxes.

A detailed documentation of the PZD Real-Time Response can be found in the EAS portal under Support - Documentation. The PZD Real-Time Response is an optional stand-alone application and has to be ordered separately. For more information, please contact your Retarus sales representative.

Phishing Filter

Phishing Filter Inbound - Configuration

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - Phishing Filter

EAS portal
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Phishing Detection

Here, you may decide how to handle Inbound emails containing URLs recognized as phishing threats by our sources. The default setting is to quarantine these messages with the reason/classification “Phishing”, but the safest option is to delete these messages directly. In this case, the user will be informed which message was deleted in both the quarantine and digest, but cannot retrieve the email. In neither case do allowlists apply, i.e. the emails will be quarantined or deleted even if their sender is included in an allowlist. You also have the option of deactivating the filter completely.

Phishing Filter Outbound

It is possible to have also outgoing (Outbound) emails checked for phishing. If this feature is activated, emails classified as phishing are either rejected, tempfailed or discarded silently – depending on your configuration. An Outbound quarantine option does not exist.

The feature may be configured on all hierarchy levels (customer, domain, profile, user).

If you would like to have the Phishing Filter Outbound activated, please refer to the Retarus Support, as this is not possible via the myEAS portal at the moment.

Phishing Filter URL Allow- and Blocklist

In some cases, an allow- or blocklisting of dedicated URLs is required in order to make sure that emails containing these URLs are either definitely blocked or not blocked by the Phishing Filter.

Allow- and blocklisting affects both the Inbound and Outbound Phishing Filter at the same time.

Retarus maintains a global Phishing Filter URL Allow- and Blocklist that is valid for all customers at the same time. Nevertheless, in some cases a customer-specific possibility to allow or block certain URLs is required.

Use cases include:

• Customers wanting to do phishing awareness campaigns with the need for allowing certain URLs (probably with dynamic subdomains). → URL Allowlist

• Customers wanting to have immediate possibility to block certain URLs (without the need to contact the Retarus Support). → URL Blocklist

In order to maintain your own customer-specific lists and add or remove URLs to/from the lists, please contact Retarus Support. Soon, we will offer the possibility to maintain the lists via myEAS portal.

To be considered for entries on these Allow- and Blocklists (see the table below for examples):

• For URLs on customer-specific blocklist, no Patient Zero Detection (PZD) events are generated.

• Customer-specific lists win over Retarus global lists.

• Allowlist wins over blocklist.

• Schema ("http://" etc.), fragment ("#somefragment") and port ("example.com:21") are cut off.

• Without wildcard, there is no subdomain matching. Subdomain matching may be done by using an asterisk as wildcard in the beginning (*.example.com).

• Exact matching for path, query parameters and values (all case-sensitively). If the value is left out, any value matches.

• Host/domain names are normalized, this means that they are matched case-insensitively (http://Example.com same as http://example.com). Paths and query parameters are not normalized, so they are compared case-sensitively.

• IP v4 notation may be used (except if it's int encoded), IP v6 addresses are not supported.

Examples

Sandboxing

Description

Sandboxing is part of the Retarus Advanced Threat Protection (ATP) package. It must be booked and activated to take effect.

Sandboxing involves static as well as in-depth analysis of specific file attachments. Attachments that could potentially contain malicious routines (such as files and active elements) are executed in a virtual machine and checked for unusual behavior.

Sandboxing applies to the following attachment types:

"*.7z", "*.a", "*.ace", "*.alz", "*.ar", "*.arj", "*.ax", "*.bat", "*.bon", "*.br", "*.btm", "*.bzip2", "*.cab", "*.chm", "*.cjs", "*.cmd", "*.cpio", "*.cpl", "*.dat", "*.dll", "*.doc", "*.docm", "*.docx", "*.dotm", "*.dotx", "*.drv", "*.efi", "*.eml", "*.exe", "*.gz", "*.gzip", "*.hta", "*.htm", "*.html", "*.jar", "*.js ", "*.lha", "*.lhz", "*.lib", "*.lrz", "*.lz", "*.lzma", "*.lzo", "*.mjs ", "*.msi", "*.ocx", "*.pdf", "*.pif", "*.pot", "*.potm", "*.potx", "*.ppam", "*.pps", "*.ppsm", "*.ppsx", "*.ppt", "*.pptm", "*.pptx", "*.ps1", "*.rar", "*.rtf", "*.rz", "*.scr", "*.sldm", "*.sldx", "*.sys", "*.tar", "*.tnef", "*.vbs", "*.wbk", "*.wim", "*.wsf", "*.xht", "*.xhtml", "*.xla", "*.xlam", "*.xlm", "*.xls", "*.xlsb", "*.xlsm", "*.xlsx", "*.xlt", "*.xltm", "*.xltx", "*.xlw", "*.xz", "*.z", "*.zip", "*.zoo", "*.zst"

If Sandboxing does not identify the attachment as malicious within 13 minutes, the email is delivered to the recipient (time-out period). This maximum delay is only applicable in very rare cases; in most cases, Sandboxing only causes a short delay as the static analysis often delivers a result already. Even in combination with Deferred Delivery Scan (DDS), the validation of messages doesn’t take more than 13 minutes in total (absolute maximum, most of the emails are analyzed for seconds only).

The Email Live Search portal provides a separate tracking point for Sandboxing as well as additional information on specific emails.

Configuration

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - [Level] - Sandboxing

EAS portal
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Sandboxing

This feature is available on customer, domain, profile or user level, and is disabled by default.

In the settings dialogue, you may activate/deactivate Sandboxing and (if activated) choose under “Mail Deletion” if suspicious emails shall be deleted (“Yes”) or if they shall be quarantined (“No”). The default setting is “No”, so emails are normally moved to the recipient’s User Quarantine. The addressee is notified by the Email Security Report (digest) and finds the email marked with “Sandboxing” as a quarantine reason. He may then decide whether to release the email from quarantine or not.

Alternatively, you can choose to delete infected emails directly. Also in this case, Retarus informs the addressees of discarded emails via the Email Security Report (digest); infected emails are listed under the “Virus” digest category. In contrast to the first option, discarded emails may not be retrieved any more.

Signature/disclaimer

For all Outbound emails, customizable personal signatures and disclaimers may be used. When created, these signatures/disclaimers are added automatically at the end of every outgoing email.

The configuration may be reached via:
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Signature

You may create a new signature by clicking on the Add signature button below the table. A blank entry field appears at the top of the Name column. After you name the signature, you can select a format for it (either Text or HTML).

The next step is to click on the settings icon () icon to bring up the signature file in the WYSIWYG editor, where you can personalize entries such as name, title, department, and employee extension. To edit a signature file using the WYSIWYG editor, you would also begin by clicking on the settings icon in the relevant signature row.

When you click on this icon for an existing signature, the signature file interface that appears has various placeholders for data such as the employee name, title, department, and extension are available under the Insert placeholder drop-down menu located in the lower part of the Editor. You can import this data directly from Lotus Domino/Notes or your Active Directory.

The use of placeholders minimizes the effort of maintaining mandatory data in business emails in accordance with legal guidelines. These requirements are identical to the content found in traditional business correspondence, and include, among other items, the firm’s legal domicile, its legal form, the name of the managing director, and the relevant court of registry. Disclaimers can be used to legal information or disclaimers of liability in emails.

The assignment of signatures occurs at the profile level. You can opt to have signatures and disclaimers in combination with each other.

Time-of-Click Protection

Description

This service is part of the Retarus Advanced Threat Protection (ATP) package. It must be booked and activated to take effect.

Retarus Time-of-Click Protection (ToCP) is part of the post-delivery protection. When an email has been classified as “clean” and delivered to the recipient, ToCP checks again in real-time the URLs included in the email if a user clicks on them.

In order to protect your users, ToCP rewrites all URLs in the body of Inbound emails and replaces them by a URL beginning with https://protection.retarus.com followed by the original URL and a unique hash. On hovering over the link with his mouse, a user may see the rewritten link including the original target in his email client before clicking on it. When the rewritten URL is clicked, the user is redirected to the Retarus servers, the URL is checked by the Retarus Phishing Detection again and if the rating is still “clean”, the user is forwarded directly to the original URL without any remarkable delay. On the other hand, if the URL is now rated as “malicious”, the user gets displayed a block page.

The following block page is displayed by default:

Configuration

myEAS (https://myeas.retarus.com) - Administration - Service Configuration - Time-of-Click Protection

EAS portal
EAS (https://eas.retarus.com) - Administration - Email Services - Service configuration - Settings - Time-of-Click Protection

In the myEAS portal, the service may be activated/deactivated and a custom block page may be defined:

• Feature – Active
  Activation or deactivation of the Time-of-Click Protection (disabled by default).

• Custom Landing Page
  When Time-of-Click Protection is activated and the end user clicks on a URL that is rated as “malicious”, the gets redirected to a block page (see service description above). By default, an English page with Retarus logo (see above) is used. With the setting “Custom Landing Page”, you may define another custom block page.
  Configuring a custom block page can only be done on customer level.
  If you would like to use the Retarus default, but in German, enter the following URL. (Other languages are not available as of now): https://protection.retarus.com/de/finding?url=%7B%7BURL%7D%7D
  If you would like to use another individual page (incl. your logo etc.), you may create and host this page on your webserver. In this case, you may configure one of the following URLs to use it for Time-of-Click Protection findings.
  https://your.landingpage?url={{URL}}
  https://your.landingpage#{{URL}}
  https://your.landingpage/{{URL}}
  The placeholder {{URL}} gets replaced with the original target URL. The placeholder isn’t mandatory, but you may use it to include the original URL on your page. This can be helpful, but on the other hand it also poses a security risk.
  For a custom block page, the use of https is recommended, because our service uses https as well. When redirecting from https to http, most browsers display a security warning to the user.