- Solution Overview
- Security Layers
- Services Architecture
- Integrating with Other Solutions
- Clustered Operations
- Administration Tools Overview
Axigen provides various types of filters at each level of mail processing that allow you to increase mail traffic security and block any type of unwanted mail messages from reaching their intended recipient mailbox. The filtering system in Axigen is highly effective and allows maximum flexibility in defining what email messages should be scanned, what filters should be used, the order in which these filters are applied and the actions taken according to the results of the scanning process. The filters can be applied both for incoming and for outgoing email traffic.
1. Message acceptance rules
Axigen implements a set of message acceptance rules at SMTP-connection level. You can configure and implement message acceptance rules and adjust them to best suit your company's security requirements. Incoming connections established via SMTP and the message flow can be easily managed using the established rules. Moreover, you can allow adding headers, changing addresses and other such actions.
Examples of message acceptance rules:
- allow incoming messages from a specific domain
- deny incoming messages with attachments exceeding 3 MB
- allow authenticated users only
- accept secured connections only
- deny looping emails (when the number of received headers exceeds 20)
The message acceptance rules can consist in any number of such rules applied following a given priority. These rules can be set at SMTP Incoming level and help save space and resources for email processing.
The message acceptance rules are defined using an Axigen proprietary scripting language and are at this time contained, along with the Processing and Relay policy scripts, in a single file per installed server. They can also be created automatically via the WebAdmin Wizard. More details on how to do this are available in the 220.127.116.11 Acceptance & Routing chapter.
Through the message acceptance rules, a wide range of event handlers associated with the SMTP events are available, along with various methods, message headers, envelopes and peer information.
The events are predefined blocks within the script that will be executed at specific moments by the server. For each event, the server calls certain methods which can have a configurable or predefined behavior. The available events at SMTP Incoming level are:
2. Routing rules
To further fine-tune email communication management at SMTP level, the Axigen messaging solution implements Routing Rules.
The routing rules correspond to the Processing and SMTP Outgoing modules and enable you to define the NDR (Non-Delivery Receipt) text and the conditions when such a message is returned (for example, send NDR responses when the specified recipient of an email message is invalid). You can also customize SMTP Outgoing actions for all or part of the relayed email communication, such as:
- establish a certain address where all emails from a certain domain are relayed, or
- specify a username / password authentication before relaying emails to a certain address.
For further information, see the dedicated section in this chapter.
The routing rules can contain any number of predefined options, thus being easily adapted to various security requirements.
These rules are defined using an Axigen proprietary scripting language and are at this time contained, along with the Message Acceptance Rules scripts, in a single file per installed server. They can also be created automatically via the WebAdmin Wizard. For details on the options available in the WebAdmin Wizard, please see the corresponding section.
A wide range of event handlers associated with the SMTP events are available, along with various methods, message headers, envelopes and peer information are available when defining routing rules.
The events defined for the routing rules and their contexts are as follows:
- Event -> Context
- onRelay -> SMTP Outgoing
- onDeliveryFailure -> Processing
- onTemporaryDeliveryFailure -> Processing
3. Message rules
Message rules instruct the Axigen mail server to take certain actions on processed email messages based on pieces of information contained by the message headers. Using message rules is safe, since they do not operate on the mail content but only extract information from the mail header and take actions according to the predefined rules. They work basically by comparing different keys using different comparators and comparison methods, against headers of a mail message. Based on the result of the comparison, you can apply different actions to the corresponding mail message (i.e. "reject", "discard", "redirect" etc.).
Examples of message rules:
- messages from firstname.lastname@example.org copy to alex@localdomain;
- messages from email@example.com move to folder Jokes;
- all messages reply with "Out-of-office" message.
Message rules are easily created using the provided Web Wizard by each individual user via the WebMail module of Axigen.
You can create more complex message rules using a simple scripting language called SIEVE. The same language is used by the WebMail Wizard when defining message rules automatically.
Message rules are static filters, where the filter itself is contained in a separate file. Different user-defined scripts can be included in any Axigen Filtering System. The supported language provides an extremely flexible filtering methodology, as users can define any number of script filters according to their needs.
Axigen also implements the vacation extension. This means that message rules can be created and applied for generating out-of-office type automatic replies. Thus, auto-generated messages can be sent when the user of the account for which the vacation applies, is on vacation, out of office or in general away for an extended period of time. The vacation extension is an extra functionality also available via script files.
AntiVirus / AntiSpam filters can also interact with message rules, via two headers appended to email messages. These headers contain a spam or virus level value which actually indicates the likelihood of that particular email message being virus or spam. Based on these levels, actions imposed by the message rules can be taken, for instance moving email messages above a certain level to a specified Quarantine folder.
Axigen supports creating customized filter chain. This means you can define and use as many anti-virus / anti-spam filters and message rules as required by their security policies.
For a complete description of this language, see RFC 3028.
4. AntiVirus / AntiSpam filters
AntiVirus / AntiSpam filters can be easily used with the Axigen messaging solution to ensure a high security level for email communication. Anti-virus / Anti-spam applications can communicate with Axigen either directly, either through the Milter module.
This type of filtering allows integration with virtually any third party applications, including anti-virus and anti-spam applications. Currently, connectors for ClamAV (anti-virus) and SpamAssassin (anti-spam) applications (both open source) are implemented, ensuring effective virus and spam protection for all mail traffic managed by the Axigen mail server. Both ClamAV and SpamAssassin need to be installed separately.
To see instructions on how to make Axigen work with ClamAV, please see the corresponding video (anti-virus tutorial). For SpamAssassin, you simply need to install the application - no further configurations are necessary.
A bundled version of Spamassassin is also available and is displayed in the filter list as a separate entry - SpamAssassinBundled. This filter, as well as the bundled Commtouch filter (commercial application) can be started on Unix/Linux systems via the "axigenfilters" initscript.
Filter configuration in Axigen also involves the notion of Active Filters. Although not a distinct filter category, the Active Filters designation is used to refer to filters currently enabled in the Axigen messaging solution. This designation is particularly useful when enabling filters.
In Axigen, you can apply filters at three levels:
- server level (these filters are applied to all emails directed to any account / mail list from the server)
- domain level (these filters are applied to all emails directed to the domain to which the account / mail list belongs)
- account / mail list level (these filters are applied only to the account / mail list for which the filters have been created)
Thus, a typical filtering chain in Axigen will contain different types of filters, applied on different levels.
If one of the filters in the filtering chain yields an error (internal error, AFSL or any type of error), the email being processed is kept in the processing queue and it will go through the filtering chain all over again, at a later time until all the filters in the chain can be applied. If all the filters in the filtering chain yield a PASS action, and the last one yields REJECT, the email is rejected.
The order in which these filters will be applied is based on their level and on their priority. See the 2.5.8 Enabling Filtering for a domain / user section for details on activation inheritance and priority levels.
Axigen can easily integrate with other third party applications through a simple interface which is made available as part of SDK (Software Development Kit). For more details on SDK delivery, please contact the Axigen Sales Department.