Listeners
All Axigen modules implement a set of connectivity and threading functionalities and features that make it faster and easier to manage.
The Axigen mail server can use different Listeners for its TCP services (SMTP Receiving, POP3, IMAP, WebMail, WebAdmin, CLI and FTP Backup) and UDP services (Log and Reporting).
Listeners are network points of entry, associated with an interface address and port number that grant access to a specific TCP or UDP service.
Listeners add extra flexibility and configurability to each Axigen service, as they can be used to grant differentiated access to the same services for different categories of users (e.g users within a specific domain). Moreover, listeners can be associated with a variety of rules that allow defining specific limitations for connections coming from IPs within specified IP sets.
Listeners can be defined, using various parameters corresponding to that TCP service, from the configuration file (as of type "TcpListener" OBJECT-SET) or through WebAdmin (the web configuration interface). UDP service listeners have fewer parameters associated as connection related parameters do not apply to them.
The following attributes are available for each listener:
-
address - the "point of entry" address and port number
-
enable - specifies whether the listener is enabled or not (this way you won't have to delete the listener when you want to discontinue its use)
-
max. number of simultaneous connections and max. number of new connections in a defined time interval (seconds / minutes / hours / days) - parameters specifying limitations for network connections accepted for this listener
-
max. connections from each remote IP address and max. connections from each remote IP address in a defined time interval (seconds / minutes / hours / days) - parameters specifying limitations for network connections from the same IP address accepted for this listener
TCP listeners can also be set to support SSL connections. Further SSL parameters are available for TCP listeners in Axigen:
-
allowed SSL versions;
-
certificate file;
-
max. chain verification depth;
-
use Ephemeral Key;
-
request certificate-based authentication from client;
and others.
Below you can find a scheme for a quick understanding of the Log listeners: (in this context ":" can be translated as "of type"):
-
TCP service:
-
listeners : "TcpListener" OBJECT-SET
-
allowRules : "TcpAllowRule" OBJECT-SET
-
denyRules : "IpRule" OBJECT-SET
-
-
UDP service:
-
listeners : "IpListener" OBJECT-SET
-
Rules
Different rules can be associated with listeners, meant to sort connections based on various parameters, and to reject (deny rules) or accept (allow rules) them accordingly. Using deny and allow rules you can automatically accept / deny connections from specific IP addresses.
Allow / Deny rules
Allow / Deny rules enable you to specify the rules for accepting/rejecting connections when these connections follow the limitations imposed by the listener. Allow / Deny rules are defined using the following general attributes:
-
specify a network / mask, IP range or single IP for which the reject / allow rule is applied
-
check or uncheck the 'enable' option to specify if the rule is enabled or not
You can then set priorities for when applying the rules and impose further connection limitations using the flow control parameters described below:
-
max. number of simultaneous connections and max. number of new connections in a defined time interval (seconds / minutes / hours / days) - these parameters impose limitations on the number of connections initiated by any address within the rule IP set;
-
max. connections from each remote IP address and max. connections from each remote IP address in a defined time interval (seconds / minutes / hours / days) - these parameters impose limitations on the number of connections initiated by the same address within the rule IP set.
Rule enforcement policy
The policy for applying accept and deny rules for connections to listeners is described below:
-
The IP address from which the connection has been initiated is exposed.
-
Axigen verifies if this IP address is part of a set of IP addresses associated to one or more deny rules; if "yes", the deny rule with the highest priority (meaning LOWEST value for the priority attribute) is applied.
-
Axigen verifies if this IP address is part of a set of IP addresses associated to one or more accept rules; if "yes", the accept rule with the highest priority (meaning LOWEST value for priority attribute) is applied.
-
If the IP address from which the connection has been initiated is associated only with a deny rule, the connection is denied (closed).
-
If the IP address from which the connection has been initiated is associated with both a deny AND an allow rule, the rule with the highest priority is applied. If the rule with the highest priority is a deny rule, the connection is denied (closed). If the rule with the highest priority is an allow rule, the limitations (if any) for the specified connections from the allow rule are applied. If the allow rule and the deny rule have the same priority, the connection is accepted.
-
If the IP address from which the connection has been initiated is associated only with an accept rule, the verifications defined for connections in the accept rule are applied, and if fulfilled, the connection is accepted.
After applying the limitations imposed by the rules, the global limitations defined at listener level are applied. Only then the connection is accepted (and the respective service protocol is applied on the accepted connection).
If no allow rule is defined for the IP address from which the connection has been initiated, then the connection is considered as fulfilling the rules and the verifications defined globally (if any) for the current listener are applied.
Axigen has a multi-threaded engine which allows separate module thread allocation. The multi-threaded engine can break server activity into multiple parallel processing threads. By allocating a number of threads to certain modules, (SMTP Receiving / SMTP Sending / WebMail / IMAP, etc.) resource (memory / CPU) distribution is adapted to usage scenario (main mail server / backup server / gateway mail server) and hardware resources.
Threads
Thread allocation is performed using the connection thread control parameters available for most Axigen modules. Depending on your network specifications and conditions the workload can be adapted to the server's processing power, in order to prevent a system overload and / or improve its performance. More details on connection thread management using WebAdmin are available in each service description tab.
These parameters are also accessible for configuration in each service section from axigen.cfg