AXS Guard MTA

Introduction

About this Document

The AXS Guard E-mail Relay How To is intended for system administrators who are familiar with SMTP, application level filtering and PKI. It consists of a conceptual section, outlining the components and capabilities of the AXS Guard SMTP server and a configuration section, where we explain the various server settings. Following is an overview of the contents.

Examples used in this Guide

All setups and configuration examples in this guide are executed as an advanced administrator. Some options are not available if you log in as a full administrator or a user with lower access privileges.

As software development and documentation are ongoing processes, the screenshots shown in this guide may slightly deviate from the current user interface.

General E-mail Concepts

Overview

In this chapter, we briefly explain the general concepts of electronic mail or e-mail. These concepts will provide you a better understanding of how the AXS Guard relays electronic mail and performs the necessary security checks to prevent undesired files from entering your network. Topics covered in this section include:

E-mail architecture and services
The user agent
Message formats
Unencrypted or Encrypted Message transfer
The final delivery of the e-mail

Architecture and Services

E-mails travel across the Internet between the source and destination via servers, in the same way that traditional paper mail travels the world via post offices . On the Internet, the role of post offices or sorting offices are assumed by Mail Transfer Agents or MTAs. The concept of e-mail varies slightly from a traditional post office in that a Mail Server stores e-mails for an e-mail client and the e-mail client retrieves and delivers them. Traditional mail is usually delivered, not retrieved. Mail Servers are sometimes called Delivery Agents and Mail Clients are sometimes referred to as Mail User Agents (MUAs), e.g. MS Outlook.

E-mails can either be stored locally on the AXS Guard mail server or on a dedicated server, e.g. in the AXS Guard LAN. Mail servers are sometimes also referred to as delivery agents.

Analogy between Paper and Electronic Mail

Typically, e-mail systems support five basic functions:

Composition refers to the process of creating messages and answers. Although any text editor can be used for the body of the message, the system itself can provide assistance with addressing and the numerous header fields attached to each message. For example, when answering a message, the e-mail system can extract the originator’s address from the incoming e-mail and automatically insert it into the proper place in the reply.
Transfer refers to moving messages from the originator to the recipient. This requires establishing a direct connection with the destination MTA or some intermediate MTA, outputting the message, and releasing the connection. The e-mail system should do this automatically, without user interaction. At this stage, security checks are performed. By default, the transfer of messages is unencrypted. However, message traffic can be encrypted, as the AXS Guard MTA supports the Transport Layer Security Protocol or TLS.
Storage is the process of saving new messages in the appropriate folders, archiving, etc. For more information about E-mail storage, see the AXS Guard E-mail Storage How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.
Reporting refers to communicating to the originator and system administrators what happened to a message, e.g. the delivery status.
Displaying incoming messages is needed so people can read their e-mail. Sometimes conversion is required or a special viewer must be invoked, e.g. if the message is a PostScript file.
Disposition is the final step and refers to what the recipient does with the message after receiving it. Possibilities include deleting it before reading, deleting it after reading, archiving, forwarding, etc.

E-mail Message Components

The key idea in e-mail systems is the distinction between the envelope and its contents.

The envelope encapsulates the message. It contains all the information needed to transport the message, such as the destination address, the message priority, etc. The message transport agents (MTAs) use the envelope for routing, just as the post office does. A new envelope is created for every recipient.

The message inside the envelope consists of two parts: the header and the body. The header contains control information for the user agents. The body is intended for the human recipient. The difference between paper mail (a) and e-mail (b) is illustrated below.

User Agents

E-mail systems have two basic parts; the user agents and the MTAs. In this section, we explain the user agents. A user agent is usually a program that accepts a variety of commands for composing, receiving, and replying to messages, as well as for manipulating mailboxes. Some user agents have a fancy menu or an icon-driven interface that requires a mouse, whereas others take imput commands from the keyboard. Functionally, they are the same.

Examples of user agents include, but are not limited to, Outlook Express, Outlook and Thunderbird.

Sending E-mail

To send an e-mail, a user must provide a destination address, the messsage and possibly some other parameters. The message can be produced with a free-standing text editor, a word processing program, or possibly with a specialized text editor built into the user agent. The destination address must be in a format that the user agent can process. Many user agents expect addresses of the form user@domain. Other address formats exist, but are outside the scope of this manual. Information about MX records and DNS is available in the AXS Guard System Administration How To and the Public DNS How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

E-mail systems, such as the AXS Guard support distribution lists, so that a user can send the same message to a list of recipients with a single command. For more information about distribution lists, see the AXS Guard E-mail Storage How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

Reading E-mail

Typically, when a user agent is started up, it connects to the mail server hosting the user’s mailbox and checks for incoming e-mail(s) before displaying anything on the screen. Afterwards, the user agent (depending on the type) communicates the number of new messages in the mailbox or displays a one-line summary of each one and waits for a command.

Sophisticated user agents and MTAs, such as the AXS Guard, ease the process of managing a large volume of e-mails.

Message Formats

E-mails have specific formats. These formats are defined per RFC. In this section, we start by explaining the basic ASCII e-mail, based on RFC 822. Afterwards, we explain the multimedia extensions based on RFC 822.

RFC 822

Messages consist of a primitive envelope, a number of header fields, a blank line, and then the message body. Each header field (logically) consists of a single line of ASCII text containing the field name, a colon, and, for most fields, a value. RFC 822 was designed decades ago and does not clearly distinguish the envelope fields from the header fields. Although it was revised in RFC 2822, a complete redesign was impossible due to its widespread usage. Typically, the user agent builds a message and passes it to the message transfer agent (MTA), which then uses some of the header fields to construct the actual envelope.

The principal header fields related to message transport are listed below:

Header	Description
To:	E-mail address(es) of the primary recipient(s).
CC:	E-mail address(es) of the secondary recipient(s).
BCC:	E-mail address(es) which should receive blind carbon copies. This line is deleted from all the copies sent to the primary and secondary recipients.
From:	The mailbox from which the message is sent.
Sender:	E-mail address of the sender.
Received:	Line added by each MTA during the e-mail transfer.
Return-Path:	This field is added by the final MTA and is intended to inform you how to get back to the sender. In theory, this information can be gathered from all the Received headers (except for the name of the sender’s mailbox). Typically it just contains the sender’s address.
Message ID	The message ID is a unique message identifier. It usually includes data, a timestamp, an IP address, a hostname and other information to attempt to make the ID unique. This identifier is intended to be machine readable. A Message ID matches exactly one instance of a particular message; subsequent revisions to the message should each receive new Message IDs.

The message body immediately follows the headers. Users can write anything they want in the body of the e-mail.

Multipurpose Internet Mail Extensions

In the early days, e-mail consisted exclusively of text messages written in English and expressed in ASCII. For this environment, RFC 822 was sufficient; it defined the headers but left the content entirely up to the users. Nowadays, on the Internet, this approach is no longer adequate. The problems include sending and receiving:

Messages written in languages containing accents and other special characters (e.g. French, Spanish and German).
Messages written in languages based on non-Latin alphabets (e.g. Hebrew, Russian, Japanese).
Messages containing audio, images or other non-ASCII information.

A solution was proposed in RFC 1341 and updated in RFCs 2045 and RFC 2049. This solution, referred to as Multipurpose Internet Mail Extensions or MIME is now widely used. The basic idea of MIME is to continue the use of the RFC 822 format, while adding structure to the message body and define encoding rules for non-ASCII messages. There is no deviation from RFC 822; MIME messages can be sent using the existing mail programs and protocols. The only required changes are the mail clients (the sending and receiving programs), which users can install themselves.

MIME defines five new message headers, as listed in the table below. The first MIME header informs the receiving user agent that it is dealing with a MIME message and indicates which MIME version is being used. Any message not containing a MIME-version header is processed as a plain text message.

Header	Description
MIME-Version	Indicates the MIME version being used.
Content-Description	Human-readable string which describes the content of the message.
Content-ID	Unique identifier
Content-Transfer-Encoding	Indicates how the e-mail body is wrapped for transmission.
Content-Type	Type and format of the content. It specifies the nature of the message body. Content types are defined per RFC 2045, RFC 2854, RFC 3003 and RFC 3023 (This list is subject to changes) Each content type has one or more subtypes. The type and subtype are separated by a slash, e.g. `Content-Type: video/mpeg`

MIME Headers

In-depth information about MIME is outside the scope of this manual. See the appropriate online resources for detailed information.

Message Transfer

The message transfer system is responsible for relaying of messages between the sender and the recipient(s). Sending an e-mail consists in making a transport connection from the source machine to the destination machine (the destination MTA), during which the e-mail is transferred.

The IP address of the destination MTA is looked up with a DNS query. The DNS system provides an MX record which contains the IP address (or addresses) of the destination MTA(s). More information about DNS is available in the AXS Guard Public DNS How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

SMTP: The Simple Mail Transfer Protocol

On the Internet, e-mail is delivered by having the source host establish a TCP connection to port 25 of the destination host. An e-mail daemon (a process, also defined as the Mail Transfer Agent or MTA), which speaks SMTP, is listening on this port. The daemon accepts incoming connections and copies messages from them into the appropriate mailboxes. If a message cannot be delivered, an error report containing the first part of the undeliverable message is returned to the sender.

SMTP is a simple ASCII protocol. After establishing the TCP connection to port 25, the sending machine, operating as the client, waits for the receiving machine, operating as the server, to talk first. The server starts by sending a line of text providing its identity and telling whether it is prepared to receive mail. If it is not, the client releases the connection and tries again later. Below is an example of a basic SMTP conversation.

Connected to gmail-smtp-in.l.google.com.
Escape character is '^]'.
220 mx.google.com ESMTP y2si15309955eeh.9
HELO mydomain.com
250 mx.google.com at your service
MAIL FROM:<me@mydomain.com>
250 2.1.0 OK y2si15309955eeh.9
RCPT TO:<jwics.ts@gmail.com>
250 2.1.5 OK y2si15309955eeh.9
DATA
354  Go ahead y2si15309955eeh.9
Hi, this is a test message. Catch you later.
.
250 2.0.0 OK 1302600534 y2si15309955eeh.9
QUIT
221 2.0.0 closing connection y2si15309955eeh.9
Connection closed by foreign host.

If the server is willing to accept e-mail, the client announces whom the e-mail is coming from and whom it is going to. If such the recipient exists, the server gives the client the go-ahead to send the message. When the message is sent, the server acknowledges it. If there is more e-mail to be sent, it is sent at this point. When all e-mails have been exchanged in both directions, the connection is closed. The e-mail exchange process is illustrated below.

AXS Guard E-mail Relay Concept

During and after the e-mail transfer, the AXS Guard performs several security checks, which are explained further in this manual.

E-mail Handling: Own Domains vs. External Domains

An MTA can handle e-mails differently, according to the domains in the e-mail headers. Incoming e-mails can either be:

Handled locally; the final destination is the MTA.
Forwarded to another computer in the MTA’s LAN.
Relayed to another authorized, external MTA. This only applies to mail sent from the LAN.
Delayed for delivery, in case the MTA is being maintained and there is no alternate MTA available.

Own Domains (Local and Forwarded)

A domain for which your AXS Guard is authoritative is considered an own domain. E-mails for own domains can either be:

Stored locally: E-mails are stored on the AXS Guard mail server and can be retrieved with an e-mail client with POP or IMAP. For more information about POP and IMAP, see the AXS Guard Mail Storage How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.
Forwarded internally: Rather than storing the e-mails locally, the incoming (and content filtered) messages are forwarded to an MTA in the AXS Guard LAN. Virtual domains

Important

As of AXS Guard version 8.2.0, virtual domains have been implemented. A virtual domain is either a local or forwarded domain for which a directory service (LDAP) profile has been configured. See the AXS Guard Directory Services manual for more information. This implementation directly affects the way e-mail aliases are handled by the AXS Guard mail server.

Alias addresses are used to find and apply the matching AXS Guard mail policy (applies to local and forwarded domains).
Messages sent to a mail alias are stored in the user’s AXS Guard mailbox (applies to local domains only). See the AXS Guard E-mail Storage manual for details and examples.

External Domains (Relayed out)

An external domain is a domain for which the AXS Guard MTA is not authoritative. E-mails sent to an external domain from a specific AXS Guard domain can be relayed to an external MTA, e.g. the MTA of the ISP. This option only applies to e-mails sent from the LAN. Relaying messages to an external MTA with a static IP is useful if you have a dynamic Internet IP, as most MTAs no longer accept e-mails originating from dynamic IP addresses. This is an extra security precaution to prevent spam. Another advantage is that, if you decide to send e-mails originating from a specific domain on the AXS Guard via the MTA of your ISP, you can enter your MTA’s IP address. This is a nice workaround which not only prevents overhead of DNS queries, but at the same time solves the issue of MX record lookup issues in case of a failing DNS server.

Final Delivery to the Mail Client

This section provides a brief overview of the protocols and techniques used to retrieve messages from a mail server. For details about mail retrieval and mail storage, see the AXS Guard Mail Storage How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

POP3: is an application-layer Internet standard protocol, operating on port 110 and used by e-mail clients to retrieve e-mail from a remote server over a TCP/IP connection. The e-mail(s) are downloaded and stored on the client.
IMAP: The Internet Message Access Protocol (commonly known as IMAP) is an application-layer Internet protocol operating on port 143, which allows e-mail clients to view and manage e-mails directly on a remote mail server. Contrary to POP3, the e-mail(s) are not downloaded by the client, but remain on the server.
Webmail: Webmail (or Web-based e-mail) is an e-mail service primarily intended to be accessed via a web browser. Very popular webmail providers include Gmail, Yahoo! Mail and Hotmail. The AXS Guard Webmail feature uses the IMAP protocol internally.

MTA Relay Scenarios and Security Checks

Overview

In this chapter, we explain the security checks which are performed by the AXS Guard MTA to prevent abuse of the mail system.

Topics covered in this chapter include:

E-mail relay: how the AXS Guard MTA relays e-mails, i.e. transfers electronic messages.
Anti-relay check: network checks performed by the AXS Guard in which the originating network is considered; the Internet, the DMZ and the secure LAN (Open relay protection). Mails are only handled for authorized domains.
Encryption: message transfers from and to the AXS Guard can be encrypted with TLS, as described in RFC 2487.
Security checks: checks involving users, headers, allowed e-mail addresses, attachments, malware, etc.
Masquerading: With masquerading, your outgoing e-mail appears to originate from user@somedomain.com instead of user@serverx.somedomain.com. Masquerading hides your internal host name from rest of the world.
Disclaimer: is a statement at the bottom of a message, which is intended to specify or delimit the scope of rights and obligations that may be exercised and enforced by parties in a legally-recognized relationship.

E-mail Relaying

A sender’s MTA usually sends an e-mail message directly to the receiver’s MTA. However, it is possible to send an e-mail message to an intermediate MTA, which in turn forwards the message to the destination MTA, as if it was the source. The intermediate MTA uses the DNS system to look up the MX record for the destination domain and to retrieve the IP address of the destination MTA. This applies to situations where the sender MTA cannot send an e-mail directly to the destination MTA.

The AXS Guard provides three relaying options; it can relay outgoing e-mails for all registered domains, it can relay outgoing e-mails for (a) specific domain(s) or forward all e-mails for a specific domain.

Relaying All Outgoing E-mails

With this option, all e-mails are relayed to an intermediate MTA instead of being delivered to the destination MTAs.

Relay All Outgoing Messages

A relay MTA simplifies configuration when multiple MTAs exist in a network. All MTAs relay their messages to a central MTA, which is known to the outside world. This simplifies the configuration for the non-relay MTAs. An extra advantage of this setup is that one MTA acts as a mail hub for your network, allowing local MTAs to be concealed.

Another reason to use a relay MTA is if you have a dynamic public IP address. MTAs generally reject e-mails originating from an MTA with a public dynamic IP address, to defend their systems against spam (unsolicited e-mails). Sending all e-mails via an Internet provider’s MTA solves this problem .

AXS Guard can be configured to use a relay MTA. When a relay MTA is used, queuing is enabled. This means that message transmission is attempted at regular pre-configured time intervals, if for any reason the relaying MTA would be busy or unavailable. Messages remaining in the queue after the configured amount of time are discarded and the sender is notified.

Relaying Some Outgoing E-mails to a Specific MTA

A relay MTA can be used for a specific domain. E.g. e-mails addressed to domain.com can be relayed to a specific MTA on the Internet, while e-mails for other domains are delivered directly to their authoritative MTAs.

If the MTA for a specific domain is known, no DNS query is needed to obtain its MX record; e-mails can be relayed directly to the configured MTA. This way you can bypass temporary DNS problems on the Internet.

Forwarding E-mails for a Specific Domain

A relay MTA can be used for handling all incoming and outgoing e-mails. This is useful if the destination MTA cannot be reached directly from the Internet, e.g. if it’s located in a secure LAN, as shown below.

Example: Forwarding Incoming and Outgoing e-mails to a Specific Domain

Assume the following: An e-mail domain, e.g. domain.com, is handled by an MTA in the secure LAN, e.g. a Microsoft Exchange server. To send an e-mail from the Internet to mary@domain.com, DNS servers are consulted to find an MX record for domain.com. Since the MTA in the secure LAN cannot be reached from the Internet, the MX record points to the public IP address of the AXS Guard MTA. E-mails are only accepted and delivered if the domain domain.com has been correctly registered on the AXS Guard. This is also referred to as the open relay protection. Local and forwarded domains are referred to as “own domains”.

