Table of Contents

4. Mail Server Security

4.1. Authentication and Encryption

4.1.1. Kerberos Authentication within Active Directory

4.2. SPF and DomainKeys

4.2.1. AXIGEN Signing Module Usage and Configuration

4.3. Mail Filtering

4.3.1. Message Acceptance Rules

4.3.2. Routing Rules

4.3.3. Antivirus / Antispam Filters

4.3.4. Message Rules

4.3.4.1. SIEVE Overview and Implementation in AXIGEN

4.3.5. The AXIGEN Filtering Module

4.3.5.1. Filtering Module Implementation in AXIGEN

4.3.5.2. Configuring the AXIGEN Filtering Module

4.3.5.3. AXIGEN Filtering Module Commands

4.3.6. Activating and Prioritising Filters and Rules

4.3.7. Language Specifications for Policy Configuration

4.3.7.1. SMTP Functionalities (I)

4.3.7.2. SMTP Functionalities (II)

4.3.7.3. SMTP Functionalities (III)

4.3.5.1. Filtering Module Implementation in AXIGEN

A "milter" is a module used by a mail transfer agent (MTA) that allows the addition of very efficient Antivirus/Antispam filters in the mail processing chain. It makes decisions and takes actions during the SMTP sessions. The milter uses a communication protocol based on sockets. This protocol can be used to enable third party applications like anti-virus or anti-spam software to integrate with different MTAs supporting this milter module.

AXIMilter is a daemon that runs separately from AXIGEN. It can be configured through its configuration file, located by default in /etc/opt/axigen/aximilter.conf. The configuration file can be specified using the command line arguments, if one wants to use configuration located elsewhere.

The AXIGEN MTA communicates with the milter extension using the "aximilter.afsl" filter and the inet socket. The filter takes care of the communications and translations between the two parties. Any results passed on by the milter to the filter are interpreted and formatted by it and passed down the chain to AXIGEN.

AXIGEN Filter Module Implementation

When the filter is defined and activated in the AXIGEN configuration you have to set the socket used for communications between AXIGEN and the milter extension. This is an inet (TCP) type of socket. Through this socket AXIGEN will connect to the milter interface and give instructions (formatted by the filter file) to the third party application at the other end. This connection is also used to receive any results from the milter back to AXIGEN.

Filter file purpose:
  • Parse the information received
  • Interpret and check the information
  • Translate information
  • Pass information
Socket purpose:
  • Establish a communications channel
  • Transfer information
  • Maintain the integrity of the information
The milter extension takes the requests received from AXIGEN and passes them to the milter counterpart of the third party application. This communication is negotiated using the standard milter protocol. When the third party milter responds, information is again passed through the TCP socket and interpreted by the filter. Only then, based on the information received, AXIGEN is able to determine what action to take.

The whole process chain can be described as follows. The AXIGEN MTA receives an email and the processing chain begins. When AXIGEN reaches the filter designated for the milter extension it passes the necessary information through the socket. All the information is translated by the filter file and fed to the AXIMilter (AXIGEN's milter extension). AXIMilter then connects through a socket to the third party milter implementation and sends the request to make a decision about the fate of the particular email.

After deciding the action to be taken on the respective email (to accept it or not and why) the information is again passed to AXIMilter through the socket between the two milter implementations. AXIMilter sends the results back to AXIGEN through the socket defined in the filter setup and it is again translated. When the AXIGEN MTA receives the information, it takes the necessary steps to deliver or discard the message.