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.
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. |
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.
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 ofuser@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.
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 aSTARTTLS
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 aSTARTTLS
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.
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 |
---|---|---|
domain |
Whitelist |
|
Whitelist |
||
domain |
domain |
Whitelist |
domain |
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.
-
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 theFrom:
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, the 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.
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 asaccounting.yourdomain.com
-
You send a message as
sender@abcxyz.yourdomain.com
When received by the recipient, the message’s origin will appear asyourdomain.com
, since masquerading is not enabled forabcxyz.yourdomain.com
-
You send a message as
sender@abcxyz.accounting.yourdomain.com
When received by the recipient, the message’s origin will appear asaccounting.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.
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 |
|
|
Out-Filter-a |
mail@addr1 |
mail@addr2 |
In-Filter-x |
|
Out-Filter-b |
|
||
In-Filter-y |
|
Out-Filter-c |
|
- 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 |
|
|
In-Filter-x |
|
Out-Filter-b |
|
||
In-Filter-y |
|
Out-Filter-c |
|
- 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 |
spam checking |
mark as spam: 5 / delete : 10 |
Forwarding |
no e-mail address specified |
Hotmail Policy ⇐ Out Filter 2
Policy | |
---|---|
domain / e-mail |
|
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 |
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 |
spam checking |
mark as spam:2 / delete:11 |
Forwarding |
no e-mail address specified |
Internal Mail Policy ⇐ In Filter 3
Policy | |
---|---|
domain / e-mail |
|
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 of10
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.
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. |
Key Type | The cryptographic algorithm that was used to generate the key. |
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. |
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. |
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, 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. |
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. |
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. |
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 |
Reject username as recipient address from non-secure connections |
Many MTA administrators use initials in e-mail addresses for easy maintenance, e.g. |
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, |
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 |
Users can send an empty message to |
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.
|
E-mail match properties |
|
Text match properties |
|
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.
|
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.
|
E-mail match properties |
|
Text match properties |
|
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.
|
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 |
|
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:
|
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 |
|
Action |
Select the appropriate action from the drop-down list.
|
Block extensions |
Enable to block e-mail attachments based on their extension.
|
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.
|
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. |
|
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, |
||
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:
The substitutions for the |
||
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.
|
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 |
Domain |
Select the domain of the distribution address, e.g. |
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 |
|
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 |
|
Local Account Settings |
|
Multidrop Settings |
|
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 |
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 |
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.
|
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.
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).
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.
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.
-
Navigate to Reports > Mail Usage.
-
Select the desired period.
-
Click on the appropriate more link.
-
Click on an area in the pie chart for additional details.
-
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