Advantages

The advantage of this setup is that all messages are checked by the AXS Guard (MTA and content checks) before they are relayed, while users are able to use the functionalities provided by a Microsoft Exchange server, i.e. the Outlook Web Access (OWA), Outlook Mobile Access (OMA) and shared calendar functionalities. Using port forwarding in this scenario is not advised, since it would bypass the AXS Guard MTA and content checks, exposing your OWA server to potential attacks.

Another advantage is that you can configure your Exchange server to use the AXS Guard MTA for all outgoing mail. This allows your exchange server to benefit from the AXS Guard’s MTA security and Content Filtering, including anti-virus checks.

Anti-Relay Check

With the explosion of unwanted and potentially dangerous e-mails circulating on the Internet, MTA security is an important issue. Depending on the originating network, the AXS Guard MTA adopts its behavior.

Open Mail Relay Problem

An open mail relay is a poorly configured SMTP server, because it allows anyone on the Internet to send e-mail through it, and not just mail destined to or originating from known users. This used to be the default configuration for many mail servers on the Internet. Open mail relays have become unpopular due to their exploitation by spammers and e-mail worms. Many open relays were closed or blacklisted by other servers.

The AXS Guard MTA automatically rejects all messages, unless the destination domain or destination e-mail address is explicitly allowed.

E-mails from the Internet

E-mails originating from the Internet are only accepted if they are sent to a valid domain registered on the AXS Guard. Mails directed to other domains are automatically rejected; they are not even processed to save resources.

E-mails from the DMZ

E-mails originating from the DMZ are only accepted if they are sent to a valid domain registered on the AXS Guard. Mails sent to any other domains are automatically rejected; they are not even processed to save resources.

E-mails from the Secure LAN

E-mails originating from the secure LAN are always accepted by the AXS Guard MTA, i.e. there are no restrictions on destination e-mails addresses for messages originating from the secure LAN, except for the restrictions enforced via content filters.

Important

Users who are connected to the AXS Guard VPN server, e.g. via a PPTP connection, are considered members of the secure LAN.

Transport Layer Security (TLS)

The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering (encryption). TLS is an optional security feature on the AXS Guard which, if enabled, allows the encryption of e-mail traffic from and to the AXS Guard SMTP server.

The basis of TLS lies in the use of certificates within the PKI infrastructure. The AXS Guard MTA can be configured to request a client certificate to enforce client authentication, as shown in the figure below.

An explanation of PKI and certificates is outside the scope this guide. For general information about PKI, see the adequate online resources or the AXS Guard PKI How To, which can be accessed by clicking on the Documentation button in the Administrator Tool.

How TLS operates

A TLS client and the server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection’s security. An example of a TLS session is provided below.

The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported CipherSuite (ciphers and hash functions).
From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision.
The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA) and the server’s public encryption key.
The client may contact the server that issued the certificate (the trusted CA) and confirm the validity of the certificate before proceeding. The AXS Guard allows you to select a self-signed certificate or to import a third party certificate.
In order to generate the session keys used for the secure connection, the client encrypts a random number with the server’s public key and sends the result to the server. Only the server should be able to decrypt it, with its private key.
From the random number, both parties generate key material for encryption and decryption.

S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.ietf.org
S: 250-mail.imc.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>

C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: <continues by sending an SMTP command>

The initiation of a TLS session may fail on behalf of either the server or the client:

Server: If the client supports the STARTTLS service and responds with the a STARTTLS command, then the server can either:
- Accept: “220 Ready to start TLS”
- Deny: “501 Syntax error (no parameters allowed)“
- Delay: “454 TLS not available due to temporary reason“
Client: If the client does not support the STARTTLS service, it will not reply with a STARTTLS command. The server will respond with a “530 Must issue a STARTTLS command first”. A client can also be configured to require the server to always initiate a TLS session. If the server does not support TLS, the client should not proceed and send the QUIT command, otherwise the server will respond with a “502 5.5.1 Error: command not implemented “ message.

Certificates and Supported Key Types

A certificate is a digital file which contains the public key of an organization and is used to encrypt messages. The key must be of a certain type. The AXS Guard currently supports RSA keys, which are commonly used by commercial Certificate Authorities. System Administrators can either choose to use the PKI tool of the AXS Guard to generate a self-signed server certificate or import a third party certificate. Currently, the following certificate types are supported:

PEM Certificate Files (with or without a separate key file)
PKCS12 Certificate Files

Third party certificates should include the following:

The public key of the CA
The server’s public key
The server’s private key

TLS Encryption and Authentication

To secure communications between the client and the server, the AXS Guard uses TLS, which authenticates the client (only if client certificates are used in your TLS setup) as well as the server and creates an encrypted connection between both. This connection consists of a TLS Handshake, which negotiates the key exchanges using an asymmetric algorithm such as RSA of Diffie-Hellman. Following this negotiation, TLS opens an encrypted channel using a symmetric algorithm such as RC4, IDEA, DES, 3DES, AES, etc.

Data Integrity

TLS ensures that exchanged data is not altered during transmission. It therefore uses hashing algorithms such as MD5 and SHA. Message digests or hash functions are used to create a short, fixed-length representation of a longer, variable-length message. Digest algorithms are designed to produce a unique digest for each message to make it impractically difficult to determine the message from the digest and (in theory) impossible to find two different messages which create the same digest, thus eliminating the possibility of substituting one message for another while maintaining the same digest.

An explanation of MD5 and SHA is outside the scope of this manual. For details about MD5 and SHA, see the adequate online resources, e.g. http://en.wikipedia.org/wiki/MD5 and http://en.wikipedia.org/wiki/Secure_Hash_Algorithm.

TLS Security Levels

Overview

Each set of protocols and ciphers that are used to secure e-mail communications with the AXS Guard MTA is determined by a security level.

The following security levels can be used for inbound mail traffic as well as outbound mail traffic:

none: TLS is not used
may: If the client attempts to encrypt the communications channel, TLS is used. If not, the AXS Guard appliance falls back to unencrypted communications. This method requires no pre-arrangement between clients and the appliance.
encrypt: TLS must be used.

The following security levels can only be used for outbound mail traffic:

verify: Based on the e-mail envelope of the outgoing message, certain information is checked in the certificate of the destination MTA.
secure: Similar to verify, but stricter.

General Security Levels

The default server and client-side security level is may (see TLS Security Levels). This means that the AXS Guard always offers TLS to an incoming connection, but the client has the option to use TLS or not. If TLS handshakes fail, the connection is retried with TLS disabled. The same applies to outgoing connections; the AXS Guard will try to initiate a TLS session with the destination MTA. If the TLS handshake fails, the connection is retried with TLS disabled. The general settings apply to all mail traffic, which means the configuration is applied to all destination domains. The AXS Guard offers the possibility to specify certain behavior on a domain basis. This is done via TLS policies.

Client Verification

At the global server layer, the AXS Guard can be configured to verify client certificates, which provides access control to its MTA. To receive an SMTP client certificate, the AXS Guard SMTP server must explicitly ask for one or specifically require the client to send one when TLS is required.

The verification depth of the client certificate can also be configured and is set to 9 by default. The verification depth determines how far TLS should verify the certificate chain before deciding that the sending client does not have a valid certificate. Verification stops at the specified depth. You can use the AXS Guard PKI tool to generate certificates for your mail clients.

Important

Some e-mail clients, like Netscape, are not user friendly when this feature is used. They may complain if no matching client certificate is available or they will present a list of certificates to choose from. Additionally, some MTAs are unable to complete TLS negotiation when client certificates are requested and abort the SMTP session.

Server Verification

The verify and secure options both verify the certificate of the destination MTA, while the options may and encrypt do not. Certificates may not be expired or revoked, and must be signed by a trusted certificate authority.

Verify:

Based on the e-mail envelope of the outgoing message, the following information is verified in the destination server’s certificate in the listed order:

If the domain of the recipient e-mail address domain is a local, forwarded or relay out domain (E-mail > Domains), the configured destination is verified.
If the destination domain is not a local,forwarded or relay out' domain, the MX record of the destination domain is verified, based on the e-mail address of the recipient.
If no matching MX record can be found in the certificate, a custom pattern (if configured) is verified. This option can be used to solve special cases.

Secure:

At this level, MX lookups are not trusted to be secure enough to verify the names of TLS peers. Instead, the following information is verified in the destination server’s certificate based on the domain in the recipient’s e-mail address:

The recipient’s e-mail domain.
If no domain can be found, a special pattern to be matched (if configured). This option can be used to solve special cases.

The verification depth can also be configured, and is set to 9 by default. The verification depth determines how far TLS should verify the certificate chain before deciding that the remote server does not have a valid certificate. Verification stops at the specified depth.

Example 1: Verify

Patterns specify domain names, or domain name suffixes. example.com matches the example.com domain, i.e. one of the names in the server certificate must be example.com; upper and lower case distinctions are ignored. .example.com matches subdomains of the example.com domain, i.e. match a name in the server certificate that consists of a non-zero number of labels followed by a .example.com suffix. Case distinctions are ignored.

Example 2: Verify

Assume the following:

Recipient: foo@foo.com
MX record of foo.com: mx.bar.com
Security level = verify:
Subject in certificate = mx.bar.com > TLS is accepted
Subject in certificate = foo.com > TLS is NOT accepted

The name of the next hop must be present in the certificate.

Example 1: Secure

Recipient: foo@foo.com
MX record of foo.com: mx.bar.com
Security level = secure:
Subject in certificate = mx.bar.com > TLS is NOT accepted
Subject in certificate = foo.com > TLS is accepted

The domain of the recipient must be present in the certificate.

Example 2: Secure

If you specify mx10.example.com as a match, you will receive a name error (mismatch) if you connect to smtp.example.com.

TLS Policies

TLS Policies always apply to outgoing connections.

The AXS Guard MTA can be configured to impose security levels on a domain basis, i.e. to override the general security settings for a specific destination domain. This is achieved via TLS policies. In the TLS policy you must specify the destination domain and the desired security level.

Example: Override general encrypt setting for domainx.com.

Assume that you trust the MTA of domainx.com and that the general settings for outgoing connections are configured to always use TLS, i.e. the security level for outgoing connections is set to encrypt. You can override this setting specifically for domainx.com. Just add domainx.com to a TLS policy and set the security level to none.

Example: Encrypt for untrusted domainy.com.

Assume that you don’t trust the connection to the MTA of domainy.com and that the general settings for outgoing connections are configured not to use TLS, i.e. the security level for outgoing connections is set to none. You can override this setting specifically for domainy.com. Just add domainy.com to a TLS policy and set the security level to encrypt. As a result, all mail to domainy.com will be sent over a TLS session.

How Messages are Relayed with TLS

Currently one method to initiate an SSL connection over SMTP is supported by AXS Guard. It consists of a standard connection to TCP port 25. An SSL session is started by issuing the STARTTLS command.

Security Checks

In this section we explain the additional AXS Guard MTA security checks. If one of these security checks fails, the e-mail is discarded:

Helo message check.
Preventing connection from MTAs with Dynamic IP addresses.
Bad header checks.
Black listing, white listing and grey listing.
Anti-spoofing, i.e. validation of e-mail addresses.
Validity check of the sender’s and the recipient’s e-mail address formats.
Validation of recipient addresses based on the origin.
Verification of the existence of the user account.
Blocking password protected zip files.

Helo Message Check

MTAs exchange identification information via the “HELO FQDN” command. The FQDN (Fully Qualified Domain Name) is the name of the MTA issuing the command.

The AXS Guard MTA only accepts the connection if the FQDN of the sending MTA is properly formatted. If an invalid FQDN is used in the helo command, mail originating from the sending MTA is automatically rejected. In a nutshell, e-mails from MTAs which do not identify themselves properly is rejected if this option is enabled.

Helo Message Check

MTA with Dynamic IP Address

The AXS Guard MTA is configured to reject connections from MTAs with a dynamic IP address. In most cases, dynamic IP addresses are assigned to end users and are unlikely to be assigned to an MTA. This security check prevents spammers from abusing end user IP addresses to send spam messages. The AXS Guard uses black lists to prevent connections from MTAs with dynamic IP addresses.

In case your AXS Guard appliance has a dynamic IP address, your e-mails may be rejected by MTAs on the Internet. A solution to this problem is to use the MTA of your Internet Service Provider (ISP), which uses a static IP address. ISPs always accept mail originating from their customers.

Bad Header Checks

Per RFC, an e-mail header must only contain ASCII characters. Mails which deviate from the RFC(s) are not be trusted, as they usually contain a virus or some other undesired content . Mails containing bad headers are automatically rejected by the AXS Guard MTA. The following is an example of a message which contains a bad subject header.

Message with a bad header

Trying 192.168.60.254...
Connected to 192.168.60.254.
Escape character is '^]'.
220 mail.domain.be ESMTP Secure MTA - Watch your steps
EHLO mail.domain.be
250-axsguard.domain.be
250-PIPELINING
250-SIZE 5242880
250-ETRN
250-ENHANCEDSTATUSCODES
250 8BITMIME
MAIL FROM: test@test.com
250 2.1.0 Ok
RCPT TO: john@domain.be
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
To: john@domain.be
From: test@test.com
Subject: subject1
Subject: subject2

This is a test.
.

Black Lists

A black list is a collection of e-mail or IP addresses that are known to send spam or infected messages. Specific text strings, which frequently occur in spam messages, may also be defined in a black list. The AXS Guard MTA looks for blacklisted items in every message. If a match is found, the message is blocked. The AXS Guard uses a number of black lists that are automatically updated via the Internet.

An entry in an AXS Guard black list can be overruled by an entry in a white list. The black and white lists use the concept of prioritizing specific matching criteria over generic matching criteria, e.g. the white list entry specific.host.com has priority over the black list entry host.com.

Scope

The AXS Guard black lists are only applied to e-mails originating from the Internet or the DMZ. There are two types of black lists; black lists which are automatically enabled and updated via the Internet and custom black lists.

Black List Types

Free realtime black lists (RBL): These are lists containing the IP addresses of identified spammers. They are automatically updated via the Internet. Following are examples of RBLs on the AXS Guard: sbl.spamhaus.org and bl.spamcop.net, which block MTAs with dynamic IP addresses.
Customized black lists: System administrators can create custom lists based on the e-mail properties to be matched. The following properties can be matched:
- The sender and / or the recipient’s e-mail address (Either by providing the entire e-mail address or the domain).
- A specific text string. Every incoming message is checked against the entered string. If the string in the black list matches the header or body of the e-mail, the message is blocked.
- The IP. Use the CIDR notation to specify a range.

Important

Sometimes it’s possible that a message is blocked by a Black List even when there is no apparent connection between the content, the attachment and the settings configured in the Black List. The solution is to create a White List to overrule the blocked content in the Black List.

White Lists

AXS Guard white lists allow you to overrule MTA security checks, including entries in the black lists. You can create customized white lists based on the same e-mail properties used for black lists. With white lists you can also overrule spam checks defined in filters.

If a user or a group of users is not receiving wanted messages due to spam checks, a custom filter can be configured so that the user(s) are able to receive the messages.
If the problem affects all users, it is recommended to create a white list entry, which is a system-wide setting.

About Black and White List Priorities

Whitelists always overrule blacklists, except when e-mail header and/or body text is matched. In such cases the following applies:

A whitelist that matches text in an e-mail header and/or body always overrules a matching blacklist.
A whitelist which matches other properties, such as an IP or e-mail address, does not overrule a matching blacklist which filters on text.

Whitelist	Blacklist	Who wins
email	domain	Whitelist
email	email	Whitelist
domain	domain	Whitelist
domain	email	Blacklist

Grey Listing

Greylisting is a method to defend e-mail users against spam. The AXS Guard MTA uses greylisting to temporarily reject any e-mail from a sender it does not recognize. If the mail is legitimate, the originating server will try send it again and it is eventually accepted if certain conditions are met. If the e-mail originates from a spammer, it will most probably not be resent, since a spammer goes through thousands of e-mail addresses and cannot afford the time delay to resend the message.

Grey Listing Triplets

For each message delivered to the AXS Guard, a triplet containing the "CLIENT_IP" / "SENDER" / "RECIPIENT" is built. The first time that this triplet is noticed or if a triplet has been noticed within a specific delay (300 seconds is the system default), the e-mail is rejected with a temporary error. Otherwise the e-mail is accepted (whitelisted). Before a sending host is whitelisted, delivery has to be reattempted within a specific time frame (2 days being the system default).

Auto-whitelisting Servers (MTAs)

Server IP addresses of MTAs are automatically whitelisted if the following conditions are met:

At least X messages need to be accepted from X different triplets with at least 1 hour between the accepted messages. The factor X represents successful deliveries before the server is whitelisted.
The server has attempted a connection within X days. (35 is the system default). Entries older than this period are automatically deleted.

New triplets are not created if a valid triplet already exists for an MTA (e.g. originating from an unknown e-mail address, but being sent from a known MTA). This is to avoid unnecessary cluttering of the triplet database.

Auto-whitelisting Senders

Sender IP addresses are automatically whitelisted if:

At least X messages are accepted from X different triplets with at least 1 hour between the accepted messages. The factor X represents successful deliveries before the sender’s IP is whitelisted.
The sender’s IP has attempted a connection within X days. (35 is the system default). Entries older than this period are automatically removed.

Manually Whitelisting Clients

Client IP addresses can be manually whitelisted by adding the client’s IP address or FQDN to the Grey Listing Database.

Whitelisting applies to a /24 network when a specific IP address is added, supporting possible mail system clusters: multiple mail systems can be used to handle the e-mail of a specific domain providing load balancing, i.e. mail cluster. Those mail systems will most-likely use an IP address within the same /24 network. e.g. adding 192.0.2.1 will whitelist the entire 192.0.2.0/24 range.

Whitelisting Recipients

Exceptions can be set for recipients by adding their e-mail address to the Grey Listing Database. Greylisting is not applied to the specfied e-mail addresses.

Anti-Spoofing

E-mail spoofing is a term used to describe (usually fraudulent) e-mail activity in which the sender address and other parts of the e-mail header are purposely altered to appear as though the e-mail originated from a different source. E-mail spoofing is a technique commonly used for spam and phishing to hide the origin of an e-mail message. The result is that, although the e-mail appears to come from the address indicated in the From field (found in e-mail headers and envelopes), it actually comes from another source.

Example: CEO Fraud

CEO fraud is a type of spear-phishing email attack.

Typically, attackers identify themselves as high-level executives (CFO, CEO, CTO, etc.), lawyers or other types of legal representatives and purport to be handling confidential or time-sensitive matters, attempting to trick staff into transferring money to a bank account they control.

The AXS Guard appliance sends a rejection message when a connection is received from an MTA which uses a sender e-mail address containing a domain name or e-mail address registered on the AXS Guard appliance.

AXS Guard checks the sender in the e-mail envelope as well as the e-mail header to detect spoofing attempts. Spoofed e-mail is stored under Deleted Spam and can be released (e.g. in case of a false positive).

System administrators can configure a white list to overrule anti-spoofing checks. Information about spoofing attempts are stored under E-Mail → Logs → Summary and E-Mail → Logs → Detail.

Sending e-mail from the Secure LAN or a VPN Client

By default, the AXS Guard appliance only allows configured local and forwarded domains to be used in sender addresses in case the e-mail is sent from the secure LAN or a VPN client. No restrictions apply, except if specified in a content filter.

Example: Anti-Spoofing

Assume you have the following domain: mydomain.com and that a person on the Internet is trying to send you an e-mail with the following e-mail address: evil@mydomain.com to admin@mydomain.com The AXS Guard MTA detects the spoofing attempt and rejects the message, as shown in the SMTP conversation below.

telnet 10.32.64.214 25
Trying 10.32.64.214...
Escape character is '^]'.
220 mail.mydomain.com ESMTP Secure MTA - Watch your steps
helo mydomain.com
250 axsguard.mydomain.com
MAIL FROM:<evil@mydomain.com>
250 2.1.0 Ok
RCPT TO:<admin@mydomain.com>
571 5.7.1 <evil@mydomain.com>: Sender address rejected:
Spoofing is not polite!

Example: Special case whitelisting the Envelope FROM address to allow bulk mail operations

The sender’s e-mail address is specified twice when e-mail messages are delivered from a sender to a recipient: once in the e-mail envelope (MAIL FROM) and once in the e-mail header.

Both addresses can be spoofed and e-mails containing spoofed addresses will be blocked by the AXS Guard anti-spoofing check.

However, there are certain cases in which you may want to allow such e-mails, e.g. for bulk mail operations.

Assume the following:

You have configured the following AXS Guard local or forwarded domain: example.com.
Anti-spoofing is enabled on AXS Guard.

An e-mail is sent from the Internet:

Envelope from: foo@bar.com
Header from: foo@example.com

The message will be blocked - as expected - by the AXS Guard anti-spoofing check, because the domain in the header’s address matches the local or forwarded domain example.com and the e-mail originates from the Internet.

To bypass the anti-spoofing check, you will need to configure a whitelist for the MAIL FROM (envelope) address and not the address in the e-mail header.

For traveling employees who need access to corporate e-mail services, Able recommends the following solutions on AXS Guard:

Webmail: A solution to manage and send e-mail via an Internet browser.
Access to the AXS Guard MTA via a VPN connection (L2TP, PPTP, IPsec, SSL VPN, OpenVPN ), which allows users to send and receive e-mails as if they were operating from their own desk.
OWA Reverse Proxy: A solution to securely access your corporate OWA via an Internet browser.

SMTP Authentication is supported, but not recommended, since it bypasses the AXS Guard anti-relay check . By default, the credentials are transmitted in cleartext.

E-mail Address Format Checks

Spam messages and e-mails containing viruses are often sent with malformed sender addresses. The AXS Guard performs special checks identifying and blocking such messages.

Recipient Address Restrictions

E-mail addresses have to comply with the standards set forth in the RFCs.

Many MTA administrators use initials in e-mail addresses for easy maintenance, e.g. abc@somewhere.com. Such e-mail addresses are more susceptible to spam abuse, because the number of permutations needed to guess the user names is very limited (3 letter combinations are easier to guess than full names). The AXS Guard MTA can be configured so that these user names are rejected if used in an e-mail originating from a non-secure (Internet and DMZ) source. If the security check is enabled, only secure LAN and VPN users may use short names when sending e-mails to eachother. Users outside the secure LAN must use the longer alias, e.g. alpha.beta@somewhere.com.

The Sender Policy Framework (SPF)

In this section, we explain the Sender Policy Framework (SPF) record. The SPF record is a special TXT record.

SPF was invented to enable the validation of legitimate e-mail sources of a domain and is now an IETF standard (RFC 4408).

Briefly, the intent of the SPF record is to allow a receiving MTA (Message Transfer Agent) to interrogate the name server of the domain which appears in the e-mail (in the sender’s address) and determine if the sending IP (the source) is authorized to send mail for the given domain.

The SPF information must be defined in a standard TXT Record (RFC1035).

If an SPF record (TXT) exists and authorizes the source IP address, the e-mail can be accepted by the MTA. If the SPF (TXT) does not authorize the IP address, the mail can be discarded, since it did not originate from a source that is authorized by the sender’s domain.

Many MTAs use the SPF record and there are plenty of potential advantages, such as the elimination and reduction of some spam categories. The logic behind SPF records is illustrated below. The steps (1 – 6) are explained further.

How SPF Works

The user Harry sends an e-mail to betty@gmail.com from a computer in his domain, domain.com.
The gateway of user Harry queries a DNS server to look up the MX record of the destination domain, i.e. the domain of the recipient; gmail.com.
The DNS server provides the IP address of the destination mail server.
The e-mail is sent and arrives at the recipient’s e-mail server.
The From: field in the message is inspected, and the receiving e-mail server sends out a DNS query to verify if the domain in the From: field has an SPF record.
The DNS server replies with an SPF (TXT) record of the sending host, if the record is available. If the record indicates that the sending host is authorized to send e-mail for domain.com, the e-mail is accepted on the receiving end.

Important

If no SPF record exists for the sending host, the e-mail is also accepted. For additional details about SPF and SPF record testing, see: http://www.openspf.org

DomainKeys Identified Mail (DKIM)

DKIM is an email security standard designed to ensure messages aren’t altered in transit between the sender and the recipient. It provides protection against domain spoofing and phishing attacks.

Specifically, it leverages public-key cryptography to sign emails with a private key as they leave a sending server. Recipient servers then look up the sender’s public key via DNS to verify the DKIM signature of the message and to make sure that the body of the message wasn’t altered during transit. Once the DKIM signature is successfully verified by the recipient server, the message will be considered authentic.

AXS Guard uses its anti-spam engine to validate the DKIM signatures of incoming messages. To publish your own DKIM signature for a domain, you'll need to generate a DKIM key and TXT record on AXS Guard. The resulting DKIM TXT record must then be added to your DNS server. This process allows receiving email servers to verify the authenticity of e-mails sent from your domain, enhancing email security and deliverability.

DMARC

Domain-based Message Authentication, Reporting, and Conformance, or DMARC, is a technical standard that helps protect email senders and recipients against spam, spoofing, and phishing. DMARC relies on DNS, SPF and DKIM standards for email authentication. The process of DMARC validation works as follows:

System administrators publish a domain policy which defines its email authentication practices. This is done with a DNS record.
When an inbound mail server receives an incoming email from that domain, it looks up its DMARC policy via DNS. The inbound server then checks the message for 3 key factors:
- Is the DKIM signature valid?
- Did the message originate from IP addresses that are allowed to send email for that domain (SPF)?
- Do the headers in the message show proper domain alignment?
With this information, the receiving server can apply the sending domain’s DMARC policy and decide whether to accept, reject, or otherwise flag the email message.
After using DMARC to determine the proper message disposition, the receiving mail server will report the outcome to the owner of the sending domain.

Important

Currently, AXS Guard does not check DMARC for incoming mail traffic. For outgoing mail traffic, administrators must add the appropriate DNS record for their domain.
DMARC validates the From: address rather than the envelope sender (Return-Path), and understanding this distinction is key to appreciating how DMARC functions. Please see the following question on serverfault.com for additional information.

Existing E-mail Addresses

Local Domain

If the e-mail address of the recipient exists in a local domain of the AXS Guard MTA, the user is looked up in:

The AXS Guard user database (Under Users&Groups > Users).
The e-mail alias lists.
The distribution lists.

If the user cannot be found, the e-mail is rejected by default and the AXS Guard MTA automatically rejects the sender. Besides providing security, it also saves system resources as the message is not even processed by the AXS Guard MTA.

helo test.com
250 mx.server.com
MAIL FROM:<test@test.com>
250 2.1.0 Ok
RCPT TO:fake1@server.com>
550 5.1.1 <fake1@server.com>: Recipient address rejected:
User unknown in local recipient table
quit
221 2.0.0 Bye

Forwarded Domain

The security check, as explained above, is not executed by default if the recipient’s e-mail domain is a forwarded domain. Domain forwarding allows you to easily send e-mails destined for a non-local domain through one SMTP server (a single point of entry). In other words, your AXS Guard acts as an incoming gateway to your network and allows you to have a single point of entry for incoming SMTP traffic towards any forwarded domain. The security check is only functional if the MTA responsible for the forwarded domain supports it.

Example: Forwarded Domain

Assume that you configured the following forwarded domain: fwdomain.com, a user admin@fwdomain.com and that a message is being sent from the Internet to admin@fwdomain.com. The security check, as explained above, is enabled. The AXS Guard MTA sends a query to the MTA which is responsible for the forwarded domain and verifies if the user (e-mail address) exists. If the user does not exist (invalid e-mail address), the e-mail is rejected.

Masquerading

With masquerading enabled, your outgoing e-mail appears to originate from user@somedomain.com instead of user@serverx.somedomain.com. Masquerading allows you to hide hosts inside a domain behind the AXS Guard mail gateway, and to make it appear as if the mail originates from the AXS Guard itself, rather than from the invidual machines behind it. Masquerading is only possible for own domains.

Address masquerading is only applied to the “From” and “To” headers of a message and to the sender addresses in the envelope.

The following masquerading options are available on the AXS Guard:

Masquerading is enabled at the system level and allows you to enable / disable it individually for each of your domains.
Masquerading is disabled; the domain as configured in the e-mail client is used for outgoing mails, on the strict condition that it is a valid (existing) domain on the AXS Guard. Mail sent from an invalid domain is blocked and also logged as such.

In the example below, we assume that masquerading is enabled for:

yourdomain.com
accounting.yourdomain.com

Example: Masquerading

You send a message as sender@accounting.yourdomain.com When received by the recipient, the message’s origin will appear as accounting.yourdomain.com
You send a message as sender@abcxyz.yourdomain.com When received by the recipient, the message’s origin will appear as yourdomain.com, since masquerading is not enabled for abcxyz.yourdomain.com
You send a message as sender@abcxyz.accounting.yourdomain.com When received by the recipient, the message’s origin will appear as accounting.yourdomain.com
You send a message as sender@myprivatedomain.com The message is blocked by the AXS Guard MTA, unless it is permitted by a content filter.

Disclaimer

A disclaimer is a statement at the bottom of a message intended to specify or delimit the scope of rights and obligations that may be exercised and enforced by parties in a legally-recognized relationship. The disclaimer is a system-wide settings and is added to all outgoing messages (of all valid domains).

The following formats are supported for disclaimers:

Plain text
HTML

HTML allows you to use HTML tags in your disclaimer as well as external images via href. Note that the recipient’s e-mail client must be adequately configured to display any remote images.

Remote Mailboxes

The AXS Guard MTA can be configured to distribute e-mails collected by a “catch-all” mailbox on the Internet. A “catch-all” mailbox refers to a mailbox in a domain that will "catch all" of the e-mails destined for that domain. A “catch-all” address provides a cheap method for companies to receive e-mail, since they don’t need a mail server of their own. Furthermore, a catch-all mailbox prevents the loss of e-mails due to misspelling, but it also results in a higher spam rate, since all messages are collected and stored in this central mailbox.

You can only configure and use the Remote Mailbox option is you purchased and enabled the AXS Guard e-mail server module.

Message Delivery

There are 3 options on AXS Guard to deliver messages of a catch-all mailbox to the final recipients:

You can have the messages delivered locally to a specific AXS Guard user account.
You can have the messages delivered to an external e-mail address, e.g. to a mailbox on an MS Exchange server in your corporate LAN.
You can have the messages delivered to multiple accounts, i.e. multidrop mode.

Multidrop Mode

Multidrop mailboxes, also called "catch all" mailboxes, contain e-mails for more than one person. Generally, all e-mails for a certain domain are collected therein and are to be retrieved by the AXS Guard; the AXS Guard then distributes the e-mails among the appropriate user mailboxes. Dropping off mail for multiple distinct recipients in the same mailbox requires the collecting server to deposit the actual recipient in the mail to achieve proper delivery.

The messages can be forwarded to an internal mail server provided that the messages are delivered to a single account. The multidrop feature is only available to accounts for which mail is delivered to the AXS Guard mail server. We do not recommend the use of multidrop mode because it may result in mail loss and a higher spam rate. (See Troubleshooting for information about specific situations with MS Exchange servers).

Envelope Header: A Solution for Potential Mail Loss

When messages are delivered to the remote “catch-all” mailbox, the original envelope is removed, i.e. the sender’s and the recipient’s e-mail addresses.

Since the envelope data is missing, Blind Carbon Copies (BCC) as well as addresses specified in a mailing list (which are not present in the mail headers) could be lost.

This problem can be resolved by the provider of the remote “catch-all” mailbox. The provider should add an e-mail header containing the recipient’s envelope address and create a new message in the mailbox for every To, CC and BCC recipient. The AXS Guard can be configured to detect this header, enabling it to correctly deliver the message and eliminating loss of messages.

Unfortunately, the use of such headers is neither required nor standardized. System administrators are therefore invited to contact their Internet service provider for more details regarding the remote account or can inspect the e-mail headers via webmail (if available).

If the special header is not available, the recipient header is used for delivery.

Some ISPs put the username and hostname of the envelope recipient in the e-mail header described above. The major reason for this is to prevent mail loops.

This results in mail sent to username@userhost.userdom.dom.com having a Delivered-To: line of the form: Delivered-To: mbox-userstr-username@userhost.example.com

On AXS Guard, the defined string prefix can be removed from the user name found in the specified header before performing multidrop name mapping or local domain checking, if either is applicable.

Spam Issues

The detection of spam is the most effective when the data of the sender’s MTA is available. Unfortunately, this information is lost when using the remote mailbox feature, resulting in a higher spam rate.

To reduce spam, you should register the remote mailbox’s domain on the AXS Guard. When a message is delivered to the AXS Guard from that domain, the domain name is stripped from the message. The remaining user name is checked to see if it is a valid AXS Guard user. If it is an invalid user, the e-mail is undeliverable.

Undeliverable Messages

Undeliverable messages are silently dropped by the AXS Guard. You can keep a copy of these messages on the AXS Guard by creating an “undeliverable” distribution list or an alias. It is highly probable that this mailbox will be flooded with spam, since it will store all messages which are undeliverable (destined for non-existing e-mail addresses).

Summary

In this section, we provide a summary of the items covered in this chapter in relation to the items which will be covered in. The diagram below depicts the entire flow of MTA checks and content filtering to which an e-mail is subjected before its actual delivery (or before it is quarantined).

Incoming Mail

The anti-relay check is the first check to be executed by the AXS Guard MTA when an e-mail arrives.
If the connection is not aborted during the anti-relay check, in other words if relaying is permitted, the AXS Guard MTA performs a range of standard security checks as explained in and its subsections.
Finally, the content of the message is scanned based on the applicable filters. The message is scanned for prohibited extensions and viruses amongst other things.

Outgoing and Internal Mail

The content of the message is scanned based on the configured filters. The message is scanned for prohibited extensions and viruses amongst other things.

Content Filtering Concepts

Overview

In this chapter, we explain the AXS Guard content filtering system. Content filtering occurs when an e-mail has been accepted by the AXS Guard MTA (it passed the anti-relay check and the MTA security checks). The sending MTA considers the e-mail to be accepted and delivered. However, the e-mail can still be rejected by the content filtering system and bounced back to the originating MTA. If the message is allowed by the AXS Guard content filters, it is delivered to the user’s local mailbox or forwarded to the user’s mailbox on the forwarded domain’s mail server.

Content filters are implemented by adding them to a policy, which in turn need to be assigned to an AXS Guard user, group or the system.

Content Filters and Policies

Filters

Content Filters define the content checks to be applied to e-mails. Two types exist, incoming filters and outgoing filters. Incoming filters apply to e-mails based on the sender’s e-mail address, outgoing filters apply to the receiver’s e-mail address. An e-mail matching a filter has the filter’s content checks and actions applied; extension blocking, spam and forwarding. If there is no match with a filter, the e-mail is rejected and bounced back to the source address, prior to any content scanning or anti-virus checks.

The specificity of matching can be configured as follows:

All domains: the filter always matches, unless a more specific filter is added which has priority based on the “best match” principle. This allows the definition of a “catch-all” filter. The “catch-all” filter applies to all e-mail addresses not matching any other specific filters. This is a technique to prevent all e-mails not matching other filters from being automatically rejected.
All local and forwarded domains: the domains registered on the AXS Guard.
Others: specified domains or e-mail addresses.

Example: Filter Operation

Filters examine each sender/receiver pair separately. Mail from guido@domain.com to marc@domain.com and anthony@domain.com results in two content scanning actions; one for the guido@domain.com/marc@domain.com pair and one for the guido@domain.com/anthony@domain.com pair.

Policies

Policies consist of at least one content filter and are always assigned to e-mail addresses. You can only assign a policy to e-mail addresses of AXS Guard (local and forwarded) domains or external e-mail addresses.

Policies for your own (local and forwarded) domains can be assigned at the system, group or user level. Assignment of policies combines the security of a default system-wide policy with group or user specific configuration settings.

Policy and Filter Matching

Policy Matching

Since a mail policy is assigned to an e-mail address, two content filtering policies may be assigned to an e-mail, one to the sender’s address and to the receiver’s address. Every AXS Guard user is assigned a mailbox. E-mail addresses are in the user@yourdomain.com or useralias@yourdomain.com format.

Policy Assignment to an e-mail address in a local domain

E-mail policies can be assigned at the user, group or system level. The applicable level is determined as follows:

A system mail policy is assigned by default in the absence of any other level policies, e.g. for distribution lists;
A group level policy takes priority over the system level policy; the system-wide policy is overruled. The group policy is assigned to the e-mail addresses of all users of the group and also to their e-mail aliases;
A user level policy takes priority over a group level policy; the group level policy is overruled. The user policy is assigned to the user’s e-mail address and also his / her aliases.

Policy Assignment to an e-mail address in a forwarded domain

Forwarded e-mail addresses refer to mailboxes handled by an MTA other than the AXS Guard. The users do not necessarily exist on the AXS Guard, meaning that only the system-wide e-mail policy can be assigned.

However, you can implement AXS Guard user or group e-mail policies for e-mail addresses in the forwarded domain, by creating the users and groups on the AXS Guard, if the system policy is not sufficient.

Example 1: Policy Assignment

Assume you have a forwarded domain, forwarded.com with a user marc, who does not exist on the AXS Guard. The user’s e-mail address is marc@forwarded.com. By default, this address is assigned the system-wide e-mail policy. You can overrule the system-wide policy by creating the user on the AXS Guard and assign the appropriate group or user e-mail policy.

Example 2: Policy Assignment

Assume that you have a forwarded domain, forwarded.com with a user marc jones, who already exists on the AXS Guard as user mj. If you wish to overrule the system-wide policy in this case, you only need to add the user’s alias e-mail address e.g. marc@forwarded.com or user name, e.g. marc to the user account mj.

Mail policies for forwarded domains are assigned as follows:

A system-wide e-mail policy is assigned by default in the absence of any other level policies;
A group level policy has priority over the system level policy; the system-wide policy is overruled. The group policy is assigned to the e-mail addresses of all users of the group and also to their e-mail aliases;
A user level policy takes priority over a group level policy; the group level policy is overruled. The user policy is assigned to the user’s e-mail address and also his / her aliases.

Detailed information about creating users is available in the AXS Guard System Administration How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

Filter Matching

The diagram below shows the AXS Guard content filtering process for an accepted e-mail. “Own” domains are local or forwarded domains. Any other domains are labeled as “external”. The same process applies to local and forwarded domains; the only difference is that for a forwarded domain, the user has to be created locally on the AXS Guard if you want to enforce user and/or group policies.

There are four possible sender/recipient address combinations, as explained in Filter Scenarios.

E-mail Content Filtering Process

Important

The last combination (external to external), where both the sender and the recipient e-mail addresses are not own domains, is blocked by the MTA. However, there are certain exceptional cases, as explained in Filter Scenarios.

Combined Filters

Local mail for which both outgoing and incoming filters exist have the safest content check combination applied as follows:

Action: the e-mail is blocked if one or both of the filters' actions is set to “reject”.
Extension blocking: an extension is blocked if blocking is specified in one of the filters, even if one filter specifically permits the extension. e.g. if the incoming filter blocks .exe extensions and the outgoing filter blocks .com extensions, both file types are blocked. If the incoming filter blocks .exe files and the outgoing filter specifically allows .exe files, the blocking action prevails.
Spam: if the spam settings differ in filters, the lowest spam tag threshold is applied . The delete option is activated if switched on in either (or both) filter(s). If activated in both filters, the highest delete spam threshold is applied.
Forwarding: e-mails matching the filter are copied to the original destination address and to any forwarding addresses specified in one or both filters.

Filter Scenarios

The following table explains how content filters are applied per sender/recipient combination:

The AXS Guard mail filter assignment is based on the premise that all e-mails are blocked, unless a filter matching the sender’s e-mail address, the recipient’s e-mail address or domain exists. If preferred, a catch-all filter can be configured to check all e-mail traffic not matching any other filter. This catch-all filter is configured with the “all domain” option. The default system mail policy contains a catch-all filter .

Direction	From	To	Description
Outgoing	Own domain	External domain	Only the sender’s domain is an own domain: if an outgoing filter in the sender’s e-mail policy matches the recipient’s e-mail address, the checks/actions defined in the filter are applied; if no filter matches, the e-mail is blocked.
Incoming	External domain	Own domain	Only the recipient’s domain is an own domain: if an incoming filter in the recipient’s policy matches the sender’s e-mail address, the checks/actions defined in the filter are applied; if no filter matches, the e-mail is blocked.
Local	Own domain	Own domain	Both the sender’s and the recipient’s domain are own domains, so the message does not leave the local network. If there is no outgoing filter in the sender’s policy matching the recipient’s e-mail address, the e-mail is blocked. If there’s no incoming filter in the recipient’s policy matching the sender’s e-mail address, the e-mail is blocked. If the e-mail is not blocked at either of these stages, the combination of actions defined in the matching filters apply.
External	External domain	External domain	Neither the sender’s nor the recipient’s domain are own domains, e.g. e-mail traffic originating and destined for outside domains, when a user configures a private e-mail address/domain on his/her mail client to send private e-mails from work. An e-mail sent from the user’s private e-mail address to an outside e-mail address is blocked by the AXS Guard, because the user and domain are not registered on the AXS Guard. This prevents users from bypassing e-mail filters. However, you can implement a policy to allow a user to send private e-mails from work, by registering the external e-mail address on the AXS Guard and assigning a policy to it .

Only one mail policy can be assigned per e-mail address. This avoids filter conflicts. However, it may occur that two policies are applied to an e-mail, in case one policy applies to the sender and another to the receiver, i.e. if both the sender and the receiver e-mail addresses belong to own domains (i.e. the “local” direction in the table above).

Only one incoming and/or one outgoing filter can be applied per e-mail. If more incoming or outgoing filters in a policy match the e-mail, the “best match” principle applies: e.g. a filter matching “manual.vasco.com” has priority over a filter matching “vasco.com”. If there is a match, the actions defined in the filter are applied. However, both an incoming and an outgoing filter may be applicable to an e-mail, as in the local mail scenario explained in the diagram in Filter Matching. In that case, the safest filter combination is applied.

Following is a step-by-step explanation of the filter selection methods.

Stage 1: determining e-mail addresses

The sender’s e-mail address is: mail@addr1 The recipient’s e-mail address is mail@addr2

Stage 2: assigning the e-mail policies
- For outgoing e-mails, only the sender’s policy is applied (stage 3).
- For incoming e-mails, only the recipient’s policy is applied .
- If the e-mail is external, meaning the e-mail is relayed for other MTAs, no policy exists for the sender or the recipient.
- If the e-mail is local, meaning the e-mail is sent between local AXS Guard users in the LAN, the sender and receiver policies apply. If both e-mail addresses have policies assigned, stages 3 and 4 are combined .

E-mail policies are assigned to the e-mail addresses of valid AXS Guard users. This is true for user e-mail addresses in the own domain, as well as for e-mail addresses in external domains. Existing policies are retrieved for the sender and the receiver if they exist.

Stage 3: Filter matching in sender’s policy, mail@addr1

Search for outgoing filter to match the recipient’s e-mail address: mail@addr2

Policy for `mail@addr1`
Incoming Filters			Outgoing Filters
Filter	Sender	Recipient	Filter	Sender	Recipient
In-Filter-w	`mail@addr2`	`mail@addr1`	Out-Filter-a	mail@addr1	mail@addr2
In-Filter-x	`mail@addr3`	Out-Filter-b	`mail@addr3`
In-Filter-y	`mail@addr4`	Out-Filter-c	`mail@addr4`

Stage 4: Filter matching in recipient’s policy, mail@addr2

Search for incoming filter to match the sender’s e-mail address: mail@addr1

Policy for `mail@addr2`
Incoming Filters			Outgoing Filters
Filter	Sender	Recipient	Filter	Sender	Recipient
In-Filter-w	mail@addr1	mail@addr2	Out-Filter-a	`mail@addr2`	`mail@addr1`
In-Filter-x	`mail@addr3`	Out-Filter-b	`mail@addr3`
In-Filter-y	`mail@addr4`	Out-Filter-c	`mail@addr4`

Stage 5: Combining an incoming and an outgoing filter

When two separate policies are applicable to a message, i.e. the sender and the recipient’s policies, the safest filter combination in the policies are applied .

Examples

In this section, we provide some examples of Content Filtering. The following examples are based on the stages explained in Filter Scenarios, using the mail policies below. owndomain can be a local or a forwarded domain.

Hotmail Policy ⇐ In Filter 1

Policy
domain / e-mail	all domains
action	allow e-mail if domain matches
extension blocking	none
spam checking	mark as spam: 5 / delete : 10
Forwarding	no e-mail address specified

Hotmail Policy ⇐ Out Filter 1

Policy
domain / e-mail	hotmail.com
action	allow e-mail if domain matches
extension blocking	block `.exe`
spam checking	mark as spam: 5 / delete : 10
Forwarding	no e-mail address specified

Hotmail Policy ⇐ Out Filter 2

Policy
domain / e-mail	`marc@hotmail.com`
action	allow e-mail if domain matches
extension blocking	none
spam checking	mark as spam: 5 / delete : 10
Forwarding	no e-mail address specified

Hotmail Policy ⇐ Out Filter 3

Policy
domain / e-mail	all local and forwarded domains
action	allow e-mail if domain matches
extension blocking	block `.com`
spam checking	mark as spam: 5 / delete : 10
Forwarding	no e-mail address specified

Internal Mail Policy ⇐ In Filter 2

Policy
domain / e-mail	all local and forwarded domains
action	allow e-mail if domain matches
extension blocking	block `.gif`
spam checking	mark as spam:2 / delete:11
Forwarding	no e-mail address specified

Internal Mail Policy ⇐ In Filter 3

Policy
domain / e-mail	`somebody@gmail.com`
action	allow e-mail if domain matches
extension blocking	none
spam checking	mark as spam:5 / delete:10
Forwarding	no e-mail address specified

Example 1: Mail from gerard@owndomain.com to marc@hotmail.com with .exe attachment

Step 1: Sender = gerard@owndomain.com; Recipient = marc@hotmail.com.
Step 2: This is an outgoing mail: the sender’s domain is an own domain and the recipient’s domain is an external domain. The matching policy, Hotmail , is applied to the sender address of the own domain. No policy has been defined for the external recipient.
Step 3: Using the “best match” principle, Outgoing filter 2 from the sender’s policy Hotmail is applied.
Step 4: No policy exists for the external recipient address, so no incoming filter can be assigned.
Step 5: Combining incoming and outgoing filters is not necessary, because only an outgoing filter has been assigned.
Result: Transmission of the e-mail with .exe attachment is allowed.

Example 2: Mail from gerard@owndomain.com to geoff@hotmail.com with .exe attachment

Step 1: Sender = gerard@owndomain.com; Recipient = geoff@hotmail.com
Step 2: This is an outgoing mail: the sender’s domain is an own domain and the recipient’s domain is an external domain. The matching policy, Hotmail , is applied to the sender address of the own domain. No policy exists for the external recipient.
Step 3: Using the “best match” principle, Outgoing filter 1 from the sender’s policy Hotmail is applied.
Step 4: No policy exists for the external recipient address, so no incoming filter can be assigned.
Step 5: Combining incoming and outgoing filters is not necessary, because only an outgoing filter has been assigned.
Result: The e-mail with the .exe attachment will be blocked and quarantined, due to extension blocking.

Example 3: Mail from gerard@owndomain.com to sarah@owndomain.com

Step 1: Sender = gerard@owndomain.com; Recipient = sarah@owndomain.com.
Step 2: This is an internal, local mail: The sender and the recipient domains are both own domains. The matching policies Hotmail and Internal are applied to the sender and the recipient.
Step 3: Using the “best match” principle, Outgoing filter 3 from the sender’s policy Hotmail is applied.
Step 4: Using the “best match” principle, Incoming filter 2 from the recipient’s policy Internal is applied.
Step 5: Outgoing filter 3 and Incoming filter 2 are combined to provide the safest options.
- action = allow e-mail if domain matches;
- extension blocking = block .com and .gif
- spam checking = mark as spam: 2 / delete: 11
- forwarding = (no address specified)
Result: Transmission of the e-mail is allowed.

Example 4: Mail from marc@hotmail.com to sarah@owndomain.com

Step 1: Sender = marc@hotmail.com; Recipient = sarah@owndomain.com
Step 2: This is an incoming mail; the sender’s domain is an external domain and the recipient’s domain is an own domain. No policy exists for the external sender, but the matching policy Internal (see above) is applied to the own domain recipient’s address.
Step 3: No policy exists for the external sender’s address, so no outgoing filter can be assigned.
Step 4: No matching incoming filter is found in the recipient’s policy Internal.
Step 5: Combining incoming and outgoing filters is not necessary, because no filters have been assigned.
Result: The e-mail is blocked, as no matching filter is found in the mail policy for e-mail address sarah@owndomain.com. This e-mail can be accepted by adding a “catch-all” filter for all domains as explained in Filters.

Example 5: Spam mail with spam score 11 from spammer@spam.com to gerard@owndomain.com

Step 1: Sender = spammer@spam.com; recipient = gerard@owndomain.com
Step 2: This is an incoming mail; the sender’s domain is an external domain and the recipient’s domain is an own domain. No policy exists for the external sender, but the matching policy, Hotmail (see above), is applied for the local domain recipient address.
Step 3: No policy exists for the external sender address, so no outgoing filter can be assigned.
Step 4: Using the “best match” principle, Incoming filter 1 from the recipient’s policy Hotmail is assigned.
Step 5: Combining incoming and outgoing filters is not necessary because only an incoming filter has been assigned.
Result: This e-mail is blocked as it is a spam message with a spam score of 11. This score exceeds the allowed spam score of 10 specified in the matching Incoming filter 1. The e-mail is deleted.

External E-mail Addresses

You can register external e-mail addresses on the AXS Guard, so that mail content filtering is applied at the user or the group level, e.g. for private e-mail addresses. The external e-mail address needs to be linked to a mail policy. When an e-mail is sent to the registered address, the adequate mail policy is automatically applied. The message is accepted or refused depending on the filters.

Filter Action

An e-mail is either blocked or allowed when it matches a filter. When an e-mail is allowed, there are 4 types of possible filter actions, which may appear individually in a filter or together (combined). The filter actions listed below are explained in the following subsections.

Extension blocking: e-mails containing potentially dangerous file extensions are blocked.
Spam checking: the e-mail is allowed or blocked depending on its spam score.
Forwarding: the e-mail is forwarded to a specific address or addresses.
Anti-virus scanning: the e-mail is scanned for viruses and malware.

Extension Blocking

This type of content scanning searches for certain file types attached to e-mails, targeted by a mail filter. Not only the extension, e.g. .exe, but also the exe file itself is checked for matching. This content check cannot be bypassed by renaming the file, e.g. to file.doc. The file will still be blocked by a filter blocking “executable” file types.

Extension blocking can be specified per filter, with one of two possible scenarios:

block all with certain specified exceptions;
allow all with certain specified exceptions.

A filter which blocks dangerous Microsoft extensions is pre-defined on the AXS Guard.

Zip Files

Password protected zip files are blocked by default on the AXS Guard. The reason is that the content of password protected zip files cannot be checked for potential viruses or malware without the password. Allowing these files may constitute a security risk. This security check is the only one on the AXS Guard MTA which cannot be overruled with a white list. The check can only be disabled system-wide.

Empty Files

If an attached file is empty, the AXS Guard MTA blocks it, even if its file extension is allowed by a Policy.

E-mail Quarantine

When an e-mail message has an attachment of a file type targeted for blocking or matches a manually defined black list, the message and its attachment(s) are moved to the Quarantine queue.

The AXS Guard administrator, sender and/or receivers are automatically notified depending on the configured settings. Administrators may view, release or delete a quarantined message . The message may also be downloaded. Caution is strongly advised when downloading a message, since delays in virus definition updates may cause you to inadvertently infect your machine.

The e-mail Quarantine system on the AXS Guard also has a built-in burst protection, which automatically deletes messages to prevent a system crash, i.e. in the event of a mail bomb. Messages over 10 days old are also automatically deleted (auto-cleanup system). Once a message has been removed from the Quarantine queue, either manually or automatically, it is permanently deleted and cannot be recovered.

Spam Checking

The content scanning system detects spam using certain characteristics of e-mail headers and content such as:

The e-mail priority
The number of uppercases
The occurrence of certain words like “viagra”, “porn”,..
The occurence of suspicious URLs (requires a DNS security license). When enabled, AXS Guard will analyze domains within emails using SecureDNS and DNS filters. If a domain is flagged as malicious, the spam score of the email will be automatically increased, ensuring it lands in the spam folder.

A spam score is calculated per e-mail. A low score indicates a low probability of the message being spam, a high score indicates a higher probability of the e-mail being spam. Filtering is based on the spam score. The detection mechanism for spam checking is updated by the AXS Guard revision system.

Two parameters can be configured in a filter:

Spam Tag Threshold: The tag “SPAM” is added to the subject field of e-mails with spam scores equal or higher than the entered value. This tag is added by means of a special X-header field, so that mail client filtering can be used to sort e-mails by their spam score.
Delete Spam Threshold: e-mails with spam scores equal or higher than this value are deleted. This level effectively defines the threshold above which the chances of the e-mail being correctly identified as spam are sufficiently high to justify immediate deletion.

If you wish to receive certain e-mails which are classified as spam by the AXS Guard, you need to create a separate filter with weaker spam filtering criteria. By adding this filter to a certain source e-mail address, the “best match” principle prioritizes this filter for all mails originating from the specified e-mail source. Spam settings for e-mails from all other sources remain the same. The default e-mail policy allows configuration of such sources. It is also possible to “train” the anti-spam system manually.

The AXS Guard offers the option to notify senders of spam. This is not recommended, because:

The sender e-mail addresses are unlikely to exist. Notifications therefore create needless network traffic.
You do not want to notify a spammer that your e-mail address is valid. If your e-mail address is “advertised” as valid, you run the risk of receiving even more spam. This also creates needless traffic and requires processing power.

Important

AXS Guard spam checks can be overruled by a white list.

E-mail Forwarding

Important

The use of this option may be subject to privacy laws and punishable by law. System Administrators are highly recommended to consult the local privacy acts and leglislation before using this option.

Mails matching a mail filter can be forwarded to one or more e-mail addresses, providing the forwarding addresses aren’t blocked by the content checking system. A forwarded e-mail is therefore delivered to its original destination and the specified forwarding address(es).

Anti-Virus Checks

Anti-virus scanning is applied to all incoming, local and outgoing mail. The AXS Guard anti-virus software is only available if purchased with the Content Scanning Module.

To optimize the security check procedure, e-mails are only scanned for viruses if they have not been rejected by an AXS Guard content filter, except for quarantined e-mails with potentially dangerous extensions, because these e-mails can be released by a system administrator.

E-mails in which viruses are detected are automatically rejected. The AXS Guard can be configured to send a notification to the sender, the recipient and the AXS Guard administrator whenever a virus is detected. Infected messages cannot be quarantined and their contents cannot be seen by AXS Guard system administrators. The last 32 infected messages are stored on the AXS Guard hard drive, but are only accessible to Able support engineers.

Sending notifications to the senders of infected e-mails is not efficient, because the sender’s address is often non-existent, which causes the notifications to be returned. This generates additional network traffic and unnecessary processing time.

Security Levels and Predefined Policies

User and group mail policies are assigned by identifying the user names in the e-mail addresses. Computer level policies are not subject to e-mail security. However, based on the same concepts applied to the security design of the AXS Guard Firewall and Web access, we recommend that default system-level policies are configured to be as restrictive as possible, to act as a safety net. To ensure maximum security, mail policies should be configured with increasing access restrictions in the order user, group and system.

Specificity of policies allows more control. E-mail policies should become increasingly specific in the order system, group and users. The configuration and assignment of policies depend on the specificity and user requirements, as illustrated below.

Pre-configured Policies

The AXS Guard provides three pre-configured policies as a starting point for mail filtering configuration. These are the internal mail policy, the default mail policy and the no-access mail policy. The default mail policy is the system level mail policy.

The pre-defined mail policies and filters can on be partially modified. You can, however, create customized filters based on the pre-defined filters with the Edit as New fuction.

Default Mail Policy

The default policy can be used to allow secure external and internal mail and contains 5 mail filters in total; 3 filters for outgoing mail and 2 filters for incoming mail:

Incoming Filters
default-in	This mail filter is used if no other filter matches. It is a safe filter to use, because it blocks all incoming potentially dangerous Microsoft executable extensions, Office macros and checks for spam. However, if e-mails important to your organization are being blocked by this filter due to spam checking or extension blocking, the source e-mail address can be added to the in-allow or in-allow-spam mail filter.
in-allow	This filter matches all the specified e-mail addresses (or domains) which are precluded from extension blocking and spam checks, i.e. mail addresses to which extension blocking does not apply. E-mail addresses and domains deliberately specified to be precluded from extension blocking are assumed not to require spam checking. This filter bypasses both extension blocking and spam checks. If you wish to apply spam checks without extension blocking, you should create a new filter.
in-allow-spam	This filter provides Microsoft executable extension blocking for the specified e-mail and domain addresses and precludes spam checks. This filter is useful to avoid important messages from being misidentified as spam. Potentially harmful file extensions are blocked.

Outgoing Filters
default-out	This filter blocks all dangerous Microsoft executable extensions and Office macros. This filter is used if no other filter matches. It doesn’t include spam checking, as outgoing mail from your LAN is unlikely to be spam. This is a safe filter to use, but if e-mails important to your organization are being blocked, the destination e-mail address can be added to the out-allow mail filter.
out-allow	This filter precludes the specified e-mail addresses and domains from extension blocking.

Internal Mail Policy

If your company policy only allows internal mail, you can use the internal mail policy, which allows transmission of all mail to and from own local and forwarded domains. No spam checking or extension blocking is performed, as the exchanged e-mails remain within the organization. To apply extension blocking to certain addresses, you need to create new mail filters.

No-Access Mail Policy

The e-mail system of the AXS Guard will be unavailable for specific users or groups when the no-access mail policy is assigned.

Automatic Spam Learning

Automatic White Listing

The AXS Guard anti-spam system includes a feature called automatic white listing. This feature adjusts the spam score calculated for a specific message based on the spam scores calculated for other mails originating from that sender. The score can be raised or lowered.

Automatic Bayesian Learning

Bayesian filtering works by gathering tokens, i.e. words or a part of a sentence, and assigning the number of their occurances in both spam and non-spam mail. Non-spam mails are also referred to as ham. Through this procedure it is possible to assign a spam probability to each token (0.01 for ham, 0.99 for spam).

The AXS Guard will automatically feed all e-mail messages to the bayesian learning system with spam scores lower than 0.1 and higher than 12. Tokens from mail messages with a score lower than 0.1 will be registered as non-spam tokens. Tokens from mail messages swith a score higher than 12 will be registered as spam tokens.

When a new message is received by the AXS Guard, the tokens with the highest or lowest number of occurances in both spam and ham mail are used to calculate the bayesian spam probability of this new message. The calculated spam score of the new message will be lowered or raised with an amount based on the bayesian spam probability.

The influence of the bayesian spam probability will only be taken into account when at least 200 spam and 200 ham e-mail messages are registered. The more messages are registered, the more accurate the system becomes. This is also referred to as “training”.

Manual Bayesian Learning

The AXS Guard automatic bayesian learning system can be trained manually to perform company tailored spam checking. It is possible to feed unrecognized spam mails (spam mail with a spam score lower than the delete threshold or spam mail without a score and non-spam mails detected as spam by the AXS Guard anti-spam system. In addition, e-mail messages not registered automatically, i.e. with spam scores higher than 0.1 and lower than 12, can be registered manually.

The following procedure can be used to train the Bayesian learning system:

Add unrecognized spam e-mail(s) to a new e-mail using drag and drop and send it to spam@domainname, e.g. spam@axsguard.yourdomain.com.
Add e-mail(s) which were mistakenly marked as spam to another e-mail using drag and drop and send it to notspam@domainname, e.g. notspam@axsguard.yourdomain.com.

Important

Both types cannot be mixed, i.e. added to the same e-mail. The hostname part, e.g. axsguard.yourdomain.com, can be left out in case your mail is delivered to the AXS Guard and not to an external mail server (i.e. a local domain).

Summary

In this section, we provide a summary of the items covered in this chapter in relation to the items which have been covered in MTA Relay Scenarios and Security Checks. The diagram below depicts the entire flow of MTA checks and content filtering before an e-mail is actually delivered or before it is quarantined.

Incoming Mail

The anti-relay check is the first check to be executed by the AXS Guard MTA when an e-mail arrives.

If the connection is not aborted during the anti-relay check, in other words if relaying is permitted, the AXS Guard MTA performs a range of standard security checks as explained in section Security Checks and its subsections.

Finally, the content of the message is scanned based on the applicable filters. The message is scanned for:

Potentially harmful extensions
Spam
Viruses and malware

If configured, the message can be forwarded.

Outgoing and Internal Mail

The content of the message is scanned based on the applicable filters. The message is scanned for:

Potentially harmful extensions
Spam
Viruses and malware

If configured, the message can be forwarded.

MTA Server Configuration

Overview

The topics covered in this chapter include, but are not limited to:

The MTA Feature Activation
How to set up an e-mail domain on the AXS Guard
How to configure notifications, such as delay notifications
How to enable the SPF Protection and configure other MTA options
How to add a disclaimer to outgoing messages
How to configure TLS

MTA Feature Activation

Log in to the AXS Guard appliance.
Navigate to System > Feature Activation.
Select E-mail in the left pane.
Enable the desired options.
Update your configuration.

Adding E-mail Domains

Mail is only accepted and processed for registered domains.

Navigate to E-mail > Domains.
Click on the + button (add new).
Enter a domain, e.g. mydomain.com.
Enter a description for the domain (optional).
Depending on the selected type, enter the settings as explained in the context-sensitive help.
Enable or disable masquerading for the domain.
Save your configuration.

Parameter	Description
Domain	The domain for which e-mail should be handled by the AXS Guard MTA.
Disabled	Disables the domain, e.g. for maintenance.
Local	Select this option if e-mails are stored locally on the AXS Guard. The e-mail server feature must be enabled under System > Feature Activation > E-mail.
Forwarded	Forwards e-mail traffic to the specified computer. The computer can be listed or unlisted. Listed means that the computer has been added to the AXS Guard computer list (under Computers). In case of an unlisted computer, enter the computer’s IP address or FQDN, e.g. computer.mydomain.com.
Forward port	the SMTP port on the computer to which e-mails are forwarded. The default SMTP port is 25.
Verify Recipient Address	If enabled, the recipient addresses of incoming mail for the specified domain are verified by initiating an SMTP connection to the server. If the server refuses delivery to the recipient, the AXS Guard will to. If the server is unreachable, the delivery of the e-mail will be postponed.
Relay Out	Relays outgoing e-mail traffic to a non-listed computer. Enter the computer’s IP address or FQDN, port number (default is 25) and authentication credentials (if required).
Masquerade	See Masquerading for details.

The e-mail will be rejected if the recipient address is invalid on the back-end mail server. Make sure your back-end mail server supports recipient address verification.
If an Exchange server is used in combination with the Verify recipient address option, you must disable tarpitting on the exchange server. If Verify recipient address is enabled, then the AXS Guard MTA waits 6 seconds before returning the following message: Recipient address rejected: unverified address: Address verification in progress. By default, tarpitting causes a delay of 5 seconds to be added to each transaction. Exchange only has 1 second to answer the request. If the exchange server is slightly loaded then it fails to answer in time.

DKIM Keys

Generating a Key Pair

Navigate to E-mail > DKIM Keys.
Click on the + button to generate a new DKIM key.
Enter the required information, select the appropriate algorithm and update your configuration.

Field Description

Name Enter a unique name to identify this DKIM key configuration.

Key Type Specifies the cryptographic algorithm to be used to generate the key pair.

DKIM TXT Record

Once the key pair is created, you can generate a DKIM TXT record for your mail domain.

DKIM TXT Record

Field	Description
Name	The name given to the DKIM key configuration.
Enabled	Activates or deactivates the usage of the DKIM key. If enabled, the key will be used to sign e-mails for the specified domain.
Description	An optional field for adding details about the DKIM key. Use it to provide contextual information, such as the purpose of the key or any other notes for future reference.
E-mail domain	The domain associated with this DKIM key. Ensure this domain matches the one specified in the `From: address` of your outgoing e-mails.
Selector	A DKIM selector is a unique identifier used in DomainKeys Identified Mail (DKIM) to specify which public key should be used to verify an e-mail’s signature. It allows domain owners to publish multiple DKIM keys, each identified by a different selector, in their DNS records.
Key Type	The cryptographic algorithm that was used to generate the key.
Public Key	This is the public DKIM key, which is used by receiving mail servers to verify your e-mail signatures.
Record Name	The DNS record to be published, e.g. `s1._domainkey.example.com`.
DKIM TXT Record	The TXT record value to be published in your DNS settings, including the public key and other DKIM parameters.

Configuration Flow

To add a DKIM TXT record to your DNS server, you'll typically need to follow these steps:

Generate a DKIM key pair and TXT record on AXS Guard.
Copy the record name and the DKIM TXT record value.
Log in to your DNS management console and access the control panel of your domain registrar or DNS hosting provider.
Add the new TXT record:
Important

The specific steps may vary depending on your provider, but generally, you'll need to provide the following information:
- Hostname: This is usually the selector (a short string) followed by ._domainkey.<yourdomain.com>. For example, s1._domainkey.example.com.
- TTL: This is the time-to-live, which determines how long the record is cached. A common value is 3600 (one hour).
- Value: This is the actual DKIM TXT record value you obtained in step 2. For example, v=DKIM1; k=rsa; p=GSIb3DQEBAQUAA4GNADCBi....
Once you've entered the information, save the new TXT record.

Example:

If your DKIM TXT record value is: v=DKIM1; k=rsa; p=GSIb3DQEBAQUAA4GNADCBi...
And if your selector is mail, you would add a TXT record with the following details:

Hostname: mail._domainkey.yourdomain.com
TTL: 3600
Value: v=DKIM1; k=rsa; p=GSIb3DQEBAQUAA4GNADCBi...

Tip

Online tools are available to help test the DKIM configuration for your mail domains, ensuring your email authentication is set up correctly. These tools verify that your DKIM records, such as the public key in your DNS, are properly configured and functioning as intended.

You can also verify your DKIM configuration using the dig or nslookup command, for example:

dig s1._domainkey.example.com txt.
nslookup -type=TXT s1._domainkey.example.com.

General Configuration Settings

Through this page, system administrators can configure a range of email server settings, including SMTP authentication, maximum message size, the system-wide mail policy, disclaimers, and spam settings.

Navigate to E-mail > Server.
Configure the settings as explained in the context-sensitive help or the table below.
Update your configuration.

Info

Each tab is also explained separately in the following subsections.

Type	Description
Postmaster for your domain	Check this option to enter the postmaster’s e-mail address, e.g. `postmaster@yourdomain.com` The postmaster is the person (administrator) who is responsible for the AXS Guard MTA. All error messages and alerts concerning the e-mail system are sent to the postmaster’s e-mail address. If no postmaster address is specified, alerts will be sent to the e-mail address provided under System > General.
Hide outgoing mail behind your domain?	If enabled, the AXS Guard will replace the domain string in e-mail addresses which belong to a subdomain of the AXS Guard. If no domain is detected in an outgoing message, the domain specified under System > General will be used. No changes are made in other cases. This option has an effect on sender and recipient addresses. It ensures that all e-mails leaving your network have a valid domain, regardless of the client settings on the sender’s computer.
E-mail max size	The maximum allowed size in megabytes of e-mails relayed by the AXS Guard MTA. If a message exceeds the specified size, it will be returned to the sender without being delivered.
Name to mail all users in local domains	Creates a broadcast address, e.g. mycompany-all. Mail sent to this address will be disseminated to all users in your local domains.
Exclude users from receiving mail sent to all users in local domains	Selected users will be excluded from receiving e-mail that was sent to the broadcast address, e.g. mycompany-all.
Do not allow mail to all users from the internet	If selected, the broadcast mailbox will not accept messages originating from the Internet. Messaging will be restricted to users in your secure network.
Mail Policy	The system-wide mail policy. Caution is advised, since this policy applies to all users and computers connected to the appliance’s network.
Allow SMTP Authentication	Use this option for telecommuters who need to send e-mail via the appliance’s MTA. This option requires authentication to be enabled on the mail client of the remote user. CAUTION: SMTP authentication bypasses the anti-relay and other MTA security checks. It is highly recommended to configure TLS for incoming connections when using SMTP authentication. Go to E-mail > TLS Policies > Local to configure a server certificate and TLS policies for SMTP traffic. Restrict user access to protect the server against brute-force attempts by creating appropriate authentication restrictions for SMTP. See Authentication > Advanced > Restrictions.
Run server with authentication on port	This field is visible only if SMTP authentication has been enabled. Specify the port number for SMTP authentication. Please note that the system default configuration is set to port 25. However, it's important to understand that this port is used solely for authentication purposes, while mail traffic is still handled through port 25.
Add disclaimer to outgoing mail	Select this option to add a legal or other type of disclaimer to outgoing messages. If checked, a new tab will become available to enter the text of the disclaimer. Text and HTML formatting are both supported.
Use an SMTP relay server	Check this option to use an SMTP relay server, e.g. your ISP’s SMTP server. If checked, a new tab will become available to enter the SMTP relay information. Enter the relay server’s IP address or its FQDN.
Maximum queue time in days	This value determines how long a message should be kept in the mail queue when the recipient’s mail system is unavailable. The AXS Guard mail system will keep trying to deliver the message until the specified queue time is exceeded and notify the sender, after which the queued message will be deleted.
The number of days to keep deleted spam	Spam that has been quarantined, will be permanently deleted after the specified period. 30 days is the system default.
Name to use for HELO/EHLO greeting	A name that is used to identify the appliance with other SMTP servers.
Stop spam scanning after specific size	This option allows you to change the maximum size of a message that will be scanned for spam. The default maximum size is 400KB. Spam will typically be much smaller, as spammers rely on the sheer number of messages sent.
Spam subject tag	Specify a string to be added to the subject field of spam messages. `*SPAM*` is the system default.
Trusted relays for spam checking	IP address(es) of trusted MTAs. Message headers added by these servers will be considered as safe by the spam checking system, resulting in a more efficient anti-spam system.
Auto-response active	System-wide auto-response. If enabled, the system will automatically send an automated response on behalf of all users.

Important

Always use the strictest mail policy at the system level.

SPF Settings

Navigate to E-mail > Server.
Select SPF Settings.
Configure the SPF settings and update your configuration.

Parameter	Description
Activate SPF protection	The Sender Policy Framework (SPF) is an e-mail authentication system designed to prevent e-mail source address spoofing, a popular practice used by spammers, resulting in backscatter. Mail exchangers that use SPF, check the sender’s identity against the DNS record’s contents and reject the message if the domain string in the sender’s address does not match.
Do not perform SPF check for the following servers	Specify servers for which SPF checks should not be performed. The following entries are valid: FQDN, IP or IP range (CIDR notation).

SMTP Relay Server Settings

The following tab and options are only available if the Use an SMTP Relay server? option has been enabled.

Navigate to E-mail > Server.
Select the SMTP Relay Server Settings tab.
Configure the SMTP Relay Server settings and update your configuration.

Option	Description
SMTP relay computer	Enter the FQDN or IP address of an SMTP relay server, e.g. the IP address of your ISP's SMTP server. Use this field if your AXS Guard appliance has a public IP address which is dynamically assigned by your ISP. AXS Guard will automatically attempt to connect to the configured SMTP server on TCP ports 587, 25, and, if necessary, 2525 in the listed order.
Use deprecated SMTPS	If the configured SMTP relay cannot be reached via the standard SMTP ports (587, 25 or 2525), emails can be relayed by using the deprecated SMTPS protocol over TCP port 465.
Authenticate?	Enable this option if credentials are required to log in to the SMTP relay server.
Remote username	Enter the SMTP relay username.
Password	Enter the SMTP relay password.
Password Verify	Enter the SMTP relay password again for verification.

Real-time Blacklists (RBL)

Important

Disabling the RBLs will result in more spam.

Navigate to E-mail > Server.
Click on the Free Realtime Black Lists (RBL) Tab.
Enable / Disable the desired RBL.
Click on Update when finished.

Option	Description
Use sbl.spamhaus.org?	See http://www.spamhaus.org/ for additional information.
Use xbl.spamhaus.org?	See http://www.spamhaus.org/ for additional information.
Use pbl.spamhaus.org?	See http://www.spamhaus.org/ for additional information.
Use bl.spamcop.net?	See https://www.spamcop.net/ for additional information.
Use cbl.abuseat.org?	See http://cbl.abuseat.org/ for additional information.
Use dul.dnsbl.sorbs.net?	See http://www.sorbs.net/ for additional information.

Security Checks

Navigate to E-mail > Server.
Click on the Security Checks Tab.
Enable / Disable the options according to your needs.
Click on Update when finished.

Option	Description
Use realtime black lists (RBL)?	Check to use the blacklist.
Enable bad header check	Per RFC, an e-mail header must only contain ASCII characters. Mails which deviate from the RFC. If enabled, messages containing bad headers are automatically rejected by the AXS Guard MTA.
Enable HELO message check	MTAs exchange identification information via the “HELO FQDN” command. The FQDN (Fully Qualified Domain Name) is the name of the MTA issuing the command. If enabled, the AXS Guard MTA only accepts the connection if the FQDN of the sending MTA is properly formatted. If an invalid FQDN is used in the helo command, mail originating from the sending MTA is automatically rejected. In a nutshell, e-mails from MTAs which do not identify themselves properly will be rejected.
Reject e-mail addresses of own domains from non-secure connections	Prevents e-mail spoofing. E-mail spoofing is a technique commonly used for spam and phishing to hide the origin of an e-mail message. The result is that, although the e-mail appears to come from the address indicated in the `From` field (found in the e-mail headers), it actually comes from another source.
Reject username as recipient address from non-secure connections	Many MTA administrators use initials in e-mail addresses for easy maintenance, e.g. `abc@somewhere.com`. Such e-mail addresses are more susceptible to spam abuse, because the number of permutations needed to guess the user names is very limited (3 letter combinations are easier to guess than full names). The AXS Guard MTA can be configured so that these user names are rejected if used in an e-mail originating from a non-secure (Internet and DMZ) source. If the security check is enabled, only secure LAN and VPN users may use short names when sending e-mails to each other. Users outside the secure LAN must use the longer alias, e.g. `alpha.beta@somewhere.com`.

Quarantine Settings

To configure the number of messages that must be kept in the quarantine queue:

Select Quarantine Settings.
Specify the maximum amount of messages to be kept in the quarantine queue. 300 is the default amount.

Parameter	Description
Maximum number of messages in the quarantine queue	The maximum amount of messages to be kept in the quarantine queue. 300 messages is the default amount.
Maximum number of days in the quarantine queue	The maximum amount of days that messages are to be kept in the quarantine queue prior to being deleted. 10 days is the system default.

System-wide Auto Response Settings

Field	Description
Start	Enter a start date for the automated response in the DD/MM/YYYY HH:MM format.
End	Enter an end date for the automated response in the DD/MM/YYYY HH:MM format.
Notify sender	Select a frequency for automated responses. For example, `one time` means that only the first message from a given sender will trigger an automated response. Subsequent messages from the same sender will not trigger an automated response.
Auto-response subject	The subject of the automated reply.
Auto-response message	The body of the automated reply. For example, an out of office message.

Notification Settings

The AXS Guard MTA can be configured to automatically notify the postmaster of certain events, e.g. when an e-mail has been bounced.

In this section we explain how to configure the AXS Guard MTA notification settings. Topics covered in this section include:

Delivery Notifications
MTA Security Check Notifications
Content Scanner Notifications
Anti-Virus Notifications
Quota Notifications

Delivery Notifications

Navigate to E-mail > Notifications.
Click on the Delivery Notifications Tab.
Enable / disable the options as explained in the context-sensitive help.
Update your configuration.

Option	Description
Send bounce notification to administrator?	A bounced message is a message that has been accepted by the AXS Guard Mail Transfer Agent (MTA), but has not been delivered. This occurs when, for example, the quota in the destination mailbox has been exceeded. This is sometimes also referred to as a "soft bounce". Messages are returned to the source address as a notification. Enable this option to send a copy of each notification message to the AXS Guard postmaster. The postmaster copy is restricted to the original message headers to maintain the privacy and confidentiality of the message body.
Send double bounce notification to administrator?	A "double bounce" refers to a "bounced" notification message sent by the AXS Guard which, in turn, is also bounced by the destination Mail Transfer Agent (MTA), for example when the user no longer exists on the destination MTA. Check this option to send a copy of any double bounce notification to the AXS Guard postmaster.
Send delay notification to sender?	Messages which cannot immediately be delivered are queued. If this option is enabled, the sender will be notified when a message has been queued.

MTA Security Check Notifications

Navigate to E-mail > Notifications.
Click on the MTA Security Check Notifications Tab.
Enable / disable the options as explained in the table below.
Update your configuration.

Option	Description
Notify administrator of rejected e-mail?	Check this option to send a copy of mail exchange transaction details to the AXS Guard postmaster when an e-mail is rejected during the conversation with the remote Mail Transfer Agent (MTA), e.g. due to Black lists matches or Helo command rejections. This option does not cover rejections of e-mails by the AXS Guard mail content filtering system, e.g. Bad Header checks.
Notify Bad Header Sender?	Per RFC, all characters in an e-mail header, including the subject, may only contain ASCII characters, i.e. a code which represents English characters as numbers . Messages containing invalid ASCII characters are usually malicious and are therefore rejected by the AXS Guard Mail Transfer Agent. Check this option to notify senders when an e-mail has been rejected.

Content Scanner Notifications

Navigate to E-mail > Notifications.
Click on the Content Scanner Notifications Tab.
Configure the options as explained in the table below.
Update your configuration.

Option	Description
Notify administrator of quarantined e-mail?	If checked, the postmaster is notified when e-mails are quarantined.
Notify internal sender of quarantined e-mail?	Check this option to only notify senders of local and forwarded domains when their e-mail has been quarantined.
Notify external sender of quarantined e-mail?	Check this option to notify external senders if their e-mail has been quarantined.
Notify internal recipient of quarantined e-mail?	Check this option to notify recipients in local and forwarded domains if their e-mail has been quarantined.
Notify external recipient of quarantined e-mail?	Check this option to notify external recipients if their e-mail has been quarantined.
Notify Spam Sender?	Check this option to notify senders when their message has been marked as spam.

E-mail Anti-Virus Notifications

Navigate to E-mail > Notifications.
Click on the E-mail Anti-Virus Notifications Tab.
Configure the options as explained in the table below.
Update your configuration.

Parameter	Description
Alert administrator of virus e-mail?	This option is enabled by default and sends a warning message to the system administrator(s) when viruses are detected in incoming e-mails.
Specify other e-mail address to send virus alerts?	Check this option to send a warning message to other specific recipient to be notified.
Notify sender of e-mail?	Check this option to send a warning message to the sender when an infected e-mail has been detected.
Notify recipient of e-mail?	Check this option to send a warning message to the intended recipient when an infected e-mail has been detected.

Quota Notifications

Navigate to E-mail > Notifications.
Click on the Quota Notifications Tab.
Select the desired options, as explained in the table below.
Update your configuration.

Parameter	Description
Send quota notification to Administrator	Notifies the system administrator as specified under System > General about the storage that remains available for each mailbox (the soft and hard limits).
Send quota notification to User	Notifies the user about the remaining size of his / her mailbox (the soft and hard limits).
Specify other e-mail address to sent quota notification	Sends quota notifications to the specified e-mail address(es).
Check the size of the user mailboxes	Select the desired frequency from the drop-down list.
Allow user to request quota status by sending an e-mail to `quota-status@domain`	Users can send an empty message to `quota-status@<systemdomain>` to receive a summary of their current mailbox quota. This only works if the message is sent from a secure or whitelisted network. `quota-status` is a reserved system name and cannot be modified.

Info

See the AXS Guard Mail Storage How To for additional information about mail quotas.

Creating Black Lists

Navigate to E-mail > Filters > Black List.
Enter the settings as explained in section Black Lists.
Save your list.

Info

You can create new black list based on existing black lists with Edit as New.

Option or Parameter	Description
Name	Enter a name using lower cases without spaces. Start with an alphabetic character, followed by any number of alphanumeric characters and/or the special characters: back slash (), hyphen (-), underscore (_), full stop(.), and the "at" sign (@).
Enabled	Enables the list if checked.
Description	Add a description for the blacklist (optional field).
Match on	Select the message attribute to match with. Specific e-mail addresses Specific text strings in the e-mail body, header or both Specific IP address(es)
E-mail match properties	Apply to: match with the sender, the receiver or both addresses. E-mail or Domain Name?: Select whether the black list should match an e-mail address or a domain name. Domain to match: If you selected to match a domain, enter the domain to be matched (unless overruled by a more specific entry in the white list). Check `Include sub-domains` if you want to match any sub-domains. E-mail address to match: If you selected to match an e-mail address, specify the e-mail address to be matched. You can select to match the sender and/or the recipient e-mail address (unless overruled by a more specific entry in the white list). Wild characters can be used to define patterns: a question mark (?) matches any character, e.g. the e-mail address `b?rt@example.com` matches `bert@example.com` and `bart@example.com`; an asterisk () matches zero or any character, e.g.`peter@example.com` matches `peter@example.com`, `peter.van.den.broek@example.com`, `peterjackson@example.com`, etc. Include sub-domains: Enter all sub-domains to be matched. For example, `domain.com` matches with `test@domain.com` and `test@just.a.domain.com`, but not with `test@mydomain.com`.
Text match properties	Apply to: This option becomes available if you have selected to match with the e-mail header or body. Select whether the body, header or both should be scanned for matches. Match Type: Select text or regular expression. Regular expressions are more advanced and allow you to match a sequence of symbols and characters expressing a string or pattern to be searched, using wildcards and regex syntax. Text to match: Performs a case-insensitive search. Enter the text to be matched. The text will not be blocked if a more specific entry exists in a white list. This option does not support wildcards. Regular expression to match: Use a regular expression to define a search pattern. Note: The e-mail subject belongs to the e-mail body.
IP address match properties	Enter the IP address(es) of the MTA(s) to be matched.
Action	Select the action to perform when a match occurs. Reject: the message is blocked and removed. Quarantine: the message is blocked and quarantined. A quarantined message can be inspected via the quarantine status page under E-mail > Status.
Message	Enter a sender notification. The notification is sent by the MTA when an e-mail has been rejected.

Creating White Lists

Navigate to E-mail > Filters > White List.
Enter the settings as explained in the table below.
Save the list.

Info

Use Edit as New to create while lists based on predefined white lists.

Option or Parameter	Description
Name	Enter a name using lower cases without spaces. Start with an alphabetic character, followed by any number of alphanumeric characters and/or the special characters: back slash (), hyphen (-), underscore (_), full stop(.), and the "at" sign (@).
Enabled	Enables the list if checked.
Description	Add a description for the blacklist (optional field).
Match on	Select the message attribute to match with. Specific e-mail addresses Specific text strings in the e-mail body, header or both Specific IP address(es)
E-mail match properties	Apply to: match with the sender, the receiver or both addresses. E-mail or Domain Name?: Select whether the black list should match an e-mail address or a domain name. Domain to match: If you selected to match a domain, enter the domain to be matched (unless overruled by a more specific entry in the white list). Check `Include sub-domains` if you want to match any sub-domains. E-mail address to match: If you selected to match an e-mail address, specify the e-mail address to be matched. You can select to match the sender and/or the recipient e-mail address (unless overruled by a more specific entry in the white list). Wild characters can be used to define patterns: a question mark (?) matches any character, e.g. the e-mail address `b?rt@example.com` matches `bert@example.com` and `bart@example.com`; an asterisk () matches zero or any character, e.g.`peter@example.com` matches `peter@example.com`, `peter.van.den.broek@example.com`, `peterjackson@example.com`, etc. Include sub-domains: Enter all sub-domains to be matched. For example, `domain.com` matches with `test@domain.com` and `test@just.a.domain.com`, but not with `test@mydomain.com`.
Text match properties	Apply to: This option becomes available if you have selected to match with the e-mail header or body. Select whether the body, header or both should be scanned for matches. Match Type: Select text or regular expression. Regular expressions are more advanced and allow you to match a sequence of symbols and characters expressing a string or pattern to be searched, using wildcards and regex syntax. Text to match: Performs a case-insensitive search. Enter the text to be matched. This option does not support wildcards. Regular expression to match: Use a regular expression to define a search pattern. Note: The e-mail subject belongs to the e-mail body.
IP address match properties	Enter the IP address(es) of the MTA(s) to be matched.
White list options	Select the action to perform when a match occurs. Check for spam: Select this option if a matching e-mail should not be allowed to bypass the spam checks of a matching filter. This ensures that e-mails matching a white list also undergo spam checks. Apply security checks: Enable if a matching e-mail should not be allowed to bypass the appliance’s Mail Transfer Agent security checks. Examples include, but are not limited to Internet black lists, bad header and Helo message checks. This ensures that e-mails matching a white list also undergo MTA security checks.
Message	Enter a sender notification. The notification is sent by the MTA when an e-mail has been rejected.

Greylisting Options

Navigate to E-mail > Filters > Grey Listing.
Enter the settings as explained in the table below.
Update your configuration.

Options and Parameters	Description
Enable Greylisting	Check this option to enable greylisting.
Delay before accepting retry (in seconds)	This is the required minimal delay between transmission attempts. Any attempt made before this timeout will be ignored and will also reset the counter.
Delete entries older than (days)	Entries older than the specified period are automatically removed.
Successful deliveries before whitelisting server	If this amount has been reached (e-mails from the sending MTA were accepted), the sending MTA is automatically white-listed. New e-mails originating from white-listed MTAs are no longer grey-listed.
Server must retry within (days)	Grey-listed e-mails which are not resent within the specified period will be discarded.
Whitelist Mail Server	Mail servers can be manually whitelisted by adding their IP address or FQDN to the greylisting database. Domains can also be whitelisted. If a domain is whitelisted, any of its subdomains will also be automatically whitelisted.
Whitelist Recipient	Exceptions can be set for recipients by adding their e-mail address to the Grey Listing database. greylisting is not applied when e-mails are sent to the specified recipient(s).
Reset database button	Clears the collected triplets from the greylisting database when pressed.

TLS Policies

In this section, we explain how to configure TLS. Topics covered in this section include:

AXS Guard Server Certificate Settings and enabling TLS
General configuration for incoming connections
General configuration for outgoing connections
TLS Policies (to override the general configuration on a case-by-case basis)

Important

To generate certificates, the AXS Guard CA must be initialized. Go to PKI > Certificates for an overview of certificates on your system or to import and generate new certificates. See the PKI How To for further information.

System-wide TLS Policies

Navigate to E-mail > TLS Policies > System-wide.
Select Incoming Connections.
Enable TLS.
Select the desired Security Level.
You can optionally require a client certificate and specify the Verification Depth .
Update your configuration.

Parameter	Description
Enabled	Check to enable TLS for incoming and outgoing mail transfers.
Certificate	Select the desired certificate from the drop-down list. Go to PKI > Certificates for an overview of certificates on your system or to generate and import new certificates.
Security level for incoming connections	none: TLS is not allowed. may: If the client attempts to encrypt the communications channel, TLS is used. If not, the appliance falls back to unencrypted communications. This method requires no pre-arrangement between clients and the appliance. encrypt: TLS is required for all clients.
Require certificate?	The SMTP server can be configured to verify client certificates to control access. When the option is enabled, the SMTP server will explicitly ask clients for a certificate when TLS is required.
Verification depth	The verification depth determines how far the certificate chain should be checked by the MTA prior to accepting a client certificate. Verification stops at the specified depth. The factory default value is 9.
Security level for outgoing connections	Select the system-wide default security policy for outgoing connections. This configuration applies to any domain. Go to TLS > Policies to configure TLS policies for specific domains.
Verification depth	The verification depth determines how far the certificate chain should be checked by the MTA prior to accepting the certificate of relay servers. Verification stops at the specified depth. The factory default value is 9.

Domain-specific TLS Policies

Navigate to E-mail > TLS Policies> Domain-specific.
Enter a policy name.
Provide a description (optional field).
Enable the policy.
Add the domain(s) for which the policy must be applied.
Select the desired security level.
Save your configuration.

Parameter	Description
Enabled	Check to enable this TLS policy.
Description	Describe the policy (optional field).
E-mail domains	Add the domains for which the TLS policy must be applied.
Security level	Select the security policy to be applied: none: TLS is not used for outgoing mail traffic. may: TLS is allowed, but not required for outgoing mail traffic. encrypt: TLS is always required for outgoing mail traffic.

Content Filters and Policies

Overview

Topics covered in this chapter include:

How to add external e-mail addresses.
How to configure and build in and out filters.
How to add the in and out filters to an e-mail policy and in turn assign the policy to the system, a group or a user.

External E-mail Addresses

Navigate to E-mail > Filters > External Addresses.
Enter the settings as explained in the context-sensitive help.
Save your configuration.

Parameter	Description
Name	Enter a name, using lower cases without spaces. Start with an alphabetic character, followed by any number of alphanumeric characters and/or special characters: back slash (), hyphen (-), underscore (_), full stop(.), and the "at" sign (@).
Enabled	Check to allow e-mails from the specified e-mail address.
Description	Add a description (optional field).
E-mail address	Enter the external e-mail address (belonging neither to a local nor a forwarded domain).
Overrule system level mail policy?	The system-wide policy under E-mail > General is applied by default. Check to select an alternative mail policy for the specified e-mail address.
Mail Policy	Select the desired e-mail policy for this address. Go to E-mail > Filters > Policies to view, configure or edit existing e-mail policies.

Creating Filters

In this section we explain how to create and configure in and out filters. Once the filters have been created, they must be added to a policy, which in turn needs to be assigned to a group, a user or to the system.

Important

Always use the strictest settings at the system level.

Filters for Incoming E-mail

Navigate to E-mail > Filters > In.
Click on Add new.
Navigate through the tabs and enter the filter matching criteria.
Save your configuration.

Options and Parameters	Description
Name	Enter a name for the new filter. Use lower cases without spaces. Start with an alphabetic character, followed by any number of alphanumeric characters and/or special characters: back slash (), hyphen (-), underscore (_), full stop(.), and the "at" sign (@).
Description	Add a description for the filter (optional field).
Sender e-mail address	Apply to all local and forwarded domains: applies to all the local and forwarded domains registered on the appliance under E-mail > Domains. Apply to all domains: the filter always matches, unless a more specific filter is added which takes priority based on the best match principle. This allows the definition of a catch-all filter. A catch-all filter applies to all e-mail addresses not matching any other filters. This is a method to prevent the automatic rejection of all e-mails which do not match other filters. Apply to specific domains and/or e-mail addresses: Enter the domains and/or e-mail addresses in a comma-separated list without spaces. If a domain is added, its sub-domains are also matched. E.g. `domain.com` matches `test@domain.com` and `test@just.a.domain.com`, but not `test@mydomain.com`.
Action	Select the appropriate action from the drop-down list. Pass e-mail if the domain matches Reject e-mail if the domain matches
Block extensions	Enable to block e-mail attachments based on their extension. Scenario: You can either allow all extensions and specify exceptions or block all extensions and specify exceptions. Click the radio button to select the desired scenario. List of blocked extensions: Enter the extensions to be blocked in a comma-separated list without spaces, e.g. `xls,exe,bat,com`. List of allowed extensions: Enter the allowed extensions in a comma-separated list without spaces, e.g. `xls,exe,bat,com`.
Block Microsoft Office Documents with macros	Macros can use the VBA SHELL command to run arbitrary commands and programs or use the VBA KILL command to delete files on your hard drive. After a malicious macro is loaded into an Office application like Word via an infected document, it can use features like “AutoExec” to automatically start with Word or “AutoOpen” to automatically run whenever you open a document. This means the macro virus can integrate itself into Word, infecting future documents.
Block encrypted archives	Blocks encrypted (password-protected) zip, 7zip and rar archives if enabled. Such files may constitute a security risk as their contents cannot be verified. Disabling this option is therefore not recommended.
Spam Checking	If enabled, e-mails are examined and assigned a spam score. Label as spam above this threshold: E-mails with a higher score are marked as spam in the subject field of the e-mail. The spam score is mentioned as well. The default threshold is 5. Delete spam automatically: Check to automatically delete spam. If you prefer to keep the e-mails for further investigation, regardless of their spam score, leave this option unchecked. Delete e-mail exceeding the spam threshold of: Enter the threshold above which spam should automatically be deleted. The default threshold is 10.
Forwarding	Enter one or more e-mail addresses to which all matching e-mails must be forwarded. Use a comma-separated list without spaces. The use of this option may be subject to privacy laws in your country. Use with care.

Filters for Outgoing E-mail

Navigate to E-mail > Filters > Out.
Click on Add new.
Navigate through the tabs and enter the filter matching criteria.
Save your configuration.

Creating Policies

Go to E-mail > Filters > Policies.
Click on Add new.
Configure the policy as explained below.
Save the policy.

Option	Description
Name	Add a name for the policy. Use lower cases without spaces. Start with an alphabetic character, followed by any number of alphanumeric characters and/or special characters: back slash (), hyphen (-), underscore (_), full stop(.), and the "at" sign (@).
Description	Enter a description which explains the goal of the policy. This field is optional.
Enabled	Check to enable the policy.
Filters for incoming e-mail	Add filters for incoming e-mail traffic as configured under E-mail > Filters > In.
Filters for outgoing e-mail	Add filters for outgoing e-mail traffic as configured under E-mail > Filters > Out.

Policy Assignment

To be in effect, a policy must be assigned to an AXS Guard security level. See the AXS Guard System Administration How To for information about security levels. This guide can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.

A policy can be assigned:

At the user level
At the group level
At the computer level (only the system-wide policy can be assigned)
System-wide

Important

Always use the strictest settings for system-wide policies. Able recommends the system-default policy, which provides the best e-mail security.

System-wide Assignment

Navigate to E-mail > Server.
Select the desired mail policy from the drop-down menu.
Update your configuration.

Computer-level Assignment

Go to computers.
Configure the settings as explained below.
Update your configuration.

Field	Description
Computer Name	Enter a name for the computer, using lower cases without spaces, starting with an alphabetic character, followed by any number of alphanumeric characters and/or the special characters: hyphen (-) and full stop(.) If possible, use the name of your computer, as defined in your Network / Properties / Identification tab (where the computer name is listed) since this is usually unique. The entered computer names and aliases are added to the internal DNS system of the AXS Guard appliance.
Enable Computer	Check to enable (default setting). Uncheck to disable. If disabled, system-level or user-level policies will be applied for web access, authentication, the firewall and SRV records. When a computer is disabled, its SRV record is not added to the internal DNS repository of the AXS Guard appliance.
Alias Names	You can add several names for a computer, providing the names adhere to the same specifications as for the Computer Name . All aliases are added to the AXS Guard internal DNS server. Computer names, computer aliases, device names and device aliases need to be unique in the network.
IP address	Enter the IP address of the computer to be added. IP addresses of computers must be unique. If you want a certain IP address to be known under (a) different name can be added in Alias Names as described above.
This computer can receive SMTP mail	Enable this option if the computer is running an SMTP mail server. This may be the case, for example, if the mailboxes on the AXS Guard appliance aren’t used, but e-mail is forwarded from the AXS Guard appliance to an Exchange server instead.
Use system mail policy when no other policy can be found	This option is only visible if the option above is enabled. Enable the option if the computer is a mail server where each user can control his/her own e-mail forwarding. In this case, e-mails could be sent to the AXS Guard mail content filtering system where both the sender and recipient addresses don’t belong to local or forwarded domains. Without activating this option, these e-mails would be blocked, as no mail policy is assigned. Activating this option will enable the AXS Guard to handle the computer’s mail traffic using the system mail policy as defined under E-mail > General.

Group-level Assignment

Navigate to Users & Groups > Groups.
Select the desired group.
Configure the policy settings under the E-mail tab.
Update your configuration.

Parameters	Description
Overrule System Mail Policy	Check this option to overrule the system-wide e-mail policy, which is configured under E-mail > General. Select the desired alternate policy from the drop-down list. Go to E-mail > Filters > Policies for an overview of defined policies.
Allow access to Webmail	Check this option to allow access to the appliance’s webmail server for the members of this group.

User-level Assignment

Navigate to Users&Groups > Users.
Select the desired user.
Configure the settings under the e-mail tab.
Update your configuration.

Field	Description
E-mail alias list	An e-mail alias allows system administrators to link one or more alternate e-mail addresses to a single mailbox. Aliases can be added as a name, e.g. `alias` or as an e-mail address, e.g. `alias@domain.com`. In the first case, messages sent to the alias will be delivered to all the user’s AXS GUARD mailboxes in non-virtual domains. In the second case, mail sent to the alias will only be delivered to the associated mailbox.
Overrule Group Mail Policy	Check this option to overrule the user’s group policy. The group policy is configured under Users & Groups > Groups. Go to E-mail > Filters > Policies for an overview of defined e-mail policies on your system.
Delete incoming mail immediately	Check to delete incoming messages for the user. Use this option for inactive accounts to preserve disk space, e.g. when a user no longer works for your company. You can combine this option with the auto-response option to notify senders that the account is no longer in use.
Forwarding Enabled	Check this option to specify a forwarding address.
Store copy on AXS GUARD	Check to preserve a copy of forwarded e-mails on the appliance.
Auto-response active	Check to enable automated responses.
	Start: Enter a start date for the automated response in the DD/MM/YYYY HH:MM format.
	End : Enter an end date for the automated response in the DD/MM/YYYY HH:MM format.
	Notify sender: Select a frequency for automated responses. For example, `one time` means that only the first message from a given sender will trigger an automated response. Subsequent messages from the same sender will not trigger an automated response.
	Auto-response subject: The subject of the automated reply.
	Auto-response message: The body of the automated reply. For example, an out of office message. The following variables can be used in your message: `$SUBJECT`: The subject of the e-mail being replied to. `$START`: When the out of office period starts. `$END`: When the out of office period ends. The substitutions for the `$START` and `$END` variables include the time if they are less than 32 hours apart (a full day + a working day).
Mailbox Quota Warning	Once this limit is reached, the appliance automatically sends a warning to the user and the system administrator, requesting the user to remove or archive messages.
Mailbox Quota Limit	The maximum amount of disk space that may be used by the user’s mailbox. When exceeded, no new e-mails can be sent or received by the user. The user first needs to remove or archive excess messages.
Allow access to Webmail	Allow or deny access to the appliance’s webmail server. Use group configuration: Apply the user’s group settings. Go to Users & Groups > Groups and select the user’s group to view the webmail configuration. On: Webmail access is granted, even if not allowed in the user’s group configuration. Off: Webmail access is denied, even if allowed in the user’s group configuration.

Distribution List Policies

Navigate to E-mail > Distribution List.
Click on Add new.
Enter the settings as explained in the table below.
Save your configuration.

Important

In AXS Guard version 8.1.0 and earlier versions, the mail policy of eachindividual user that is part of a distribution list is used to determine whether or not the user can receive messages sent to the distribution list address.

As of version 8.2.0, the mail policy can be configured at the distribution list level. The system mail policy is applied by default. If a strict mail policy has been assigned at the system level, then mail to members of the distribution list may get blocked, even if those members have been assigned individual mail policies that are less strict.

Field	Description
Name	A name for the distribution list. Invalid characters are not accepted.
Description	Provide a description for the distribution list (not required).
Distribution e-mail address	Enter the address without the domain name; rather than entering `all@mydomain.com`, just enter `all`.
Domain	Select the domain of the distribution address, e.g.`mydomain.com`. Go to E-mail > Domains to view all configured domains.
Overrule System Mail Policy	Check this option to overrule the system mail policy as configured under E-mail > General. Go to E-mail > Filters > Policies for an overview of available policies or to configure a new policy.
Recipients	Local Users: Add recipients as listed under Users & Groups > Users. Added recipients will receive a copy of mails sent to the distribution address. Local Groups: Add groups as listed under Users & Groups > Groups. Members of added groups will receive a copy of mails sent to the distribution address. External users or list names: Enter the e-mail address(es) of the external recipient.
Auto-response active	Sends an automated response according to the configured settings.
Accessibility	Allow access from anywhere: Select this option to allow anybody to send messages to the distribution e-mail address. If enabled, messages coming from the Internet will be accepted and relayed. Restrict access to internal use: If selected, the broadcast mailbox will not accept messages originating from the Internet. Messaging will be restricted to users in your secure network.

Remote Mailbox Configuration

Overview

In this chapter, we explain how to configure the remote mailbox feature. To use this feature, the AXS Guard e-mail server must be enabled. Topics covered in this section include:

The configuration of remote e-mail account settings, regardless of the selected delivery.
How to retrieve mail from a remote mailbox for a single, local AXS Guard user.
How to retrieve mail for a non-AXS Guard mailbox, e.g. a mailbox on a MS Exchange server in your local network.
How to retrieve mail from a remote mailbox for multiple local users based on the e-mail headers in the messages on the remote server.

Account Settings

Log in to the appliance.
Navigate to E-mail > Remote Mailboxes.
Click on Add New.
Enter the options and parameters as explained in the table below.
Save your configuration.

Parameter	Description
Name	Enter a name for the remote mailbox. Use lower cases withouts spaces. Entries are validated.
Description	Enter a description for the remote mailbox (optional field).
Enabled	Check to enable e-mail retrieval according to the frequency specified below. If the option is disabled, mails will not be retrieved, but your configuration settings will remain on the appliance in case you wish to enable retrieval in the future.
Check for mail every	Enter the desired frequency. The system default is 5 minutes.
Remote Account Settings	Remote Mail Server: Enter the FQDN or the IP address of the remote mail server. Protocol: Select the protocol used by the remote mail server (POP or IMAP). Use SSL: Check this option if the remote mail server uses the Secure Sockets Layer (POPS or IMAPS). Remote Username: Enter the username of the external mailbox. Remote Password: Enter the password of the external mailbox. Keep mail on server: Check this option if you wish to keep a copy of the retrieved e-mails on the remote mail server (in case POP is used).
Local Account Settings	Deliver to: select the appropriate target for delivery. Local user: the appliance will deliver e-mail to a local mailbox, i.e. known under Users & Groups > Users. External user: the appliance will deliver e-mail to an external mailbox, e.g. a mailbox on an Exchange server in your corporate LAN. Multidrop: select this option if you need e-mail to be delivered to multiple accounts. Local user: select the local user from the drop-down list. Go to Users & Groups > Users for an overview of users on your system. @domain: Select the appropriate local domain from the drop-down list. Go to E-mail > Domains for an overview of domains configured on your system. External e-mail address: Enter the e-mail address of the external mailbox.
Multidrop Settings	Remote domain: Enter the domain. This is required to reduce the spam. Enable detection of envelope header: Check to enable detection of the special envelope (if used by your remote mailbox provider). Envelope header name: Enter the name of the header used by your remote mailbox provider in which the original envelope recipient address is listed. Prefix used in envelope header: Some mail systems will add a prefix to the original envelope recipient address. The appliance removes the entered string from the e-mail address.

Multidrop Mode

Important

We do not recommend the use of multidrop mode since possible mail loss and a higher SPAM rate may occur. Please see Remote Mailboxes for additional information.

Ensure that the remote mailbox settings are configured correctly.
Select the Local Account Settings tab.
Set the Deliver to option to Multidrop. A new tab, Multidrop Settings, will appear.
Select the Multidrop Settings tab and enter the Multidrop settings as explained in the table below.
Save your configuration.

Header	Description
Remote Domain	Use the `add` button to enter the domain. This is required to reduce spam.
Enable detection of envelope header	Check this option to enable the special envelope detection mechanism. Use this option only if it is supported by your remote mailbox provider.
Envelope header name	This field is only available if you checked the option above. Enter the name of the header used by your remote mailbox provider in which the original envelope recipient address is listed.
Prefix used in envelope header	This field is only available if you checked `Enable detection of envelope header`. Some mail systems will add a prefix to the original envelope recipient address. The AXS Guard appliance removes the entered string from the e-mail address.

Black and White List Checker

Overview

Use the black and white list checker to identify which filter is blocking:

A given IP address
A given e-mail address
Certain content, based on the e-mail body and headers

Using the Black and White List Checker

Log in to the appliance.
Navigate to E-mail > Tools > B&W List Checker.
Select the type of match.
Enter the correct item in the data field, depending on the selected match type, e.g. an e-mail address.
Click on Check to display the result.

Option or Parameter	Description
Type of match	Select the message object to be matched. IP address E-mail address Body and/or header content
Rejected IP address	Enter the IP address that was rejected.
Rejected e-mail address	Enter the e-mail address that was rejected.
Rejected text line	Enter (a part of) the text which was rejected.

Status, Logs and Reports

Overview

In this chapter, we explain the user of the AXS Guard MTA status, logs and e-mail reports.

MTA Status

The MTA status provides detailed in formation about:

The e-mail queue; messages awaiting delivery.
Information about quarantined messages; messages awaiting approval for release or removal.
Information about blocked spam messages.
Information about the e-mail quotas per user.

E-mail Queue

Log in to the appliance.
Navigate to E-mail > Status > Queue.
Click on the message ID.
Click on the desired links to view or download the message details.

Sending a queued message

Navigate to E-mail > Status > Queue
Select the desired message and click on Send Now.

Quarantined Messages

Navigate to E-mail > Status > Quarantined Queue.
Click on the message ID.
Click on the desired link to view or download the message details.

Releasing a quarantined message

Navigate to E-mail > Status > Quarantined Queue.
Select the desired message and click on Release.

Deleting a quarantined message

Navigate to E-mail > Status > Quarantined Queue.
Select the desired message and click on Delete.

Important

Events related to messages which are deleted from this queue are recorded in the admin tool logs.
See System > Logs > Admin Tool.

Blocked Spam

Navigate to E-mail > Status > Deleted Spam.
Click on a message ID to view its details.
Click on the links to view or download the message details.

The Tests links will take you to a page which provides detailed information about the spam score.

Spam Score Details

When the DNS Security feature is enabled, AXS Guard analyzes the domains of URLs within emails using SecureDNS and DNS filters. If a domain is flagged as malicious, the spam score of the email automatically increases, ensuring it lands in the user's spam folder. The Deleted Spam info page provides more details, highlighting the specific malicious domains identified in each deleted email, along with their corresponding DNS Security categories (e.g., APT, botnet, malware, scam).

Spam Score Details

Removing a spam message

Navigate to E-mail > Status > Deleted Spam.
Select the desired message in the list and click on the delete button.

Releasing a spam message

Spam messages can also be released in case of a false positive. Just select the appropriate message and click on the release button.

Deleting and releasing spam

Remote Mailbox Status

You can verify the status of the fetchmail service under System > Status > Services. The fetchmail service is the process that handles your remote mailboxes, if any.

MTA Logs

The MTA logs provide detailed in formation about:

The history of all e-mails handled by the AXS Guard MTA.
Detailed information about messages, including the unique message ID.
Detailed information about the passing or failing of a message and the associated policy.
Information about greylisted e-mail addresses.
An information summary which provides crucial information about the message, such as the time, the Send ID, the Receive ID, etc.

The history of a message exchange can be traced by the Receive and Send IDs or mail server queue IDs, which are not be confused with the unique message ID (defined per RFC 822).

Log on to the appliance.
Navigate to E-mail > Logs > Summary.
Click on the desired date (YYYY-MM-DD) to view the summary.
Click on Raw to view the unparsed version of the summary.

Tracing Messages via detailed information

Navigate to E-mail > Logs > Detailed.
Click on the desired date (YYYY-MM-DD) to view the details.

Filter Action Information

Navigate to E-mail > Logs > Filter.
Click on the desired date (YYYY-MM-DD) to view the details.

Greylisted Addresses

Navigate to E-mail > Logs > Grey Listing.
Click on the desired date (YYYY-MM-DD) to view the details.
Use a search filter to find specific messages using the Receive or Send ID.
See Grey Listing for more information about greylisting.

Reports

Important

Misuse of e-mail report information may be punishable by law.
System administrators are encouraged to consult their local privacy legislation before using this option.
The usernames in e-mail reports can be obfuscated on demand. Contact the Able support center for assistance.

The MTA reports contain information and statistics over a given time period about:

The total percentage of blocked messages.
The number of received messages from the Internet, grouped by sender and recipient.
The number of received local messages, grouped by sender and recipient.
The number of delivered messages to recipients on the Internet, grouped by sender and recipient.
The number of delivered messages to local recipients, grouped by sender and recipient.
The number of rejected messages, grouped by reason and e-mail addresses.
1. Navigate to Reports > Mail Usage.
2. Select the desired period.
3. Click on the appropriate more link.
4. Click on an area in the pie chart for additional details.

MTA Reports

Configuration Examples

Overview

In this chapter, we provide some step by step configuration examples to familiarize yourself with the configuration of mail filters and policies.

Creating Exceptions to the System Default Configuration

Example 1: Allowing incoming exe attachments

Assume the following situation: The default System configuration prevents users from sending and receiving e-mails with attachments containing files with an .exe or any other potentially dangerous extensions. However, all AXS Guard users should be able to receive e-mails with .exe or other attachments from a trusted sender, e.g. somebody@gmail.com.

Log on to the AXS Guard appliance.
Navigate to E-mail > Filters > In.
Select the default-in-ex-ext filter.
In the Sender e-mail addresses or domains field, enter the e-mail address of the sender who is allowed to send e-mails containing .exe attachments, e.g. somebody@gmail.com.
Click on Update when finished.

Example 2: Allowing outgoing exe attachments

Assume the following situation: The default System configuration prevents users from sending and receiving e-mails with attachments containing files with an .exe or any other potentially dangerous extensions. However, all AXS Guard users should be able to send e-mails with .exe or other attachments to a trusted sender, e.g. somebody@gmail.com.

Log on to the AXS Guard appliance.
Navigate to E-mail > Filters > Out
Select the default-out-ex-ext filter.
In the Sender e-mail addresses or domains field, enter the e-mail address of the recipient to whom e-mails with .exe attachments may be sent, e.g. somebody@gmail.com.
Click on Update when finished.

Example 3: Allowing outgoing exe attachments for some Users

Assume the following situation: The default System configuration prevents users from sending and receiving e-mails with attachments containing files with an .exe or any other potentially dangerous extensions. However, some AXS Guard users should be able to send e-mails with .exe or other attachments to anybody.

Log on to the AXS Guard appliance.
Navigate to E-mail > Filters > Out.
Select the internal-out-unrest filter.
Click on Edit as New.
Provide a name and description for the new filter.
Select the Apply for all Domains option.
Click on Save.
Navigate to E-mail > Filters > Policies.
Select the default (Recommended Default) policy.
Click on Edit as New.
Provide a name and description for the new policy.
Remove the default-out-blockms and the default-out-ex-ext filters from the outgoing e-mail filters, by clicking on the trash bin icon on the right.
Add the new all-domains filter to the outgoing e-mail filters, by clicking on the Add Filter button.
Click on Save when finished.

Group Level Assignment

Navigate to Users&Groups > Groups.
Select the group to which the new Policy should be assigned.
In the E-mail tab, check Overrule System Mail Policy?.
Select the newly created policy from the drop-down menu.
Click on Update.

Result

All members belonging to the selected group can send e-mails with .exe attachments to any domain.

User Level Assignment

Navigate to Users&Groups > Users.
Select the user to which the new Policy should be assigned.
In the E-mail tab, check Overrule Group Mail Policy?.
Select the newly created policy from the drop-down menu.
Click on Update.

Result

This user can send e-mails with .exe attachments to any domain.

Enforcing E-mail Address Limitations

In this example, we restrict a specific AXS Guard user so that he/she can only send and receive e-mail to and from one address, e.g. somebody@gmail.com. No extension or spam checks are performed.

Create a new Out Filter

Log on to the AXS Guard appliance.
Navigate to E-mail > Filters > Out.
Select the no-access-out filter.
Click on Edit as New.
Provide a name and a description for the new filter.
Check the Specify for which domains and/or e-mail addresses option.
Enter the authorized e-mail address, e.g. somebody@gmail.com.
Select Pass E-mail if the domain matches in the Action Menu.
Click on Save.

Create a new In Filter

Navigate to E-mail > Filters > In.
Select the no-access-in filter.
Click on Edit as New.
Provide a name and a description for the new filter.
Check the Specify for which domains and/or e-mail addresses option.
Enter the authorized e-mail address, e.g. somebody@gmail.com.
Select Pass E-mail if the domain matches in the Action Menu.
Click on Save.

Add the new In and Out Filter to a Policy

Navigate to E-mail > Filters > Policies.
Click on Add New.
Provide a name and a description for the new policy.
Add the newly created incoming filter, by clicking on the Add Filter button.
Add the newly created outgoing filter, by clicking on the Add Filter button.
Click on Save.

Add the new Policy to the user

Navigate to Users&Groups > Users.
Select the user to which the new Policy should be assigned, e.g. John.
In the E-mail tab, check Overrule Group Mail Policy.
Select the newly created policy from the drop-down menu.
Click on Update.

Result

This user can on send and receive e-mails to and from somebody@gmail.com.

Example: User Level Limitations

In this example, we restrict a given AXS Guard user so that he/she can send e-mails to local and outside networks (domains), but not receive any e-mails from outside networks (domains). Reception of messages originating from local domains is allowed. Potentially dangerous executable extensions are not allowed.

Log on to the AXS Guard as explained in the AXS Guard System Administration How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool.
Navigate to E-mail > Filters > Policies.
Click on Add New.
Provide a name and a description for the new policy.
Add the internal-in-unrest filter, by clicking on the Add Filter button.
Add the default-out-blockms filter, by clicking on the Add Filter button.
Click on Save.

Assign the Policy to the User

Navigate to Users&Groups > Users.
Select the user to which the new Policy should be assigned, e.g. John.
In the E-mail tab, check Overrule Group Mail Policy.
Select the newly created policy from the drop-down menu.
Click on Update.

Using a Regular Expression to Match Content

In the following example, we create a black list using a regular expression. We will quarantine any message that contains a number between 0 and 999.

Go to E-mail > Filters > Black List.
Enter the settings as shown in the screenshot below, using the following regex: [0-9]{3}.
Save the filter.

Next we use a telnet session to test our new filter:

$ telnet 10.200.33.57 25
Trying 10.200.33.57...
Connected to 10.200.33.57.
Escape character is '^]'.
220 mail.mydomain.be ESMTP Secure MTA - Watch your steps
EHLO somedomain.com
250-axsguard.mydomain.be
250-PIPELINING
250-SIZE 52428800
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: <someuser@somedomain.com>
250 2.1.0 Ok
RCPT TO: <localuser1@mydomain.be>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: test message

This is a test. This message contains an invalid number: 789. This mail should be quarantined.

.
250 2.0.0 Ok: queued as 4738sm16clz3h0R
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Next we verify the quarantined queue:

Go to E-mail > Status > Quarantined Queue.
Click on the message ID to view additional message details.

Using Text to Match Content

In the following example, we create a black list using a simple text match. We will quarantine any message that contains the following sentence: All work and no play makes Jack a dull boy.

Text searches are case-insensitive. The filter in the following example will also match all work and no play makes jack a dull boy and other permutations.

Go to E-mail > Filters > Black List.
Enter the settings as shown in the screenshot below, using the following text: All work and no play makes Jack a dull boy.
Save the filter.

Next we use a telnet session to test our new filter:

$ telnet 10.200.33.57 25
Trying 10.200.33.57...
Connected to 10.200.33.57.
Escape character is '^]'.
220 mail.mydomain.be ESMTP Secure MTA - Watch your steps
EHLO somedomain.com
250-axsguard.mydomain.be
250-PIPELINING
250-SIZE 52428800
250-ETRN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
MAIL FROM: <someuser@somedomain.com>
250 2.1.0 Ok
RCPT TO: <localuser2@mydomain.be>
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
Subject: test message

This is a test.
All work and no play makes Jack a dull boy
This ends our test.

.
250 2.0.0 Ok: queued as 473fTs3ysQz3h0R
QUIT
221 2.0.0 Bye
Connection closed by foreign host.

Next we verify the quarantined queue:

Go to E-mail > Status > Quarantined Queue.
Click on the message ID to view additional message details.

Troubleshooting

I am not receiving any e-mails and the logs do not show any traffic

Verify if the Firewall allows SMTP traffic on the Internet side (port 25) of the AXS Guard. Navigate to Firewall > Static and check if the int-smtp rule is included in the stat-int policy. If the IPS Module is active, check the IPS logs for blocked SMTP traffic. Search for the following entries: DNS, SPOOF and SMTP. More information about the IPS Module is available in the AXS Guard IPS How To, which can be accessed by clicking on the on-screen Documentation button in the Administrator Tool.

I can send messages, but the receiver gets an undeliverable message when sending a reply

This occurs most likely when a sender is mailing from a private domain (a domain which does not resolve on the Internet). The sender’s e-mail address (From field) in the mail client should contain a domain which can resolve correctly on the Internet, i.e. for which an MX record exists, otherwise the receiver will not be able to reply.

The “verify recipient address” option is checked, but I receive messages which should be rejected

The AXS Guard will try to validate the recipient address before accepting the e-mail. The e-mail will be rejected if the recipient address is invalid on the back-end mail server only if it allows recipient address verification.

How to enable recipient verification on a Microsoft Exchange 2003 server:

Activate the Global Settings > Message Delivery (properties) > Recipient filtering tab > Filter recipients who are not in the Directory checkbox in the Exchange System Manager on your Microsoft Exchange Server.
Enable the Apply Recipient Filters option in the Default SMTP Virtual server (Exchange System manager > Administrative Group > SERVERNAME > Protocols > SMTP > Default SMTP virtual server (properties) > General tab > Advanced button > Edit ).

If an Exchange server is used in combination with the Verify recipient address option, you must disable tarpitting on the exchange server. If Verify recipient address is enabled, then the AXS Guard MTA waits 6 seconds before returning the following message: Recipient address rejected: unverified address: Address verification in progress. By default, tarpitting causes a delay of 5 seconds to be added to each transaction. Exchange only has 1 second to answer the request. If the exchange server is slightly loaded then it fails to answer in time.

I cannot access or get the Remote Mailbox option to work.

The Remote Mailbox option is only available and functional if you purchased and activated the AXS Guard e-mail server module.

Special considerations when using the Remote Mailbox option with a MS Exchange server.

The multidrop option uses the username in the retrieved mail for delivery to the same user on the AXS Guard (localhost).

You should verify whether:

The user exists on the AXS Guard (or the name exists as an alias of a user).
The AXS Guard e-mail server feature is activated.

If the user or the alias does not exist on the AXS Guard, the e-mail is delivered to undeliverable@localhost.

If you decide to use the multidrop option in combination with an internal MS Exchange server, execure the following steps:

Create the user on the AXS Guard (if he/she does not exist)
Enable e-mail forwarding for the user (Users&Groups > Users)
Enter the internal e-mail address in the Forwarding Address field

Alternatively, you could create a distribution list using the username in the mails which are to be remotely retrieved. Specify “all domains” and an internal e-mail address to forward the messages to. Note that to create a distribution list, you must purchase and activate the AXS Guard e-mail server module.

Bona fide messages are being blocked

Sometimes it’s possible that a bona fide message is blocked by a Black List, even when there is no direct connection between the mail content, the attachment and the settings configured in the Black List. The solution is to create a White List to overrule the blacklisted content. A White List entry that matches on text has a higher priority than a Black List entry that matches on text.

Support

If you encounter a problem

If you encounter a problem with AXS Guard, follow the steps below:

Check the troubleshooting section of the feature-specific manual.
Check the knowledge base on this site for information about special configurations.
If no solution is available in any of the above sources, contact your AXS Guard vendor.

Contact Information

(+32) 15-504-400
support@axsguard.com

Field	Description
Name	Enter a unique name to identify this DKIM key configuration.
Key Type	Specifies the cryptographic algorithm to be used to generate the key pair.