The Axigen Solution: Overview & Architecture - Admin Manual

From Axigen Wiki

Axigen is an integrated email, calendaring and collaboration platform, masterfully built on advanced mail server technologies, for increased speed and security. It is a fully self-developed solution, truly innovative in several respects, particularly scalable and configurable. This messaging solution offers the entire range of mail services - SMTP, POP3, IMAP, WebMail - includes List server, Logging, Reporting and FTP Backup modules and provides various, flexible administration options (including a central Web administration interface - WebAdmin).

Axigen provides users with effective time-management tools such as personal and public calendars, tasks and notes, available from WebMail, MS Outlook and iCal (Webcal) compatible clients. Advanced collaboration functionalities enable users to share their emails, tasks and appointments by granting colleagues permissions to read, write, delete or perform other actions on the content of mailbox folders of choice, by viewing others' availability (free / busy) status or delegating the right to send messages in their name to co-workers.

OS compatibility

Developed initially for Linux, Axigen is currently available for RedHat Enterprise, Fedora, CentOS, SuSE, Gentoo, Novell, Ubuntu, Debian, Mandriva, Slackware, FreeBSD, Solaris, Windows Server 2003 / 2008. Please check our website for an up-to-date list of supported platforms.

Axigen uses MPA (Multi Platform Architecture), a proprietary cutting-edge technology that allows porting Axigen's high-performance mail server on multiple platforms while keeping the same set of features. This makes it possible to adapt the product to any demanded platform, while still guaranteeing stability, and makes it easier for users to switch to a different platform, whenever their requirements change.

Integrated messaging solution

Axigen is an all-in-one, turnkey messaging solution and a great alternative to open source. It is also modular, as it can run with any number of services inhibited. For instance, if you only want to run the SMTP service, Axigen can run with all other services inhibited by allocating all processing threads to SMTP. Thus, Axigen can accommodate any usage scenario - main mail server, backup server, mail relay server.

High configurability

Built with system administrators’ needs in mind, Axigen provides you with unmatched configuration possibilities. For each and every Axigen module and feature, you can fine tune connection control, client management and make advanced settings at domain / account level.

Innovative storage

Axigen UltraStorage^TM ensures an effective space management. Using a unique technology that allows storing messages in a special directory structure, Axigen guarantees an effective, fast email flow and optimized space-saving. This innovative storage architecture, doubled by similar queue architecture, with RAM cached index based access, reduces I/O operations and disk access. Messages are stored in container files, a proprietary format that supports an effective space-saving filling procedure, allowing you to specify the locations and the number of directories / files allowed for message storage.

Advanced security tools

In terms of security, Axigen GrowSecure^TM grants a safe reception, transit and delivery of email. The Axigen messaging platform comes with an extensive, customizable security toolset. Messages can be filtered at server, domain or user level via a variety of filters, including anti-virus / anti-spam, anti-spoofing (SPF authentication), DomainKeys and custom SIEVE scripts, Identity Confirmation, blacklisting, whitelisting, greylisting or country filtering. For extra email protection, Axigen can integrate with virtually any commercial security application requested by users.

Automation options

Axigen addresses automation requirements of system administrators by providing you with an alternative configuration interface - CLI (Command Line Interface). Apart from being an alternate method of performing basic configuration tasks, CLI automates repetitive tasks, which can be really time-consuming when performed manually. Automatic domain data migration is also available in WebAdmin, where you can easily set migration related parameters.

Clustering support

Axigen allows you to route SMTP, POP and IMAP connections to different machines running our messaging solutions. This feature is based on the integration of Axigen with OpenLDAP and it makes use of the SMTP In, POP3 Proxy and IMAP Proxy services. This feature enables you to spread mailboxes on several Axigen servers and have a separate machine that routes POP3/IMAP connections to the appropriate mailbox server.

Another important feature of the OpenLDAP integration with the Axigen mail server is the LDAP Authentication mechanism. This method is available for all the Axigen services that require authentication: SMTP In, POP3, IMAP, WebMail, POP3 Proxy and IMAP Proxy.

Last but not least, synchronization of accounts and groups can be performed with LDAP using three synchronization methods: from Axigen to LDAP, from LDAP to Axigen and both ways, for saving time when making record changes.

These are some of the distinctive Axigen features - to read more about them, their configuration procedures and many more facilities and configuration options provided by Axigen, browse through this online documentation.

MultiPlatform

Axigen uses MPA (Multi Platform Architecture), a proprietary cutting-edge technology that allows porting Axigen's high-performance mail server on multiple platforms (Linux, FreeBSD, Solaris and Windows) while keeping the same set of features. This makes it possible to adapt the product to any demanded platform, while still guaranteeing stability, and makes it easier for users to switch to a different platform, whenever their requirements change.

Modularity

Services and modules

Axigen is an Internet-based mail server that provides messaging services over the Internet via connections using a Transmission Control Protocol / Internet Protocol (TCP/IP) network. The Axigen mail server sends mail messages using the Simple Mail Transfer Protocol (SMTP). The messages can be retrieved using the Post Office Protocol version 3 (POP3), the Internet Message Access Protocol (IMAP), WebMail, Mobile Webmail or ActiveSync. Axigen’s mail storage integrates a proprietary technology (Axigen UltraStorage^TM) that allows storing messages in a special directory structure, guaranteeing an effective, fast mail flow and optimizing space-saving.

Architecture features

Axigen incorporates a multi-threaded engine, which can break server activity into multiple parallel processing threads. This enables you to allocate a certain number of processing threads to specific modules (SMTP incoming / SMTP outgoing / WebMail / IMAP etc.). Running services can be configured at service, domain and account level.

Most Axigen services (SMTP Incoming, SMTP Outgoing, POP, IMAP, WebMail) make use of configurable listeners to define rules for accepting or denying connections.

Administration tools

The administration tools enable both centralized configuration (WebAdmin and Command Line Interface) and manual configuration (configuration file).

Security

The Axigen messaging platform comes with an extensive, customizable security toolset. Messages can be filtered at server, domain or user level via a variety of filters, including anti-virus / anti-spam, anti-spoofing (SPF authentication), DomainKeys and custom SIEVE scripts, identity confirmation, blacklisting, whitelisting, greylisting or country filtering.

Highly configurable logging and reporting services are also available and a FTP Backup service allows you to securely backup and restore your domain and user configuration.

The schema below illustrates all of Axigen’s components:

When a remote host tries to deliver a message to or via Axigen, it first passes through the SMTP Receiving module (SMTP INCOMING). Message acceptance policies are applied on the message by this particular service.

After the message passes through the SMTP Incoming service, it is placed in the Axigen queue. The Queue Processing (PROCESSING) service takes the message and begins the filtering process using the AV/AS solutions and the message rules defined in Axigen.

If the message is not discarded during the Processing service by a filter, then it is delivered locally to the Axigen storage, if the recipient is locally defined or it can be relayed to another host using the SMTP Sending module (SMTP OUTGOING).

Users can access their mailboxes using an email client (such as MS Outlook, Mozilla Thunderbird, Apple Mail etc.), the WebMail interface or from their mobile device.

Axigen SmartProcessing^TM

Axigen incorporates a multi-threaded engine, which can break server activity into multiple parallel processing threads and thus reduces email processing time to a minimum. It also offers a more efficient management of messages based on the unique requirements of each company.

Queue management

You can inspect the content of the queue, applying filters based on originator, recipient(s), message size, failure reason and so on. Specific actions such as delete, retry or send NDR can be performed on selected items.

Virtual queues

Axigen maintains an availability status for each destination domain, avoiding repeated delivery retries to unresponsive domains.

Cached queue / Hashed structure

The disk structure of the queue is optimized for fast message access, even if a large number of messages exist in the queue. Axigen also retains memory-cached queue items that are to be delivered soon.

Axigen UltraStorage^TM

Using a unique technology that allows storing messages in a special directory structure, Axigen guarantees an effective, fast email flow and optimized space-saving.

Indexed data structure

Axigen ensures an optimal balance between the space used for storing indexes and the time to access information by introducing multiple levels of indexes depending on how often information is accessed.

Transactional access

It provides structural integrity for the stored information by performing transactional data access.

Expandable storage

You can add subsequent storage units to one domain, thus increasing the available space.

Single storage of emails with multiple recipients

Only one copy of a message received by multiple recipients is stored, making Axigen particularly useful for distribution lists and groups.

Repairing corrupted accounts

If an account’s data becomes corrupted (due to, for instance, disk failure), Axigen allows you to attempt account data recovery.

Domain renaming

If the domain name changes and users remain the same you can simply rename the domain and users can start using the same accounts, but with new email addresses according to the new domain name.

Axigen GrowSecure^TM

Axigen GrowSecure^TM secures reception, transit and delivery of email. Messages can be filtered at the server, domain, or user level via a variety of filters, including anti-virus / anti-spam (any third party solution), anti-spoofing, Domain Keys and custom SIEVE scripts.

The Axigen mail server offers high-end features for large scale implementations by providing speed, security, reliability and a failsafe storage system helping you to avoid any interruption of service or loss of data.

Scalability

• Statefull services

Non-distributed email solutions, where account information (configuration and messages) is stored on a single machine, allow vertical scalability through hardware upgrades (CPU, RAM, disk). However, due to limitations in a typical machine (i.e. max 2 CPU, max 4 GB RAM etc.) an upper limit is eventually reached, where one can no longer upgrade one machine – vertical scalability limit.

When the vertical scalability limit is reached, the only solution available is to distribute account information (configuration and mailbox) on more than one machine – horizontal scalability. Since information for one account is atomic and cannot be spread across multiple machines, the solution is to distribute accounts on more than one machine. This way, for a single account, there will be one machine responding to requests (IMAP, POP, SMTP, WebMail) for that specific account. Thus, when the overall capacity (in terms of active accounts) of the messaging solution is reached, adding one more machine to the solution and making sure new accounts are created provides a capacity upgrade, therefore allowing virtually unlimited horizontal scalability.

• Stateless services

Since stateless services do not store information over multiple sessions, we can assume that two different machines are able to service requests for the same account. This way, horizontal scalability can be achieved by simply adding more machines providing the same service in the exact same configuration. The only remaining requirement is to ensure that requests to a specific service are distributed evenly throughout the machines providing that specific service (i.e. if the system contains two machines providing IMAP proxy services, half of the incoming IMAP connections must reach one of the machines and the rest of the connections must reach the other machine). This functionality is provided by a load balancer.

Email features

Queue management

• Queue management

You can inspect the content of the queue, applying filters based on originator, recipient(s), message size, failure reason and so on. Specific actions such as delete, retry or send NDR can be performed on selected items.

• Virtual queues

Axigen maintains an availability status for each destination domain, avoiding repeated delivery retries to unresponsive domains.

• Cached queue / Hashed structure

The disk structure of the queue is optimized for fast message access, even if a large number of messages exist in the queue. Axigen also retains memory-cached queue items that are to be delivered soon.

Routing policies

• Built in DNS Cache
• Virtual Routing

Thanks to Axigen's virtual routing capabilities, you can assign different outbound IP addresses to each domain.

Log server

• Multiple log levels
• Per service log files
• Remote log collection

All Axigen services are capable of logging either locally or through the network. The logging module will collect log entries received from the network, allowing you to have a dedicated logging server.

Storage

• Indexed data structure

Axigen ensures an optimal balance between the space used for storing indexes and the time to access information by introducing multiple levels of indexes depending on how often information is accessed.

• Transactional access

It provides structural integrity for the stored information by performing transactional data access.

• Expandable storage

You can add subsequent storage units to one domain, thus increasing the available space.

• Single storage of emails with multiple recipients

Only one copy of a message received by multiple recipients is stored, making Axigen particularly useful for distribution lists and groups.

• Repairing corrupted accounts

If an account’s data becomes corrupted (due to, for instance, disk failure), Axigen allows you to attempt account data recovery.

• Storage overload prevention

Overload prevention is ensured by limiting allowed message sizes according to specific policies based on multiple message or connection parameters.

• Domain Renaming

If the domain name changes and users remain the same, you can simply rename the domain and users can start using the same accounts, but with new email addresses according to the new domain name.

User options

• Ajax WebMail Interface

The Ajax-powered WebMail interface provides users with a desktop-like experience. Keyboard navigation and shortcuts, drag-and-drop, "Live" email list view, frequent folders, all these intuitive features render email related tasks effective and pain-free.

• Standard WebMail Interface
• Mobile WebMail

Users can access their Axigen email account from mobile phones with Internet connectivity to check their emails, compose messages, give others permissions on their folders or download attachments.

• Personal Organizer

Users can organize their business with effective time-management tools such as personal and public calendars, journal, tasks and notes.

• Address Book (contacts, groups and distribution lists)

The address book features personal contacts, public contacts (domain-admin defined) and email addresses of all accounts in the same domain. Distribution lists (user-defined groups of contacts and other email addresses) can also be accessed from the address book.

• RPOP (Remote POP Connections)

Users may retrieve messages from other email services (such as Gmail, Yahoo or any POP3 enabled service) in their Axigen inbox, in specific folders.

• Rules & filters

Outlook-like rules and filters such as "Move to folder", "Delete", "Forward" and others are available for administrators at server, domain or account level and for users via the Webmail interface or an Axigen Outlook Connector profile.

• Multiple languages and skins

The Webmail Ajax and Standard interfaces are brandable and localized in over 30 languages. The standard WebMail interface comes with several skins to be used at the end-user's choice.

• WebMail message printing

WebMail users can take advantage of the built-in print function that will automatically reshape the message in a printer-friendly form before sending it to the printer. Moreover, multiple messages can be selected for printing in a single operation.

• Out-of-office messages

Personalized auto-reply messages can be defined by the user from Axigen's WebMail, selectively for internal (local domain) or external senders.

• Account aliases
• Individual blacklists

Each user may define his/her own list of email addresses from which messages will be automatically deleted (moved to Trash).

• Personalized user signature
• Access the same PIM via WebMail or Outlook

The same Contacts and Calendar (Events, Tasks, Notes and Journal) entries are viewable from both an Axigen Outlook Connector and WebMail interface.

• Overquota notifications

Users are notified when the mailbox usage is close to quota or when the quota is exceeded via messages and WebMail pop-ups.

• Request temporary email addresses (aliases)

Users can request a one or more random temporary aliases for use when subscribing to public sites, in order to avoid spam. Temporary email addresses expire after the time period defined by you.

Security / AntiVirus / AntiSpam

• Kaspersky AntiVirus (add-on)
• Kaspersky AntiSpam (add-on)
• AVG Antivirus and AntiSpam for Linux/FreeBSD (add-on)
• Commtouch Real Time AntiSpam Protection (add-on)
• Content filtering (score based) & Bayesian filtering (through the included SpamAssasin)
• Direct integration with AntiVirus & AntiSpam applications

Native connectors for AV / AS filtering for selected applications are available, providing faster and more controllable filtering (you can define specific actions on suspicious messages or on messages that cannot be cleaned).

• Integration through MILTER with AntiVirus & AntiSpam applications

Axigen provides a Milter interface, thus allowing virtually any Milter-capable anti-virus or anti-spam application to be used.

• Interface for anti-virus, anti-spam, third party, custom made filters

Axigen's Filtering Interface allows interoperability with an external, third party application, such as anti-virus, anti-spam, content filtering or billing.

• Server, domain and user level filters

Specific sets of filters can be configured for each domain or even for selected accounts in order to differentiate security policies.

• Anti-Impersonation

You can enforce user authentication on message submission and verify that the sender header matches the authentication credentials preventing impersonation attempts from local accounts.

• Access Control / Whitelisting / Blacklisting / Greylisting
• Email addresses whitelisting / blacklisting
• Country Filtering

This filtering helps you determine geographic locations based on IPs and create rules accordingly, such as banning or allowing emails sent from the selected countries.

• Restrict maximum simultaneous connections

You can restrict the total number of simultaneous connections that a service may accept and/or the maximum number of simultaneous connection accepted from the same IP address, in order to avoid attacks from a single IP. Additionally, privileged IP address groups (trusted servers) may have different connection limits policies.

• Restrict maximum incoming connections rate

Similarly, you can restrict the total number of connection per time unit that a service may accept and/or the maximum number of connection per time unit accepted from the same IP address in order to avoid attacks from a single IP. Additionally, privileged IP address groups (trusted servers) may have different connection rate limits policies.

• Selectively restrict maximum messages size

The server can be configured to accept different maximum messages sizes based on sender/sender domain, recipient/recipient domain, remote IP address, connection security, authentication level and other message or connection related parameters, ensuring a flexible protection for the queue and the storage. Privileged users may have extended rights.

• SMTP peer reverse DNS lookup validation
• Originating domain MX validation
• Sender validation - SPF (Sender Policy Framework)

Axigen implements a standard-based SPF verification module for sender validation (if the remote domain is properly configured with SPF information).

• Open Relay Blocking (ESMTP APOP, AUTH login, CRAM-MD5, PLAIN authentication)
• Message integrity validation - DomainKeys compliant

The messages’ integrity may be checked if the originating server used DomainKeys to sign them. Locally-originated messages may be signed by Axigen to allow validation by DomainKeys-compliant remote servers (Yahoo associates a higher spam score to unsigned messages).

• Encryption policies (SSL / TLS)

Axigen’s encryption methods guarantee secure data transmission over networks (attempt or force connection level security).

• Authentication (Normal login, PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5, GSSAPI)

The Axigen mail server can be instructed to accept only connections/messages from authenticated entities (specific sources or destination domains).

• SASL authentication support
• Security policies

Axigen can support corporate governance rules or different service levels for users.

• Secure passwords enforcement

You can define password strength policies (minimum password length, required sets of characters and so on), restricting the users from setting simple passwords.

• Identity Confirmation

Email SMTP server

• Extended SMTP support
• SMTP routing
• Activity logging
• Encryption support
• Authentication support
• Access Control / Whitelisting / Blacklisting

You can define IP access control rules (allow/deny) on POP3 service level. If more granular access control is required, rules can also be defined on each listener of the POP3 service. Rules may refer to unique IPs, IP ranges or IP/Netmasks.

• Usage restrictions

You may selectively allow specific users to submit messages via SMTP, alternatively or in conjunction with WebMail-only usage.

• Connection control

The SMTP service supports specific simultaneous connections and connection rates limits, allowing you to adapt to the specific SMTP usage scenarios.

• Message acceptance policies

Axigen can be configured to reject messages sent by impersonated users (unauthenticated users or messages where the sender header differs from the authentication credentials), messages coming from blacklisted IPs, messages that fail SPF or DomainKeys verification etc. and similarly, to accept messages coming from trusted sources or through secure connections. You can selectively restrict maximum message size, maximum number of relay servers an incoming message passed through etc.

• Message delivery retries

The maximum number of delivery retries and the delivery retry intervals can be easily controlled. You can define the subject and body of the temporary or final non-delivery reports per server or selectively per sender or recipient domain.

• Routing policies

You can define outbound routes (relay servers), globally or per destination domain as well as outbound connection security parameters (SSL / TLS connections, SMTP authentication etc.).

• Message appender
• Management of incorrectly folded email headers

Axigen can be configured to accept and fix incorrectly formatted inbound messages (having malformed headers).

POP email acces

• APOP authentication
• Activity logging
• Encryption support
• Authentication support
• Access Control; IP Whitelisting / Blacklisting

IP access control rules (allow/deny) can be defined on POP3 service level. If more granular access control is required, rules can also be defined on each listener of the POP3 service. Rules may refer to unique IPs, IP ranges or IP/Netmasks.

• Usage restrictions

You can selectively allow specific users to retrieve messages via POP3, alternatively or in conjunction with WebMail-only usage.

• Connection control

The POP3 service supports specific simultaneous connections and connection rates limits, allowing you to adapt to the specific POP3 usage scenarios.

• Sub-folder support

By extending the standard POP3 protocol, Axigen’s POP3 service allows users to access subfolders by logging in with "user+subfolder" instead of plain "user".

IMAP email access

• IDLE Support

Axigen will notify IMAP clients when new messages arrive in specified folders, avoiding repeated polling that overloads the network.

• Activity logging
• Encryption support
• Authentication support
• Access control; IP Whitelisting / Blacklisting

IP access control rules (allow / deny) can be defined on IMAP service level. If more granular access control is required, rules can also be defined on each listener of the IMAP service. Rules may refer to unique IPs, IP ranges or IP / Netmasks.

• Usage restrictions

You can selectively allow specific users to retrieve messages via IMAP, alternatively or in conjunction with WebMail-only usage.

• Connection control

The IMAP service supports specific simultaneous connections and connection rates limits, allowing you to adapt to the specific IMAP usage scenarios.

• Public Folders
• Internationalized search

IMAP clients can use special local characters when searching messages.

WebMail access

• Drag-and-drop functionality
• Dynamic loading / "Refreshless" updates
• Keyboard navigation and shortcuts
• Smart attachment management
• Export/Import contacts
• Service levels for basic and premium users

You can offer different services for specific accounts (access to WebMail and mobility, exposure to advertising etc.) or set restrictions (maximum number of attachments, maximum attachment size, maximum number of recipients, etc), thus differentiating between basic and premium users.

• Built-in HTTP server

The WebMail interface is provided through Axigen’s proprietary HTTP server, increasing the overall security and reliability of the system. Moreover, data is accessed directly from the storage and messages are injected directly in the queue, resulting in smaller response times for the WebMail service.

• Re-branding support through server-side templates

The graphic design and general layout of the WebMail interface can be modified to accommodate the specific customer’s brand and usage requirements.

• Activity logging
• Encryption support
• Access control; IP Whitelisting / Blacklisting

IP access control rules (allow / deny) can be defined on WebMail service level. If more granular access control is required, rules can also be defined on each listener of the WebMail service. Rules may refer to unique IPs, IP ranges or IP/Netmasks.

• Usage restrictions

You can selectively allow specific users to access the mailbox through the WebMail interface, alternatively or in conjunction with IMAP/POP3 usage.

• Connection control

The WebMail service supports specific simultaneous connections and connection rates limits, allowing you to adapt to the specific WebMail usage scenarios.

• Available in over 30 languages
• Multiple skins

The user may choose any of the predefined skins, changing the look and feel of the WebMail interface.

• Multi-level folder management
• Virtual domains support
• Domain specific WebMail templates
• Read receipts
• Rules & filters (Outlook-like)
• Out-of-office automatic replies

Personalized auto-reply messages can be defined by the user from Axigen's WebMail, selectively for internal (local domain) or external senders.

• Internationalized search

Users can type special local characters when searching messages.

• Preview pane
• Public folders
• Personalized user signature
• User-level blacklist

Each user may define his/her own list of email addresses from which messages will be automatically deleted.

• RPOP

Users may retrieve messages from other email services (such as Gmail, Yahoo or any POP3 enabled service) in their Axigen inbox, in specific folders.

• RPOP templates for Yahoo! and Gmail

There are simplified RPOP settings for retrieving messages from the users’ Yahoo! or Gmail accounts in their Axigen inbox.

• Image attachments viewer

Image attachments can be browsed directly in the preview pane of the WebMail interface.

• HTML filtering

Axigen eliminates malware contained in HTML messages by filtering hidden scripts.

• Overquota notifications

Users are notified when mailbox usage is close to quota or when the quota is exceeded via messages and WebMail pop-ups.

• HTML composer

Users have available rich-text styles such as bold, italic, underline, strikeout, different font faces and font sizes, colors and so on when composing or replying to email messages.

• Address Book

Personal contacts, public contacts (domain-admin defined) and email addresses of the accounts in the same domain are available in the address book.

Shared folders & permissions

• Shared folders

Users can share their personal folders by granting permissions (read, write, delete etc.) or predefined sets of permissions (viewer, contributor, editor, master) to other users/groups in the same domain.

• Permissions on calendar, contacts, tasks, notes and journal folders

Special folders can also be shared to other users by setting appropriate permissions.

• Permissions on public folders

The postmaster can control access to public folders, restricting groups or specific users from performing actions on defined public folders (read, insert or delete messages). Public folder permissions also facilitate allocation of shared resources such as meeting rooms or projectors by creating a dedicated public calendar folder

• Permission inheritance over the folder tree

A set of permissions applied to one folder may be inherited to all subfolders (all subsequent changes will automatically apply to the entire structure). Additionally, exceptions to this set of permissions may be defined to a specific subfolder or even an entire branch. For instance, one user can grant full permissions on his mailbox to a co-worker except for one "secret" folder

• Permissions on group hierarchy

A user group may be granted permissions on specific folders. Every new added member inherits the complete permissions set. Any change in the permission set for the group is automatically applied to all members. Additionally, exceptions may be defined for specific users or groups. For instance, you can apply a set of permissions to the "Sales" group - each new member will have the same permissions, and additional permissions can be added to the team leader.

• Send emails on behalf of other users

A user can delegate the right to send messages in his name to a co-worker in the same domain. If anti-impersonation is enabled, Axigen will forbid sending emails as another user (altering the "From" header). Granting the "Send mail as" permission will allow the co-worker to send emails on behalf of the user via the Webmail interface or an Axigen Outlook Connector profile, still maintaining the anti-impersonation enforcement to the whole server.

• Availability information from other users

When requesting a meeting, users can consult the calendar of other attendees in order to check their availability (free/busy status).

• Domain Address Book restrictions

The postmaster of a domain is able to restrict the access to the Domain Address Book for a specific set of users, if needed.

Outlook Connector

• Offline mode

While performing their daily tasks, users no longer depend on being connected to the network in order to access their messages, contacts, calendars or tasks from the Microsoft Outlook email client. All changes performed in offline mode are automatically synchronized with the Axigen mail server once the access to Internet is restored, while also enabling the sending of messages from the Outbox folder.

• Improved search and mail access speed
• Read receipts
• Per-folder synchronization levels
• Public folders
• Calendar
• Meeting requests
• Tasks, assign tasks
• Notes
• Journal
• Address Book

Personal contacts, public contacts (domain-admin defined) and email addresses of the accounts in the same domain are available in the address book.

• UNICODE support
• Search folders

Users can create virtual folders containing messages that match a specific search criterion ("large messages", "unread messages", "messages sent only to me" etc.).

• Notification messages

The Axigen Outlook Connector can show informational balloons regarding its activity.

• Branding support

On demand, companies and SPs can get the Axigen Outlook Connector branded with their details.

Mailing list server

• Email based subscribing and unsubscribing
• Search folders

Users can create private or public mailing lists by requiring subscription approval or allowing unapproved members.

• Posting moderation
• Activity logging
• Configure list subject prefix
• Expandable templates for body begin, body end
• Access to mailing list archive through WebMail

The mailing list owner can login using the WebMail interface in order to perform tasks like message list moderation, review mailing list archive and others.

Clustering support

• Multi-tier setup (front-end & back-end)

You can separate services (such as SMTP / IMAP / POP3 etc.) on different tiers to enhance the overall security of the system and to provide service high availability.

• LDAP authentication and routing

Account passwords and routing information can be stored in a central point to support the multi-tier setup.

• SMTP routing to back-end

Messages received by the front-end tier are delivered to the appropriate back-end server (depending on LDAP recipient information).

• POP3 / IMAP WebMail proxy

You can distribute mailboxes on multiple Axigen back-end servers and use separate front-end proxies to route POP3 / IMAP / WebMail connections to the appropriate back-end server.

• RH Cluster Suite integration

Upgrade

• Seamless upgrade from previous versions

The storage content is automatically upgraded from the previous version on the first run.

Migration tools (IMAP based)

• Manual account migration over IMAP
• Automatic, transparent accounts & messages migration

Axigen provides a dedicated engine that ensures an automatic and transparent migration process. Thus, all domains, accounts and mailboxes from any legacy mail server can be easily migrated to Axigen via IMAP, without service interruptions.

Backup & restore

• Online backup of accounts and messages

You can download domain configuration, accounts and messages using Axigen’s built-in backup and restore service. Thus, domain-level, account level or even folder-level data backups can be performed.

• Full or partial restore

Using Axigen’s built-in backup and restore module, you can restore full domains’ information, a specific account or even a specific folder of an account.

• Delegated backup

Delegated administrators may download backups of their domains.

Server infrastructure features

• Innovative architecture with integrated services (SMTP / IMAP / POP / WebMail)

You can avail of centralized management of the configuration for all the services through the WebAdmin or CLI. Services inter-operate natively, ensuring faster access and proper resource-access locking. Thus, simultaneous access via different services may be performed without risking data corruption.

• MPA (MultiPlatform Architecture)
• Multi-threaded mail engine
• Allow concurrent user access to resources
• RFC compliance

The Axigen services are implemented in conformance with industry standards (RFC, Internet drafts) providing a higher degree of interoperability with clients and other email servers.

Integration

• API for external filtering

Full documentation is provided for Axigen’s external filtering interface, allowing customers to integrate their own external filtering modules with the Axigen server. Thus, interoperability with third party applications such as content filtering or billing systems can be obtained.

• Templates for WebMail interface customization

Axigen’s WebMail interface is dynamically generated using HSP server-side templates. Customers may extend the provided templates design with a completely new template set obtaining the desired WebMail interface look and feel.

• External LDAP authentication
• External Active Directory authentication

All Axigen services can use Kerberos tickets generated by Active Directory to perform user authorization, provided the mail client supports it (e.g. Mozilla Thunderbird, Novell Evolution).

OpenLDAP / Active Directory integration

• Accounts & groups synchronization
• LDAP authentication
• LDAP based routing

PIM Features

Web Personal Organizer

• Calendar
• Meeting requests
• Tasks, assign tasks
• Notes
• Journal
• Address Book

Personal contacts, public contacts (domain-admin defined) and email addresses of the accounts in the same domain are available in the address book.

• Search folders

Users can create virtual folders containing messages that match a specific search criterion ("large messages", "unread messages", "messages sent only to me" etc.).

Mobility Features

Users can access their email and personal info such as contacts, calendar etc., by using Push Email Synchronization or the Mobile WebMail interface.

Push Email & PIM Synchronization via ActiveSync

Handling business operations is now easier when using Axigen's built-in Microsoft Exchange ActiveSync support for mobile devices, used for synchronizing Contacts / Calendar / Tasks.

BlackBerry support (Push Email & PIM Sync) via the AstraSync or the NotifySync client

Axigen provides business travelers with instant access to relevant data such as emails, contacts or calendars, regardless of time and location, from their BlackBerry devices, via the AstraSync or the NotifySync client.

• Push Email & PIM Synchronization

The built-in Microsoft Exchange ActiveSync support for mobile devices, through its Push email technology and synchronization of Contacts / Calendar / Tasks, provides road-warriors with instant access to mission critical information such as messages, contacts or appointments.

• Blackberry Support

The NotifySync and the AstraSync solutions for BlackBerry smart phones complements Axigen's range of already supported mobile devices. It provides organizations of all sizes with two-way, over-the-air synchronization of email messages, contact data, calendar entries or tasks lists.

Mobile WebMail

The Mobile WebMail interface enables users to access their WebMail account from mobile phones. If the connecting browser is recognized as a mobile phone browser, the Axigen WebMail service will serve the light XHTML version instead of the standard/Ajax WebMail pages, allowing users to check their emails, compose messages, download attachments and much more.

Server Administration

Smartly structured administration offers the option of local or remote access to servers. With the web-based administration front-end, configuration is a breeze and maintenance simple and straightforward, while all day-to-day tasks can be easily automated.

Account classes

All account management uses inherited hierarchies and defined exceptions, so you can easily create different groups of accounts, differentiating the service levels (allowed services, message size quota, filters applied, etc).

• Configuration groups

You can create groups of users that share the same set of settings, such as service availability, mailbox usage quotas or anti-virus / anti-spam scanning. Account classes also allow applying default domain settings as well as account-specific exceptions.

• Restrictions for sending / receiving messages

Restrictions for sending to specific recipient addresses or receiving from specific sender addresses can now be defined. These restrictions can be set as a policy for an entire domain, for an account class or for specific accounts.

• Dynamic configuration inheritance

Changes to domain-wide settings or account classes are instantly propagated to all accounts

• Multiple administrative users
• Groups for simplified management
• Server level permissions

Fine-grained control delegated administrators’ access level by setting specific server-level permissions like: manage server configuration, manage services, manage backup, manage reporting, manage delegated administration etc.

• Domain / subdomain level permissions

Domain administrators may have full permissions for a domain or a limited set, such as: manage accounts, manage groups, manage public folders or manage filters. The same permissions may be granted on a sub-domain level.

• Domain / subdomain level restrictions

A domain administrator may use restraints such as limiting the maximum number of users, maximum quota per user etc. for a specific domain. The same restrictions may be enforced on a sub-domain level.

• Subdomain administration

All the permissions and limitations set on domain level are automatically used when creating sub-domains that can further be administered as standalone domains. The server administrator can enforce the maximum number of sub-domains that a domain administrator is allowed to create.

• Delegated backup

Delegated administrators may download backups of their domains.

Administration: web based, command line

Configure service specific parameters through Axigen's Web Administration interface, with quick links and contextual help. Alternatively, you can automate administrative and provisioning tasks using the Command Line Interface with a web API.

• Remote server administration

Server administration can be performed either remotely or from the local network, using a secure connection to the Web Administration Console or using the Command Line interface, for lower bandwidth connections.

• Automated operations

Recurrent operations (inactive account deletion, storage compacting or any other administrative command) can be automated by using scripts that run the actions through the CLI.

• Services availability per account

You can enable or disable specific sets of services (IMAP, POP3, WebMail, RPOP) in order to differentiate end-user service levels.

• User groups

By creating user groups, others can send messages to predefined groups of email addresses (e.g. sales@yourdomain.com, support@yourdomain.com).

• Random password generation for new accounts
• Secure password enforcement

You can define password strength policies (minimum password length, required sets of characters and so on), restricting the users from setting simple passwords.

• Automatic creation of accounts from LDAP
• Overquota notifications

Mailbox quota usage thresholds can be configured such as users get notifications via email or WebMail pop-ups whenever the limit is exceeded.

• Delay the delivery of selected messages

Axigen allows you to selectively postpone the delivery of specific messages - for instance, delay with 10 minutes messages from the sales department in order to avoid accidental sending (those messages can be removed from the queue), or postpone delivery of lower importance messages for night-time. This feature can be applied for messages from specific sender and sender domains, recipient and recipient domains, message sizes and so on.

Delegated administration

Delegate administrative tasks to specific administrative users/groups with predetermined membership hierarchies and permissions for a specific domain / subdomain or even for specific operations.

Reporting & statistics

• Server & traffic statistics

You can monitor system load, connected users and sessions for each service, message queue size, average times spent executing service commands, values of inbound and outbound traffic counters etc. in order to obtain an overview of the server’s health and activity.

• Data collection and export

The increased granularity of the reporting service allows you to easily generate charts and reports at server level, for a specific domain (useful for Service Providers monitoring multiple domains and required to provide reports for each customer) or even for specific users in special cases. Collected data can be aggregated in charts or exported in XML or CSV formats.

• Graphic charts

All collected data can be represented in a graphical chart, using different types (bars, lines, etc), colors and outlines for differentiation. More than one parameter can be represented on the same chart, to facilitate the comparison between them. In most frequent cases, the selected interval has more collected values than can be displayed on the chart. Aggregation functions such as average, max, min etc., can be applied to allow relevant representations. Once a chart has been generated, the zooming option can be used in order to drill down within a selected interval to analyze the event of interest.

• Detailed storage reports

You can inspect storage utilization for each domain, as an overview or in details, for each element of the storage (domain objects, account storage and messages). Delegated administrators may also inspect storage utilization information, if they are granted permission to do so.

• SNMP service

Server running parameters can be monitored in real-time using standard SNMP monitoring systems.

Branding & Localization

The WebMail interface and Axigen Outlook Connector can be easily branded to have your organization's look and feel. Additionally the WebMail interface can be localized in your native language (it is already available in the languages specified below) and has several skins to be used at the end-user's choice.

• Arabian
• Chinese Simplified
• Chinese Traditional
• Czech
• German
• Danish
• Estonian
• English
• Spanish
• Finnish
• French
• Greek
• Hindi
• Croatian
• Hungarian
• Indonesian
• Hebrew
• Italian
• Japanese
• Lithuanian
• Dutch
• Norwegian
• Polish
• Portuguese
• Romanian
• Russian
• Swedish
• Serbian
• Slovak
• Slovenian
• Turkish

Security Layers

Axigen comes with a full security feature set, guaranteeing secure reception, transit and delivery of email and protection for your confidential data.

Authentication

The Axigen mail server supports authentication, meaning it can be instructed to accept only connections / messages from authenticated entities. Normal login, LOGIN, PLAIN, CRAM-MD5, DIGEST-MD5 and GSSAPI methods are available for client authentication, reducing the risk of unauthorized connections.

Encryption (SSL/TLS)

All Axigen communication protocols can benefit from SSL/TLS technology which allows sending encrypted messages across networks and preventing plain text messages to be intercepted on the way from sender to recipient. This encryption method guarantees secure data transmission over networks.

Built-in firewall (application level)

Stopping spammers and preventing DOS attacks is one of the most important tasks of a mail server and the sooner the problem is identified in the mail stream, the better. This is why Axigen has a built-in firewall at the application (TCP listener) level that allows you to control connectivity parameters, like the following listener rules:

• maximum simultaneous connections;
• maximum connections to be accepted during a time interval;
• maximum simultaneous connections accepted from a single host (that may be an attacker).

Furthermore, you may define IP sets that have specific sets of such rules, applied with different priorities or IP sets whose connections are denied.

Anti-spoofing (SPF and DomainKeys compliant)

SPF authentication is used by the SMTP Incoming module in Axigen to determine whether the mail message comes from an authorized source. DomainKeys is an email authentication system designed to verify both the DNS domain of an email sender and the message integrity. This additional authentication method significantly reduces spoofing attempts (unauthorized attempts to gain server access), or assuming a fake identity when sending an email.

Message acceptance rules

You can configure and implement message acceptance policies 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 policies.

AntiVirus / AntiSpam

The Axigen mail server can easily integrate with a large number of anti-virus / anti-spam applications, either commercial, or open source.

Routing rules

The Processing policies correspond to the SMTP Processing and SMTP Outgoing modules. On one hand, they enable you to define the NDR (Non-Delivery Receipt) text and the conditions when such a message is returned. On the other hand, they allow you to customize SMTP Outgoing actions for all or part of the relayed email communication.

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.

Country filtering

This filtering enables you to determine geographic locations based on IPs and create rules accordingly, such as banning or allowing emails sent from selected countries.

Identity Confirmation

Axigen Identity Confirmation is basically the implementation of a Challenge / Response-based anti-spam method. It blocks unwanted messages from reaching your users' Inbox by intercepting incoming emails and requiring new senders to confirm their identity, without any effort from their part.

Greylisting

The "Greylisting" feature enables the Axigen server to automatically reject messages from unknown senders / IPs with a temporary error message ("451 Temporary rejected by greylisting"). Unlike legitimate email servers, most spam sources will not try to resend the emails in question, thus reducing the amount of spam received by Axigen.

Encryption

Axigen provides a variety of security options related to authentication and encryption for all connections established by/with the mail server.

Secure/Plain connections and authentication methods

Axigen supports TLS enabled connections. TLS-enabled connections are connections that support the Transport Layer Security, a standard providing encryption and authentication service that can be negotiated during the startup phase of many Internet protocols, including SMTP, POP3 and IMAP, and used for general communication authentication and encryption over TCP / IP networks.

All Axigen mail services (SMTP, IMAP, POP3) provide an AllowStartTLS parameter that you can enable and have the server advertise TLS capability.

Authentication methods are available both for TLS-enabled connections and plain connections (non TLS-enabled). The methods supported by Axigen are: PLAIN, LOGIN, CRAM-MD5, DIGEST-MD5 and GSSAPI.

The PLAIN mechanism consists of a single message from the client to the server, in which the client sends the authorization identity (identity to login as), the authentication identity (identity whose password will be used) and the clear-text password. If left empty, the authorization identity is the same as the authentication identity. The PLAIN authentication mechanism is not recommended for use over an unencrypted network connection.

The LOGIN mechanism is a non-standard mechanism, and is similar to the PLAIN mechanism except that this mechanism lacks the support for authorization identities.

The CRAM-MD5 is a challenge-response mechanism that transfers hashed passwords instead of clear text passwords. For insecure channels (e.g., when TLS is not used), it is safer than PLAIN.

The DIGEST-MD5 is the required authentication mechanism for LDAP v3 servers.

The Digest-MD5 is based on the HTTP Digest Authentication. In Digest-MD5, the LDAP server sends data that includes various authentication options that it is willing to support plus a special token to the LDAP client. The client responds by sending an encrypted response that indicates the authentication options that it has selected. The response is encrypted in such a way that proves that the client knows its password. The LDAP server then decrypts and verifies the client's response.

GSSAPI is the Generic Security Services Application Programming Interface. Its primary use today is with Kerberos authentication. Kerberos is the primary authentication mechanism in Windows Active Directory.

Also, for all Axigen services, authentication error control parameters are available. That is, if on attempting to connect, clients fail to authenticate correctly a number of times, the connection is dropped.

SSL Parameters

Axigen supports SSL-enabled connections, providing advanced SSL parameters for TCP Listener configuration available for all its TCP Services (SMTP, IMAP, POP3, WebMail, CLI and WebAdmin). See SSL Parameters for Listeners for information on these parameters and how to configure them using WebAdmin.

Also, for all Axigen services, authentication error control parameters are available. That is, if on attempting to connect, clients fail to authenticate correctly a number of times, the connection is dropped. For information on these parameters, see the Connection Error Control sections for each module in Configuring Axigen using WebAdmin.

Kerberos is the primary authentication mechanism in Windows Active Directory. Within the Axigen mail server, it is used as an authentication method through GSSAPI (Generic Security Services Application Programing Interface). In order to enable Kerberos authentication for your installed Axigen solution, please follow the steps described below.

1. Create an account named "axigen_SERVICE" in Active Directory corresponding to each service you want to authenticate on from Axigen. Three accounts will be used for all Axigen supported services: axigen_smtp, axigen_imap and axigen_pop.

2. Export the keys using the KTPASS utility:

• Generate a key for the SMTP service:

ktpass -princ smtp/axigen.hostname@REALM -mapuser axigen_smtp -pass PASSWORD -out axigen-smtp.keytab

• Generate a key for the IMAP service:

 ktpass -princ imap/axigen.hostname@REALM -mapuser axigen_imap -pass PASSWORD -out axigen-imap.keytab

• Generate keys for the POP3 service:

ktpass -princ pop/axigen.hostname@REALM -mapuser axigen_pop -pass PASSWORD -out axigen-pop.keytab

• In all commands shown above you must replace:
  1. "axigen.hostname"
     • with the domain Axigen users should use to login to REALM
     • with the Kerberos realm, particularly for Active Directory, with the domain name for which you want to authenticate
  2. "PASSWORD"
     • with the password for the corresponding "axigen_SERVICE" account, which you have previously created.
• Please note that the Axigen IP address must reverse point to the same hostname you have specified above as "axigen.hostname".

3. Copy the exported key files on the Axigen machine in the /etc directory and merge them using the "ktutil" application. Simply type "ktutil" and issue the following commands in the application's subshell:

• load the needed "keytab" files, according to the services you want to use GSSAPI authentication with:

rkt /etc/axigen-smtp.keytab
rkt /etc/axigen-imap.keytab
rkt /etc/axigen-pop.keytab 

• write the new "/etc/krb5.keytab" file:

wkt /etc/krb5.keytab 

• exit the "ktutil" shell:

quit

• At this moment, all necessary keys will be saved in the "/etc/krb5.keytab" file.

Prerequisites and Settings for Each Active Directory User Defined for Axigen

The Axigen domain name must be the same as the full Active Directory domain name. Also, the accounts for which you want to use Kerberos authentication must be created within the Axigen messaging solution.

Example:

The example below shows how to set up the Windows version of the Mozilla Thunderbird email client to use Kerberos authentication with in an Active Directory environment:

1. Open the "Account Settings" window from "Tools" -> "Account Settings...".
2. Click "Add Account". This will open the "Account Wizard".
3. Select "Email account" as the type of account to be created, then press "Next".
4. Fill in your name and email address and press "Next".
5. In the next screen, select "IMAP" or "POP" incoming server types, according to your network policy. 
Set the "incoming server" box to Axigen's fully qualified host name or the Axigen machine IP address.
6. Press "Next" and fill in the user account name as stored in Axigen. 
In the last screen, fill in the account name, then press "Next", review the settings and press "Finish".
7. Go to the "Server settings" section of the newly created account and check the "Use secure authentication" option. 
Also, if Axigen is configured to relay emails from authenticated users only and if you have created a keytab 
corresponding to the SMTP service (as shown above), add the Axigen hostname in the "Outgoing server (SMTP)" 
section, selecting the "Username and password" checkbox from the "Security and authentication" section.
8. Click the "OK" button from the "Account settings" window.

Multi-layer access control

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.

Filter types

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 3.2.5.4 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:

• onConnect
• onEhlo
• onMailFrom
• onRcptTo
• onHeadersReceived
• onBodyChunk
• onDataReceived

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 john@example.com copy to alex@localdomain;
• messages from jokes@domain.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.

Active filters

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.

Filtering levels

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.

Flow Control

Within the "Flow Control" section you can enforce global access limitations to the listener or service by setting the maximum number of:

• simultaneous connections;
• concurrent connections from each remote IP address;
• new connections to the listener made in a defined time period;
• maximum connections from each remote IP address in a defined time interval.

For example, based on your available bandwidth, you could restrict or allow more or less connections to be initiated on a specific Axigen service. Another scenario to modify these parameters is when a workstation from your local network is infected by a virus sending spam. Axigen will allow the infected workstation to send messages since it has no reason to do otherwise because the infected workstation uses the Axigen account credentials. In this case you can restrict the number of connections from each remote IP to an appropriate value.

SPF

SPF (Sender Policy Framework) is a sender authentication method developed in order to ensure mail server's security by applying different anti-spoofing mechanisms. This mechanism consists in making a DNS request in order to determine whether the mail message comes from an authorized source, which is described in a SPF record, registered on the DNS. SPF records contain domain attributes that uniquely describe mail messages.

The query may have one of the following seven possible results:

• pass: meaning the message meets the domain's definition for legitimate messages;
• neutral
• none
• soft fail
• fail: meaning the message does not meet the domain's definition for legitimate messages;
• temp error
• permanent error

In case of a permanent error, Axigen rejects the mail message generating the respective error. If a temporary error is generated, the Axigen mail server returns an error message to the sending party. In all other cases the mail message is accepted.

DomainKeys

Starting with v7.5, the new, embedded DomainKeys authentication can be configured by using advanced acceptance / routing rules. Axigen now implements both built-in DomainKeys and DomainKeys Identified Mail technologies.

For each DomainKeys process, signing and verifying, a SMTP filtering rule needs to be configured in your AXIGEN Mail Server, via the WebAdmin interface, under "Security & Filtering" -> "Acceptance & Routing" -> "Advanced Settings" -> click "Add Acceptance / Routing Rule".

For DomainKeys signing, the rule should be:

* Conditions:
  Match any email message
* Actions:
- Select "DK - DK Key Path" from the "Actions" list, click "Add Action";
- Fill in the "DK Key Path" field with the path to your private key file;
- Select "DK - DK Selector" from the "Actions" list, click "Add Action";
- Fill in the "DK Selector" field with the name of your DomainKeys selector, as configured in your DNS server;
- Select "DK - Sign Domain Key" from the "Actions" list, click "Add Action" - "Save Configuration"

For DomainKeys verifying, the rule should be:

* Conditions:
  Match any email message
* Actions:
- Select "DK - Check Domain Key" from the "Actions" list, click "Add Action";
- "Save Configuration"

Make sure you use suggestive "Rule names" for the above rules. For example: "DomainKeys-sign" and "DomainKeys-verify".

To use DKIM technology (DomainKeys Identified Mail), similar rules can be defined. The only difference is that you need to select the actions containing "DKIM". For example: "DKIM selector" instead of "DK Selector" / "Sign DKIM" instead of "Sign Domain Key".

Please note that your DNS must be configured accordingly in order to implement domain keys signing.

In order to find the benefits for implementing DomainKeys or DKIM please refer to:

• http://en.wikipedia.org/wiki/DomainKeys
• http://domainkeys.sourceforge.net/
• http://www.dkim.org/

Country Filtering

The Country Filtering feature allows you to configure restrictions based on the country name of the connecting peer IP, for the SMTP Incoming service.

In order to identify the country for a given IP, you can upload an IP to a country mapping database (in CSV format). The database can be downloaded from sources like MaxMind. A free version is available at GeoIPCountryCSV-lite

You can also configure the list of IPs or IP ranges to be skipped by the GeoIP look-up.

Blacklisting / Whitelisting / Greylisting

You can define a list of email addresses, blacklists, from which emails should always be rejected. On the other hand, you can also define a list of email addresses from which emails should always be accepted.

These rules are applied at the server level while the message is processed by the Queue Processing service. These filters are applied based on the "From" message header.

The "Greylisting" feature enables the Axigen server to automatically reject messages from unknown senders / IPs with a temporary error message ("451 Temporary rejected by greylisting"). Unlike legitimate email servers, most spam sources will not try to resend the emails in question, thus reducing the amount of spam received by Axigen.

DNSBL

A DNSBL (DNS-based Blackhole List, Block List, or Blacklist) is a list of IP addresses published through the Internet Domain Name Service in a particular format. A blacklist usually refers to a list of email or IP addresses known to send spam emails or some other type of unsolicited messages. Such lists are currently used by mail servers for filtering incoming emails and blocking the ones listed, in order to improve mail security and integrity. The blacklist is also the opposite of what is called a whitelist. Excluding IP or IP ranges from DNSBL checks is also available in Axigen.

Furthermore, a connection is not rejected if the sender is authenticated even if the connecting IP is listed in one of the DNSBL operators used.

DNS Checks

Additional validations that can be run to reject spam are checking the originating domain for MX entries and the originating IP for a reverse DNS entry.

A mail exchanger record (MX record) is a type of resource record in DNS that specifies a mail server responsible for accepting email messages on behalf of a recipient's domain. Most of the times, the same mail server is responsible for sending email messages too, and therefore enabling MX checks will protect you from unsolicited messages from spammers.

Identity Confirmation

Axigen Identity Confirmation© is basically the implementation of a Challenge / Response-based anti-spam method. It blocks unwanted messages from reaching your users' Inbox by intercepting incoming emails and requiring new senders to confirm their identity, without any effort from your / their part.

The Identity Confirmation system compares the sender of each incoming message against the contents of your Address Book. As a result:

• If the sender appears in the Address Book, the message comes through, as expected.
• If the incoming message originates from an unknown address, the Challenge / Response system sends an auto-reply email designed to confirm its authenticity. Once the address in question is verified, the message is delivered appropriately, as are all subsequent messages from the same sender.

Features of the Identity Confirmation:

• All the received, yet unconfirmed, messages are permanently available for your inspection, without them crowding your users' Inbox, as they are stored in a specific "Unconfirmed Messages" folder.
• The confirmed senders are automatically added to their "Collected Addresses" contact folder (part of your Address Book).
• The validation code is at their disposal to change whenever they want to.
• Users can configure the number of days to be skipped when sending the confirmation request to a sender.

While a Challenge / Response request can be easily fulfilled by a real person, it can hardly be performed by a spammer, on the following grounds:

• Legitimate senders have a valid return address while spammers usually forge a return address. This means that most spammers won't get the challenge, which results in them automatically failing any required action.
• Spammers send email in large quantities and would have to perform Challenge / Response actions in large numbers, while legitimate senders would only have to perform them once for every new email contact, at the most.

Even if activated, this mechanism is, of course, not enforced for the users already in the users' Address Book, or present in their Whitelist / Safe senders list.

AntiSpam

Axigen direct connectors for third party scanners

Also known as Axigen direct connectors, these filters apply once the spam and malicious messages have already been thinned-out by the previous SMTP level filters. They provide the most performance-effective method of integration by closely communicating with the third party scanners installed on the system.

The scanners receive instructions from the Axigen messaging solution through these filters and once the scan is complete, provide the relevant results back to the server. Using these results, Axigen decides the fate of the messages, including dropping or accepting the message. These actions can be fully customized to fit the requirements of any email traffic regulations.

The Axigen messaging solution provides custom-built and tested connectors for the following list of scanners, reducing the configuration required for the integration process to a minimum:

• SpamAssassin
• Commtouch

Axigen Milter integration for third party scanners

The Milter integration method acts at the SMTP level and follows the same baseline functionalities as the direct integration method through the connectors. However, a few differences exist between the two approaches, such as lower performance results and a broader compatibility with third party scanners for the Milter, as opposed to the direct integration.

Milter is actually a protocol that was originally designed for open-source mail transfer agents, but is currently being adopted as the new standard in the industry by a large number of email-related software vendors. Through this standard approach, any scanner that supports the Milter can be integrated with the Axigen messaging solution. The result of this feature is an extensive list of scanners that can be integrated with it, thus expanding Axigen's ability to fit the needs and requirements of the environment it's being deployed in.

The complete list of scanners supported and tested through the Milter integration method follows:

• SpamAssassin
• Avira MailGate Suite (AV/AS)
• BitDefender Security for Mail Servers (AV/AS)
• Brightmail AntiSpam

AntiSpam filters are dynamic filters executed by external processes. These types of filters are based on a file defining the communication protocol between Axigen and the external process executing the filter.

AntiSpam filters can also interact with Message Rules, via headers appended to email messages. These headers contain a spam level value which actually indicates the likelihood of that particular email message being 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 a customized filter chain. This means you can define and use as many AntiVirus / AntiSpam Filters and Message Rules as required by your company's security policies.

In Axigen, anti-spam / anti-virus filters calls are multi-threaded. This means that filters can be applied on several emails at the same time, improving thus service availability and processing speed.

If one of the filters in the filtering chain does not respond, Axigen provides a failsafe mode, which allows pinging the filter regularly until the connection is re-established. At that moment, the email message filtering chain is resumed. This guarantees that every message goes through the entire filtering chain.

The Axigen messaging solution 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.

AntiVirus

Axigen direct connectors for third party scanners

Also known as Axigen direct connectors, these filters apply once the spam and malicious messages have already been thinned-out by the previous SMTP level filters. They provide the most performance-effective method of integration by closely communicating with the third party scanners installed on the system.

The scanners receive instructions from the Axigen messaging solution through these filters and once the scan is complete, provide the relevant results back to the server. Using these results, Axigen decides the fate of the messages, including dropping or accepting the message. These actions can be fully customized to fit the requirements of any email traffic regulations.

The Axigen messaging solution provides custom-built and tested connectors for the following list of scanners, reducing the configuration required for the integration process to a minimum:

• avast! for Linux/Unix Servers
• Clam AntiVirus
• AVG AntiVirus Email Server Edition
• Commtouch

Axigen Milter integration for third party scanners

The Milter integration method acts at the SMTP level and follows the same baseline functionalities as the direct integration method through the connectors. However, a few differences exist between the two approaches, such as lower performance results and a broader compatibility with third party scanners for the Milter, as opposed to the direct integration.

Milter is actually a protocol that was originally designed for open-source mail transfer agents, but is currently being adopted as the new standard in the industry by a large number of email-related software vendors. Through this standard approach, any scanner that supports the Milter can be integrated with Axigen. The result of this feature is an extensive list of scanners that can be integrated with it, thus expanding Aixgen's ability to fit the needs and requirements of the environment it's being deployed in.

The complete list of scanners supported and tested through the Milter integration method follows:

• Avira MailGate Suite (AV/AS)
• BitDefender Security for Mail Servers (AV/AS)

AntiVirus Filters are dynamic filters executed by external processes. These types of filters are based on a file defining the communication protocol between Axigen and the external process executing the filter.

AntiVirus Filters can also interact with Message Rules, via headers appended to email messages. These headers contain a virus level value which actually indicates the likelihood of that particular email message being infected. 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 your company's security policies.

In Axigen, anti-spam / anti-virus filters calls are multi-threaded. This means that filters can be applied on several emails at the same time, improving thus service availability and processing speed.

If one of the filters in the filtering chain does not respond, Axigen provides a failsafe mode, which allows pinging the filter regularly until the connection is reestablished. At that moment, the email message filtering chain is resumed. This guarantees that every message goes through the entire filtering chain.

The Axigen messaging solution 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.

Message acceptance policies

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, they 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 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 named smtpFilters.script. They can also be created automatically via the WebAdmin Wizard.

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:

• onConnect
• onEhlo
• onMailFrom
• onRcptTo
• onHeadersReceived
• onBodyChunk
• onDataReceived

Message routing policies

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

Incoming 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.

Thus you can create rules like:

• messages from john@example.com copy to alex@localdomain;
• messages from jokes@domain.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. For more details on Wizard usage, please see "Mail filtering" in WebMail.

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.

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.).

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.

SIEVE overview

SIEVE is a language created and used for mail filtering either on the server or on the client. The language is completely described in the RFC 3028. SIEVE is an interpreted language that can be described as relatively simple. It has no loop structures, no variables (in the basic form) it has only an if control structure.

SIEVE works basically by comparing different keys using different comparators and comparison methods, against headers of a mail message and based on the result applies actions to the message (such as reject, discard, redirect).

The structure of SIEVE as described in the RFC 3028 is:

SIEVE defines 5 actions: keep, fileinto, reject, discard, redirect - which are self-explanatory.

It also defines 3 control commands:

• <stop> - which stops the processing to that point
• <if elsif else> structure
• require command - which defines an extension of the language. It tells the interpreter that the respective extension will be used in the script

The if structure has the form: if <test> <block> elsif <test> <block> else <block>

A block is a block of commands (actions and control commands - including other ifs) and a test can be one of the following:

1. address - tests a set of the address headers against a set of keys using different comparison methods
2. envelope - optional test
3. header - tests a set of the headers against a set of keys using different comparison methods:
   • true, false - constants
   • allof <other tests> - logic and between several tests
   • anyof <other tests> - logic or between several tests
   • not <test> - negation of a test
   • exists - test if a set of headers exist
   • size - test against the size of a message

A test can take 2 values: true or false.

After parsing a script against a mail message, several actions can result which may interact. Several constrains are defined regarding action interaction which will be explained in the next paragraph. If no action is to be taken after a complete parse of the script, or an error occurs, an implicit keep will ensure delivery of the message to the Inbox.

The Axigen SIEVE interpreter

The interpreter uses the following restrictions and constrains in implementing the RFC 3028:

• it implements the extensions described in the RFCs: "fileinto", "reject", "envelope", "copy", "relational", "spamtest", "virustest", "subaddress".
• the relational test: "count" can only be used with the "i;ascii-numeric" comparator and when there are more then one strings in the second string list, only the first will be considered.
• it implements the "i;octet", "i;ascii-ccasemap" and "i;ascii-numeric" comparators for the "i;ascii-numeric" comparator, the ":matches" and ":contains" tags, cannot be used. Error otherwise.
• it allows only require with (fileinto, reject, envelope, copy, vacation) arguments, gives an error message otherwise.
• it allows address and envelope test with the second string list (the values list) not tested for valid addresses (i.e. it allows part of addresses put in the values list).
• it allows only the: "From", "To", "CC", "Bcc", "Sender", "Resent-From", "Resent-To" headers to appear in the address test and only "To", "From" headers in the envelope test. Error otherwise.
• the required group of commands must appear first and must contain only required commands. Error otherwise.
• elsif and else must appear only after an if or an elsif. Error otherwise.
• there is one type of warning and five types of error messages:
  1. "[Syntax Error]: given if there is a syntax error in the script"
  2. "[Parse Error]: if a semantic error appears"
  3. "[Semantic Error]: similar to parse error"
  4. "[Validation Error]: if the script is not compliant to this document"
  5. "[Run-time Error]: if something is wrong during a message parse"
• numbers in the size test cannot be negative and cannot exceed 2^32-1. Error otherwise.
• numbers when using the "i;ascii-numeric" comparator cannot exceed 2^32-1 and cannot be negative. If a string used with this comparator starts with something other than a digit, or it's null or negative, or it exceeds 2^32-1, it gets the value 2^32. Leading whitespace (SP,HTAB,CRLF) is ignored.
• it does not allow two or more comparator, address-part, match-type tags in the address, hearer and envelope tests. Error otherwise.

Action interaction

General action interaction - the following constrains apply (error otherwise):

• "reject" can only be by itself and only once (eventually with "stop");
• "keep" can appear with any action (except "reject") several times, and a move to inbox (or similar) will be executed once;
• "discard" can appear with any action (except "reject") several times and the result will be a discard only when solely discard actions are present or there is an implicit "keep" by using the ":copy" tag;
• "fileinto" can appear several times with any action (except "reject") and a move to the specified folder will be executed (if a move to the same folder is specified, it is treated as an error, but a duplicate move will not be performed - a warning will be issued);
• "redirect" can appear several times and with any action (except "reject"), the result consisting in redirecting to the specified address only once (without giving an error if a duplicate reject with the same address appears) - a warning will be issued;
• any action except "stop", "fileinto", "vacation" and "redirect" used with the ":copy" tag will cancel the implicit "keep".

Vacation interaction:

• "vacation" can appear once per script and all other appearances will be disregarded;
• "vacation" used with "discard", "redirect", "fileinto" or explicit "keep" will not be an error and will not be considered to break the respective actions interaction rules.

Spamtest and Virustest extension

This implementation supports the spamtest and virustest extensions as described in the RFC 3685, but in each case, the following constrains appear:

1. Spamtest
   • a separate tool will be implemented that will map vendor specific information from anti-spam tool
   • a new header named "X-AxigenSpam-Level" will be added which can have the following values:
     • 1 - message was tested and is clear of spam
     • 2 - 9 - message was tested and has a varying likelihood of containing spam in increasing order
     • 10 - message was tested and definitely contains spam
2. Virustest
   • a separate tool will be implemented that will map vendor specific information from anti-virus tool
   • a new header named "X-AxigenVirus-Level" will be added which can have the following values:
     • 1 - message was tested and contains no known viruses
     • 2 - message was tested and contained a known virus which was replaced with harmless content
     • 3 - message was tested and contained a known virus which was "cured" such that it is now harmless
     • 4 - message was tested and possibly contains a known virus
     • 5 - message was tested and definitely contains a known virus

The possible values of the header SHOULD be only numbers and if so MUST be only the above numbers, but may also have leading and trailing spaces and may contain alphanumeric characters after the numbers. There may be maximum one header of each type at a given moment, and when the tool has a value to assign to the header, it will assign it only if it is greater than the value already contained in the header.

Vacation extension

The vacation extension is implemented using the draft: draft-ietf-sieve-vacation-04. The vacation extension is used to send auto-generated messages when the user of the account for which the vacation applies, is in vacation, out of office, in general away for an extended period of time.

For a description of the syntax of this extension, please consult the SIEVE related documents and the draft this implementation is based of.

Implementation specific issues like restrictions and constrains and general issues that appear in the draft with SHOULD or MAY, are defined below:

• The minimum value for the vacation: days argument is 1 and the maximum is 45. If the value given to the days argument is less that 1 it will be considered 1 and if greater that 45, it will be considered 45. The default value if the days parameter is omitted is 7.
• The "Previous Response Tracking" feature (section 4.2 of the draft) is implemented using a CRC32 hash and the date when the response was sent. This means that there may be cases when a second response will be generated even though it was not supposed to, but the chances of that is negligible compared to the speed gain.
• The "Limiting Replies to Personal Messages" feature (section 4.6 of the draft) was implemented considering the same cases as in the draft, but this will change in a way to allow you to define custom rules for recognizing auto-generated mails.
• The vacation response message is generated with all the features defined in the Section 5 of the draft except the "References" field that is not generated in this version of the implementation.

The interaction between vacation and other actions is described above, under "Action interaction".

RFCs currently implemented

POP3

• RFC 1939 - Post Office Protocol (version 3)
• RFC 2449 - POP3 Extension Mechanism
• RFC 1734 - POP3 AUTHentication command

POP3 and IMAP Specifications

• RFC 2195 - IMAP/POP AUTHorize Extension for Simple Challenge/Response
• RFC 2595 - Using TLS with IMAP, POP3 and ACAP

SMTP specifications

• RFC 2821 - Simple Mail Transfer Protocol
• RFC 821 - Simple Mail Transfer Protocol (obsolete)
• RFC 822 - Format of ARPA Internet text messages
• RFC 974 - Mail routing and the domain system
• RFC 3501 - Internet message access protocol (version 4rev1)
• RFC 3848 - ESMTP and LMTP Transmission Types Registration

SMTP service extensions

• RFC 2821 - Simple Mail Transfer Protocol
• RFC 1869 - SMTP Service Extensions
• RFC 2554 - SMTP Service Extension for Authentication
• RFC 1830 - SMTP Service Extensions for Transmission of Large and Binary MIME Messages
• RFC 2920 - SMTP Service Extension for Command Pipelining
• RFC 1652 - SMTP Service Extension for 8bit-MIME transport
• RFC 1870 - SMTP Service Extension for Message Size Declaration

IMAP specifications

• RFC 3501 - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
• RFC 2342 - IMAP4 Namespace
• RFC 2180 - IMAP4 Multi-Accessed Mailbox Practice
• RFC 2683 - IMAP4 Implementation Recommendations
• RFC 2087 - IMAP4 QUOTA extension
• RFC 2359 - IMAP4 UIDPLUS extension
• RFC 2088 - IMAP4 non-synchronizing literals
• RFC 2177 - IMAP4 IDLE command
• RFC 3502 - Internet Message Access Protocol (IMAP) - MULTIAPPEND Extension
• RFC 3348 - The Internet Message Action Protocol (IMAP4) Child Mailbox Extension
• RFC 4314 - IMAP4 Access Control List (ACL) Extension

HTTP specifications

• RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
• RFC 2965 - HTTP State Management Mechanism
• RFC 2396 - Uniform Resource Identifiers (URI): Generic Syntax

DNS specifications

• RFC 1034 - Domain names, Concepts and Facilities
• RFC 1035 - Domain names, Implementation and Specification

SIEVE extensions implemented in Axigen

• RFC 3028 - SIEVE: A Mail Filtering Language (Extensions defined in the base RFC: fileinto, reject, envelope)
• RFC 3894 - SIEVE Extension: Copying without Side Effects
• RFC 3431 - SIEVE Extension: Relational Tests; Comparator extension: i;numeric-comparator
• RFC 3598 - SIEVE Email Filtering -- Subaddress Extension

Generic RFCs

• RFC 2822 - Internet message format
• RFC 2045 - MIME Part One: Format of Internet Message Bodies
• RFC 2046 - MIME Part Two: Media Types
• RFC 2047 - MIME Part Three: Message Header Extensions for Non-ASCII Text

Mailing Lists

• RFC 2919 - List-Id: A Structured Field and Namespace for the Identification of Mailing Lists
• RFC 2369 - The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header * Fields

FTP

• RFC 959 - FILE TRANSFER PROTOCOL (FTP)

Groupware

• RFC 2445 - Internet Calendaring and Scheduling Core Object Specification (iCalendar)
• RFC 2446 - iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries
• RFC 2447 - iCalendar Message-Based Interoperability Protocol (iMIP)
• RFC 3283 - Guide to Internet Calendaring
• RFC 2426 - vCard MIME Directory Profile

SNMP

• RFC 1157 - A Simple Network Management Protocol (SNMP)
• RFC 3416 - Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
• RFC 1213 - Management Information Base for Network Management of TCP/IP-based internets: MIB-II
• RFC 3418 - Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)

Services Architecture

Axigen is an integrated service SMTP, IMAP, POP, secured SSL/TLS, WebMail and list server, integrating advanced technologies and messaging services.

Services and modules

The Axigen messaging solution is built on an Internet-based mail server that provides messaging services over the Internet via connections using a Transmission Control Protocol/Internet Protocol (TCP/IP) network. Axigen sends mail messages using the Simple Mail Transfer Protocol (SMTP). The messages can be retrieved using the Post Office Protocol version 3 (POP3), the Internet Message Access Protocol (IMAP), WebMail or using your mobile device to access the Mobile WebMail, a lite version of the WebMail interface or using ActiveSync technology to keep your messages, tasks and contacts synchronized with ActiveSync clients. Axigen Mail Storage integrates a proprietary technology that allows storing messages in a special directory structure, guaranteeing an effective, fast mail flow and optimizing space-saving.

Architecture Features

Axigen incorporates a multi-threaded engine, which can break server activity into multiple parallel processing threads. This enables you to allocate a certain number of processing threads to specific modules (SMTP incoming / SMTP outgoing / WebMail / IMAP etc.) Running services can be configured at service, domain and account level.

Most Axigen services (SMTP Incoming, SMTP Outgoing, POP, IMAP, WebMail) make use of configurable listeners to define rules for accepting or denying connections.

Administration Tools

The administration tools enable both centralized configuration (WebAdmin and Command Line Interface) and manual configuration (configuration file).

For each service described in the Architecture chapter, configuration options are available in each of these tools (WebAdmin, CLI and the configuration file, axigen.cfg).

Security

Axigen incorporates an advanced filtering system and other innovative security tools (AntiVirus, AntiSpam, AntiSpoofing - SPF Authentication, SSL/TLS authentication etc.).

Highly configurable logging and reporting services are also available, and a Backup service allowing you to securely backup and restore your domain and user configuration.

Below you can find a schema illustrating all of Axigen's components.

Engine

Axigen uses MPA (MultiPlatform Architecture), a proprietary cutting-edge technology that allows porting the Axigen server on multiple platforms, Linux-based, BSD-based, Solaris and Windows platforms, while keeping the same set of features. This makes it possible to adapting the product to any demanded platform, while guaranteeing stability, and makes it easier for users to switch to a different platform, whenever their requirements change.

Axigen uses a supervisor process to monitor the child process. A supervisor is responsible for starting, stopping and monitoring its child processes. The basic idea of a supervisor is that it should keep its child processes alive by restarting them when necessary. Which child processes to start and monitor is specified by a list of child specifications. The child processes are started in the order specified by this list, and terminated in the reversed order.

Modularity

Axigen is a modular server running either as integrated service server or with certain services inhibited.

When using Axigen as main mail server, it is recommended to run all services provided by Axigen - Processing, SMTP Incoming, SMTP Outgoing, POP3, IMAP, WebMail, WebAdmin, CLI, Log, Report, FTP Backup - in order to take full benefit of functionalities offered by the server. By default, when installing mail services the following services will be running: SMTP, IMAP, POP3, WebMail and WebAdmin. SMTP stands for all Axigen SMTP services: SMTP Incoming, SMTP Outgoing and Processing.

Each Axigen service can be started / stopped / restarted separately providing you a flexible way to troubleshoot or to perform administrative tasks without completely stopping the server.

Services vs. modules

Services in Axigen refer to those components that clients can access, request and use information. Clients connect to service using an IP:PORT combination.

On the other hand, modules refer to those Axigen components that also provide services for the clients. However, these components are not accessed using an IP:PORT combination.

Take for example the SMTP module which includes the SMTP Receiving and SMTP Sending services. The SMTP Receiving service can be accessed using an IP:PORT combination so that clients can connect to this service and interact with it, while the SMTP Sending service is responsible for sending messages, meaning that Axigen will become the one connecting to another mail server using an IP:PORT combination.

Listeners & rules

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:

1. The IP address from which the connection has been initiated is exposed.
2. 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.
3. 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.
4. If the IP address from which the connection has been initiated is associated only with a deny rule, the connection is denied (closed).
5. 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.
6. 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

Admin delegation

Starting with version 5.0, Axigen features Delegated Administration options, which enable the easy creation of administrative groups, with predetermined membership hierarchies and permissions, assigned to specific domains. The WebAdmin Administration Rights section gives access to parameters configuring the behavior of such administrative users or imposing the limitations for each type of administrative user created.

• Server level permissions

Delegated administrators access level can be controlled by setting specific server-level permissions like: manage server configuration, manage services, manage backup, manage reporting, manage delegated administration etc.

• Domain / subdomain level permissions

Domain administrators may have full permissions for a domain or a limited set, such as: manage accounts, manage groups, manage public folders or manage filters. The same permissions may be granted on a sub-domain level.

• Domain / subdomain level restrictions

These restrictions limit the maximum number of users, maximum quota per user, etc. that a domain administrator may use for a specific domain. The same restrictions may be enforced on a sub-domain level.

• Subdomain administration

All the permissions and limitations set on domain level are automatically used when creating sub-domains that can further be administered as standalone domains. You can enforce the maximum number of sub-domains that a domain administrator is allowed to create.

• Delegated backup

Delegated administrators may download backups of their domains.

Account classes

In Axigen, settings are spread within three levels of depth:

• "Server Level" - is the most general of them all. Settings applied at this level propagate throughout the whole system. It is very useful to make changes here that need to apply on all domains. Some service settings are unavailable at this level, such as RPOP configuration.
• "Domain Level" - is the middle ground. The settings configured here override the settings applied on the server level. However, any changes here, affect only the contents of the particular domain being set up (such as existing and future accounts).
• "Account Level" - is the most localized of all three levels. The account level settings override any other settings. There are some settings that cannot be edited at this level, such as the message appender or socket filter configuration.

By default, all new users inherit the domain account defaults settings. However, you can impose specific limitations for users by creating account classes. Instead of inheriting the settings from the domain account defaults the users could inherit settings from the account class.

Groupware

The Axigen messaging solution implements groupware services allowing network users to interact and work together by sharing folders, emails, calendars, tasks etc. Complex permission hierarchies can be created to meet the specific collaboration and sharing needs of any organization.

Personal Organizer and Axigen Outlook Connector

Having time management and mobility needs in mind, a Personal Organizer module is available. This comprises tools such as calendar, tasks, journal, notes and collaborative support.

Aiming to adapt to all requirements generated by a competitive business environment, the permission granting structure enables users to delegate email sending tasks to their team members and view the free / busy status to avoid assigning events when a team member is already taking part in a different one.

The Axigen Outlook Connector enhances the communication of Microsoft's email client with the Axigen server, thus making the Personal Organizer available for Outlook users to take full advantage of all Axigen's features and capabilities.

Axigen Outlook Connector implements most Exchange-like features including server-side Search Folders (such as Unread messages or Large Messages) which enables users to easily locate messages based on various filters. The new application also allows new folders (including special folders) creation on the server directly from Outlook.

Users are allowed to perform operations on folders (view its contents, add items, delete items etc.) if permissions on the respective folder were defined. By default all users have permissions on their own folders and can allow other users to access one or more of their personal folders with different permission levels (read only, read and write etc.). These permissions can be set either from WebMail or Outlook and can be granted to a user or a group of users.

Computing permissions

Each time the server needs to determine if a specific action on a specific resource is allowed or denied for a specific administrative user, the following reasoning is used:

• if the permission is set to deny on at least one of the parent folders in the chain, for the user or a group that the user belongs to, the permission will be denied;
• if the permission is not denied on any of parent folders in the chain but allowed on at least one, for the user and/or a group that the user belongs to, the permission will be allowed;
• if the permission is neutral (not set) on all parent folders in the chain, for the user and/or a group that the user belongs to, the permission will be denied.

Permissions description

• Read items - Folder is visible and its contained items can be read;
• View items - Folder appears in hierarchy ("lookup");
• Read folder content - Items in this folder may be read;
• Share the read / unread status - Changes to the read / unread flag are seen by other users (does not apply for contacts, calendar, tasks, journal and notes folders);
• Set / clear flags - Modify flags other than read / unread and deleted / not deleted (does not apply for contacts, calendar, tasks, journal and notes folders);
• Add items - Add new items to folder (create new, move to, copy to). Both "add items" and "delete items" permissions are required for modifying items;
• Add sub-folders - Add new sub-folders below this folder (create new, move to, copy to);
• Delete folder - Delete this folder, including all its contained items;
• Delete items - Delete items in this folder. Both "add items" and "delete items" permissions are required for modifying items;
• Mark items as deleted / not deleted - Modify the deleted / not deleted flag;
• Expunge folder - Purge items marked with the deleted flag;
• Manage permissions - Modify permissions on this folder.

Types of permissions

When new entities are created they can have two types of permissions:

1. Implicit permissions do not appear in the permissions list for resources, cannot be modified (they are resolved directly by the MACL engine) and cannot be overridden with an explicit "DENY" from any level (above or below). These are:
   • the "postmaster" user has "all rights" on all public folders;
   • the "postmaster" user has "Lookup" and "Manage permissions" on all folders of all the accounts in its domain;
   • the "postmaster" user has "all rights" on his mailbox (and all sub-folders);
   • each user has "all rights" on his/her mailbox (and all sub-folders).
2. Default permissions are explicit, modifiable and appear when specific entities are created. They are:
   • newly created folder in the PF namespace or in a mailbox other than the creator's, the creator has "all rights", with "apply to sub-folders";
   • if the newly created public folder is created from the WebAdmin interface, no explicit permissions are set for it;
   • when a new domain is created, the PF root contains the permissions: "all users in domain", "allow", "Lookup", "apply to sub-folders".

Collaboration

Having time management and mobility needs in mind a Personal Organizer module is available from both Axigen’s WebMail interface and the email client Outlook. The Personal Organizer comprises tools such as calendar, tasks, journal, notes and collaborative support.

Aiming to adapt to all requirements generated by a competitive business environment, this permission granting structure enables users to delegate email sending tasks to their team members and view the availability (free / busy) status to avoid assigning events when a team member is already taking part in a different one.

The Axigen Outlook Connector enhances the communication of Microsoft's email client with the Axigen server, thus making the Personal Organizer available for Outlook users to take full advantage of all Axigen's features and capabilities.

Axigen Outlook Connector implements most Exchange-like features including server-side Search Folders (such as Unread messages or Large Messages) which enables users to easily locate messages based on various filters. The new application also allows new folders (including special folders) creation on the server directly from Outlook.

The iCalendar compatibility and support built into the Axigen mail server product aims to provide data (contact, meeting, task etc.) and option setting synchronization between the email service and an external email client accessing the stored information across the network. These features facilitate the administration and maintenance of the user mailbox, as well as provide access to calendaring features for users of email clients that support the ICS standard.

The Calendar helps users plan and schedule their work-related or personal events and to have a clear and detailed view of their work, thus enabling an improved time management.

Tasks helps users organize their work-related tasks and collaborate with others on ongoing projects. By enabling them to permanently check the level of completion, tasks offer a clear and detailed view of their workload.

When creating calendar events attendees can be invited. Additionally the availability (free / busy) status of the attendees is displayed IF the user editing the event has the 'Read Free/Busy status' permission on the attendee's mailbox.

The Journal allows you to add entries that help you keep track of your day-to-day tasks and actions.

The Note tool allows you to add quick notes while working. Notes are best suited when one needs to write down something very quickly and has little time to add more details.

Clustered operations

The Axigen Mail Server provides Clustering Support starting with version 3.0. Clustering support is based on OpenLDAP integration with Axigen and allows routing for the SMTP Incoming, POP3 Proxy, IMAP Proxy and WebMail Proxy services. This new feature enables you to spread mailboxes on several Axigen back-end servers and have a separate tier containing multiple front-ends that route POP3/IMAP/WebMail connections to the appropriate back-end server.

Another important feature of the OpenLDAP integration with the Axigen mail server is the LDAP Authentication mechanism. This method is available for all the Axigen services that require authentication: SMTP In, POP3, IMAP, WebMail, POP3 Proxy and IMAP Proxy.

For a detailed example on how to setup a high availability distributed solution see this related article: "Implementing, Deploying and Managing a High Availability Distributed Solution on Axigen Mail Server" available here.

Also starting with 7.0 Axigen implements LDAP synchronization. Accounts and groups in a domain can be synchronized with associated LDAP entries. Synchronization is supported for OpenLDAP and ActiveDirectory servers through their LDAP-based synchronization protocol using LDAP cookies (RFC 4533). The synchronization can be done in the following ways:

• from AXIGEN to LDAP: changes on a AXIGEN object (account/group) are propagated upon the associated LDAP entry;
• from LDAP to AXIGEN: changes on a LDAP entry are propagated upon a corresponding AXIGEN object (account/group);
• both ways: changes in one part (LDAP or AXIGEN) are propagated upon the corresponding object in the other part.

Proprietary storage

Axigen Storage is a specific file structure with index based access allowing fast mail delivery, retrieve and query.

Axigen Mail Storage checks the consistency of the messages placed in the storage and empties the queue only if the mail message is correctly stored.

All domain and user configuration along with user messages are stored in Axigen specific storage.

Each Axigen storage is defined by three elements:

• Storage directory: the directory where all storage file will be created;
• Max. file size: maximum size of a data file (Storage Container). The default value is 256 MB;
• Max. files: maximum number of files. The default value is 128 files.

Therefore the maximum capacity of each storage is Max. file size * Max. files and the default capacity is 32 GB.

Inside the storage directory, a list of files, named with 2 hexa digits followed by the .hsf extension - e.g. 2A.hsf - are created. There is also a file named hsf.dat which contains an unique id of the storage and the relation with other storages of the same domain. This information is useful in case some of the storage directories are moved to other locations.

Another feature of Axigen storage is that it supports transactions, so that some critical operations of domain configuration changes are made safely.

Filling the containers

When a storage container approaches its maximum size, (defined by the "Max. file size" parameter), another storage container will be created and the new messages will be stored herein. If the number of storage containers reaches the maximum value (defined by the "Max. files" parameter) and all of them have reached the maximum size, the storage is considered full and no more messages will be inserted.

The data in the storage containers is written in blocks of 4KB, therefore usually the files size is a multiple of 4KB. These memory blocks are called nodes. Smaller blocks of memory are also available, for message parts smaller than 4KB. These smaller blocks are called formatted nodes.

Each storage file can contain a maximum of 16 millions messages, and the maximum theoretical file size is 64GB (some limitations might apply, depending on your system configuration; currently Axigen limits this maximum size to 2GB). There can be maximum 128 files in one storage, and one domain can have over 4 billion message storages defined.

The actual maximum capacity in terms of total message count and size depends on the specific messages in the storage.

For each domain, at least three storages are used:

• one storage for domain configuration, where all domain specific configuration, the public folder and the list of domain objects (users, maillist, forwarders, etc) are stored;
• one storage for domain objects configuration, where all domain objects configurations and folders are stored;
• one or more storages for messages, where all mails and other data associated with mails are stored; it is recommended to define each message storage on a different physical disk, since Axigen will use these storages in parallel.

Space saving filling procedure

The storage files with more free space have a priority when it comes to selecting the files in which a new message is added. The usage of the free space is also enhanced by message deletion.

Each message in a storage file is identified by a pointerID (type UINT). The information related to these pointers-to-messages is stored in the same storage file.

• Indexed data structure

This ensures an optimal balance between the space used for storing indexes and the time to access information by introducing multiple levels of indexes depending on how often information is accessed.

• Transactional access

Axigen provides structural integrity for the stored information by performing transactional data access.

• Expandable storage

You can add subsequent storage units to one domain, thus increasing the available space.

• Single storage of emails with multiple recipients

Only one copy of a message received by multiple recipients is stored (particularly useful for distribution lists and groups).

• Repairing corrupted accounts

If an account’s data becomes corrupted (due to, for instance, disk failure), Axigen allows you to attempt account data recovery.

• Storage overload prevention

Overload prevention is ensured by limiting allowed message sizes according to specific policies based on multiple message or connection parameters.

Email flow

Bellow is an example on an incoming message taken from the Axigen log. The Axigen log is set to log "Protocol Communication" level, for the SMTP Receiving and Processing services, in order to obtain more details.

The first line shows that a connection was established to Axigen:

SMTP-IN:00000022: [127.0.0.1:25] connection accepted from [192.168.0.5:58047]

This line indicates that Axigen is ready to begin the SMTP communication:

SMTP-IN:00000022: >> 220 ts3.gecadco.local Axigen ESMTP ready

The next lines show the SMTP communication between Axigen and the remote host:

SMTP-IN:00000022: << EHLO  host.example.com
SMTP-IN:00000022: Greylist disabled
SMTP-IN:00000022: >> 250-ts3.gecadco.local Axigen ESMTP hello
SMTP-IN:00000022: >> 250-SIZE 10485760
SMTP-IN:00000022: >> 250-HELP
SMTP-IN:00000022: >> 250 OK

Here is where the sender of the message from the envelope is given by the remote host:

SMTP-IN:00000022: << MAIL FROM: remote_user@example.com

The next lines indicate that a certain action was performed after the "MAIL FROM" command. This action is actually a SMTP policy defined in the smtpFilters.script file:

SMTP-IN:00000022: Set smtp action to ACCEPT
SMTP-IN:00000022: Set smtp explanation to [Emails accepted from domain example.com
SMTP-IN:00000022: >> 250 Emails accepted from domain example.com

The recipient of the message is then provided and then the actual message which includes the headers and the body:

SMTP-IN:00000022: << RCPT TO: test@domain.tld
SMTP-IN:00000022: >> 250 Recipient accepted
SMTP-IN:00000022: << data
SMTP-IN:00000022: >> 354 Ready to receive data; remember <CRLF>.<CRLF>
SMTP-IN:00000022: << 3 bytes and final dot read

After the remote host indicates that the message is complete Axigen takes the message and enqueues it with an ID which is further used in the PROCESSING service. As you could notice the SMTP-IN service has a unique ID also for this message:

SMTP-IN:00000022: New mail received from host.example.com (192.168.0.5) and enqueued with id 20D2FB
SMTP-IN:00000022: >> 250 Mail queued for delivery

The PROCESSING Service now starts and begins to filter the message:

PROCESSING:0020D2FB: Shepherd thread received signal for processing
PROCESSING:0020D2FB: Start processing mail

SpamAssassinBundled is enabled and identifies this message as not being spam:

PROCESSING:0020D2FB: Start filter AV:SpamAssassinBundled of type socket filter from server
PROCESSING:0020D2FB: Shepherd thread finished processing signal
PROCESSING:0020D2FB: >> CHECK SPAMC/1.2
PROCESSING:0020D2FB: >> Content-length:
PROCESSING:0020D2FB: >> 133
PROCESSING:0020D2FB: >>
PROCESSING:0020D2FB: >> Send mail stream: 20D2FB
PROCESSING:0020D2FB: << SPAMD/1.1 0 EX_OK
PROCESSING:0020D2FB: << Spam: False ; 4.9 / 5.0
PROCESSING:0020D2FB: Filter SpamAssassin Filter(127.0.0.1:1987):[PASS]: Spam: False ; 4.9 / 5.0
PROCESSING:0020D2FB: Finished filtering mail object 20D2FB with filter: AV:SpamAssassinBundled of type socket filter from server

Now the rules defined on the server level are applied:

PROCESSING:0020D2FB: Start filter WASieveServer of type script filter from server
PROCESSING:0020D2FB: Finished filtering mail object 20D2FB with filter: WASieveServer of type script filter from server

And finally the delivery of the message occurs:

PROCESSING:0020D2FB: Finish processing mail
PROCESSING:0020D2FB: Shepherd thread received signal for delivery
PROCESSING:0020D2FB: Shepherd thread finished processing signal
PROCESSING:0020D2FB: Start mail delivery
PROCESSING:0020D2FB: Mail delivered to mailbox 'INBOX' of <test@domain.tld> with id 2
PROCESSING:0020D2FB: Shepherd thread received signal for cleanup
PROCESSING:0020D2FB: Start mail cleanup
PROCESSING:0020D2FB: Mail removed from queue
PROCESSING:0020D2FB: Shepherd thread finished processing signal

Essentially to remember when investigating an issue related to mail delivery is that you need "Protocol Communication" logs in order to obtain more details. Then you can track a message path, from the time it enters Axigen to the moment when it's delivery is made, using the IDs corresponding to that message. As you can notice in the example above the message is received with an ID "000022" and then enqueued with the ID "20D2FB" which is also used when the PROCESSING service logs it's messages.

Filtering priorities

If filters are defined at the server, domain and user levels they are applied in this order and if the messages matches more than one rule the last action is applied.

For example, in a scenario where a rule was defined at the server level, one at the domain level and one at the user level in the Axigen log file you will find the following lines:

Start processing the message

PROCESSING:0029C82A: Start processing mail

First the message is filtered by the rules defined at the server level:

PROCESSING:0029C82A: Start filter WASieveServer of type script filter from server                                     
PROCESSING:0029C82A: Shepherd thread finished processing signal                                                       
PROCESSING:0029C82A: Finished filtering mail object 29C82A with filter: WASieveServer of type script filter from server

Next by the rules defined at the domain level

PROCESSING:0029C82A: Start filter WASieveDomain of type script filter from domain <domain.tld>                        
PROCESSING:0029C82A: Finished filtering mail object 29C82A with filter: WASieveDomain of type script filter from domain <domain.tld>

Finally by the rules defined at the account level, in this case the account is postmaster@domain.tld:

PROCESSING:0029C82A: Start filter wmFilter of type script filter from domain object <postmaster@domain.tld>                     
PROCESSING:0029C82A: Finished filtering mail object 29C82A with filter: wmFilter of type script filter from domain object <postmaster@domain.tld>                                                                                                             

The filtering process ends.

PROCESSING:0029C82A: Finish processing mail

If, for example, after filtering the message with the server level filters the message is going to be delivered to "Spam" folder and then the message matches the conditions set for the account level filters and the action for the account level filters is to deliver the message to "Trash", then the message will be delivered to "Trash" folder.

Queue management

Axigen Mail Storage uses a proprietary technology which optimizes space and mail flow. This innovative storage architecture, doubled by a similar queue architecture, with index based access reduces I/O operations and disk access. Messages are stored in container files, a proprietary format that supports an effective space-saving filling procedure, allowing you to specify the locations and number of directories/files allowed for message storage.

The messages received from SMTP clients are stored in a queue that is processed by Axigen according to specific rules. Different operations can be executed on this queue, such as inspecting the queue, specifying/modifying the path where the queue is stored, setting the maximum number of queue subdirectories, processing size (number of messages) and number of local delivery threads for local SMTP transactions.

Using the "mqview" tool to view statuses for messages in the queue

The Axigen queue contains for each message stored in the queue, besides the message itself, a file with a status report for the message. You can view the status report for the files currently in the Axigen queue using the "mqview" tool:

/var/opt/axigen/queue/0F/S12BE (Linux/Solaris)
/var/axigen/queue/0F/S12BE (*BSD)

Solution 1:

cd /var/opt/axigen/queue/0F
/opt/axigen/bin/mqview @ S12BE

Solution 2:

/opt/axigen/bin/mqview /var/opt/axigen/queue 0F12BE

Each of these commands displays an output similar to the one below:

johnd /var/opt/axigen/queue/00 # mqview @ S5F4E

Mail Queue view of file : ../00/S5F4E

ID : 005F4E
State : RECEIVED
Flags : 00
Last Data Version : 00
Number of RCPTs : 1
Next Send Schedule : As Soon As Possible
Retry Count : 0
Reverse Path : root@localdomain
Authenticated Path : root@localdomain
RCPT information for: johnd@localdomain
State : RECEIVED
Data Version : 00
Filter Info : 
Destination mbox: INBOX
Failure Info : 
Local Delivery : 

Another example of the "mqview" tool is available here.

Services

The next sections will provide an overall view of the Axigen services.

SMTP Receiving

The SMTP Receiving module in Axigen establishes the dialogue with other entities via SMTP / ESMTP protocols, receives the mail message (if all conditions set by you are fulfilled) and forwards the mail message to the Processing module.

SMTP Incoming overview

This module protects the mail server against attacks and ensures a good functionality (adjusted to the processing power of the hardware, the bandwidth, and other factors) due to functions as configurable listeners, thread and client management, user authentication and a built-in SPF authentication procedure.

In Axigen, at SMTP Receiving level, specific anti-spam tests can be performed, thus ensuring basic email sorting before reaching the queue. The SMTP Receiving module accepts connections as specified by SMTP listeners defined in the configuration file, receives the message and performs the enabled anti-spam tests (e.g. SPF, MX, reverse DNS checks) at the appropriate SMTP event.

Listeners

Listeners can be defined and managed to add extra flexibility and configurability to this service. For that, global access limitations, SSL Settings and access lists can be enforced on the address used by this service for binding.

Access control

Access rules allow you to control connection to this service by defining simple access lists for specific Networks / IP Ranges / IP’s. Service level access rules are automatically applied to all its listeners and will override for this service any existing Global Access rules.

Authentication

Authentication is a method for preventing non-desirable actions by granting access to Axigen server's SMTP Receiving features to authenticated users only.

SMTP-Receiving Authentication parameters allow you to specify the authentication methods to be used for secured or unsecured connections. The available types are: Normal login, Plain, Login, CramMD5, DigestMD5 and GSSAPI.

For information on how to configure authentication parameters for SMTP-Receiving using the SMTP filtering system, consult our related knowledgebase article.

Message acceptance rules

At SMTP-connection level message acceptance rules can be configured and implemented to best suit security requirements. Incoming connections established via SMTP and the message flow can be easily managed, using already established policies, to help save space and resources for email processing.

Flow control

Flow control parameters can be adjusted to fine tune the server’s performance and avoid overloading it. Global access limitations to this listener can be enforced by setting the total number of simultaneous connections, concurrent connections from each remote IP address, number of new connections to the listener made in a time period interval, number of total connections from each remote IP address on a time interval period. The default interval for this time period is set to 1 minute.

Milter

As an additional security enhancement, the SMTP Policy system can call external milter type filters. More information on functions defined for using external Milter filters are available in the AntiSpam and AntiVirus sections.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Email loop protection

To prevent looping emails from increasing your mail server's traffic set a number of maximum received headers for received emails.

Error control

To protect the server, the number of failed/wrong commands received from SMTP clients during one session can be limited. When these limits are exceeded, incomplete connections or connections that are not RFC compliant will be dropped thus freeing important bandwidth.

Thread management

The Axigen mail server is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

IMAP

The Axigen IMAP module establishes connection with IMAP clients and retrieves mail messages from the storage unit. The server accepts connections as specified by the IMAP listeners defined in the configuration file. By default the server accepts connections on 127.0.0.1:143 .

IMAP module overview

The IMAP module implements the extension QUOTA, as described by the RFC 2087 standard. IMAP clients implementing the QUOTA extension can display mailbox quota for a specific user account.

Listeners

Listeners can be defined and managed to add extra flexibility and configurability to this service. For that, global access limitations, SSL Settings and access lists can be enforced on the address used by this service for binding.

Access control

Access rules allow you to control connection to this service by defining simple access lists for specific Networks / IP Ranges / IP’s. Service level access rules are automatically applied to all its listeners and will override for this service any existing Global Access rules.

Flow control

Flow control parameters can be adjusted to fine tune the server’s performance and avoid overloading it. Global access limitations to this listener can be enforced by setting the total number of simultaneous connections, concurrent connections from each remote IP address, number of new connections to the listener made in a time period interval, number of total connections from each remote IP address on a time interval period. The default interval for this time period is set to 1 minute.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Encryption and authentication

Various authentication types can be used in Axigen for IMAP secured (SSL/TLS) / unsecured connections. Possible options are: normal login, plain, login, cram-md5, digest-md5 and gssapi.

Error control

To protect the server, the number of failed/wrong commands received from IMAP clients during one session can be limited. When these limits are exceeded, incomplete connections or connections that are not RFC compliant will be dropped thus freeing important bandwidth.

Thread management

The Axigen mail server is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

Compatibility with various IMAP mail clients

Axigen has been thoroughly tested and it is proven to work with Mozilla, Outlook, Outlook Express, Thunderbird, The BAT!, Eudora.

Public folders

Users may share email messages by simply copying and/or moving them to a public folder. You can also associate a certain email address with a public folder. Thus, emails can be sent directly to the public folder.

Internationalized search

When running an IMAP search for any IMAP client, the search text may contain language-specific characters (i.e. using diacritics).

POP3

Axigen POP3 module establishes connection with POP3 clients and retrieves mail messages from the storage unit. The server accepts connections as specified by the POP3 listeners defined in the configuration file. By default the server accepts connections on 127.0.0.1:110 .

POP3 module overview

In Axigen the POP3 module works as follows:

• shows only the messages that existed in the mailbox when the mailbox was opened;
• keeps zombie copies for the messages deleted during the current session; the module shows them as zero size messages, and the module reports an error when a client application tries to retrieve a deleted message;
• messages are retrieved using the RETR command and the message is marked with the "Seen" flag (you can view this flag when using an IMAP or WebMail client).

Listeners

Listeners can be defined and managed to add extra flexibility and configurability to this service. For that, global access limitations, SSL Settings and access lists can be enforced on the address used by this service for binding.

Access control

Access rules allow you to control connection to this service by defining simple access lists for specific Networks / IP Ranges / IP’s. Service level access rules are automatically applied to all its listeners and will override for this service any existing Global Access rules.

Flow control

Flow control parameters can be adjusted to fine tune the server’s performance and avoid overloading it. Global access limitations to this listener can be enforced by setting the total number of simultaneous connections, concurrent connections from each remote IP address, number of new connections to the listener made in a time period interval, number of total connections from each remote IP address on a time interval period. The default interval for this time period is set to 1 minute.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Encryption and authentication

Various authentication types can be used in Axigen for IMAP secured (SSL/TLS) or unsecured connections. Possible options are: normal login, plain, login, CramMD5, DigestMD5 and GSSAPI.

Error control

To protect the server, the number of failed/wrong commands received from POP3 clients during one session can be limited. When these limits are exceeded, incomplete connections or connections that are not RFC compliant will be dropped thus freeing important bandwidth.

Thread management

The Axigen mail server is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

Compatibility with various POP3 mail clients

Axigen has been thoroughly tested and it is proven to work with Mozilla, Outlook, Outlook Express, Thunderbird, The BAT!, Eudora.

WebMail

The Axigen WebMail establishes connection with the mail server via Web browsers, sends and retrieves mail messages to and from the storage unit.

The Axigen WebMail works with major web browsers such as Internet Explorer and Mozilla. With this module the users can securely access their mailboxes from Internet browsers, while you are in complete control of the content, functionality and look of the web pages.

WebMail module overview

Listeners

Listeners can be defined and managed to add extra flexibility and configurability to this service. For that, global access limitations, SSL Settings and access lists can be enforced on the address used by this service for binding.

Access control

Access rules allow you to control connection to this service by defining simple access lists for specific Networks / IP Ranges / IP’s. Service level access rules are automatically applied to all its listeners and will override for this service any existing Global Access rules.

Flow control

Flow control parameters can be adjusted to fine tune the server’s performance and avoid overloading it. Global access limitations to this listener can be enforced by setting the total number of simultaneous connections, concurrent connections from each remote IP address, number of new connections to the listener made in a time period interval, number of total connections from each remote IP address on a time interval period. The default interval for this time period is set to 1 minute.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

HTTP protocol options

WebMail allows you to set HTTP limits for any request made to the WebMail service. This prevents you from automatically accepting excessive amounts of data (HTTP headers, HTTP body and upload data).

WebMail options

Administrators can choose to allow access only to a specific Webmail interface type (Ajax / Standard). You can also set the default interface type with which the users are presented when accessing the Webmail service.

The access to Calendars and Free / Busy information via iCal/HTTP can also be restricted.

To facilitate login procedures for multi-domain environments, Axigen implements login domain selection. Users can select the domain from a drop-down list and then login with their username and password only.

To better manage security and resource related issues persistent connections can be allowed/denied and time limits on active/idle sessions imposed.

Thread management

The Axigen mail server is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

Other Axigen WebMail features include:

• Complex customization - simple change of skin and behavior;
• Easy to use, secure and user-friendly – due to features like tree structure for folders view, common actions applied on folders (rename, delete, move, create), built in HTTP server etc.;
• Server Side Scripting Language - called HSP, used to generate HTML code;
• Personal Address Book - WebMail Contacts give users the possibility to select recipients from their personal contact list when composing new email messages. New addresses can be added to the existing address book either manually or automatically, when receiving new emails;
• Personal Organizer - comprises tools such as calendar, tasks, journal, notes and collaborative support. Through the Axigen Outlook Connector, the Personal Organizer is synchronized between Outlook and Axigen's WebMail;
• Public Address Book - contains contacts set at domain level, that are also available when composing an email;
• Automatic filters and replies – can be set trough WebMail interface wizards. Vacation / out-of-office messages can be defined and enabled to be sent automatically as a response to all received emails;
• Internationalized search and multiple languages support - language-specific characters can now be used when running a search;
• Public folders - users may now share email messages by simply copying and/or moving them to a public folder. You can also associate a certain email address with a public folder. Thus, emails can be sent directly to the public folder, archiving options being also available;
• WebMail Print Option - can be found in the main view of the WebMail interface and offers the option of quickly printing email messages;
• Compose while attach - using IFrame technology users can continue the Compose action while attaching files to their messages;
• URL redirect rules and virtual host support - URL redirect rules are used for redirecting plain connections established on one listener towards a secure domain:port location. Redirects can also be used to redirect connections from a specified listener to a virtual host. This way, several domain names can be defined for the same IP address and several domains can be hosted on a single IP. This is useful, for instance, when you wish to have two different WebMail login pages for two different local domains hosted at the same IP;
• HTML mail filtering levels - parses the HTML code from the emails and generates a safer (i.e. removes possibly unsafe scripts) and cleaner (i.e. converts to XHTML-like) HTML code. This provides WebMail account users with the ability to set the HTML filtering level to be applied to all mail in HTML format.

WebAdmin

WebAdmin overview

Axigen WebAdmin is the recommended administration tool for Axigen. While alternative methods are provided (Command Line Interface, text-editable configuration file), WebAdmin is the most intuitive and user-friendly tool. WebAdmin is a web-based configuration interface, tested for Mozilla and Internet Explorer, which gives you access to all configuration parameters for all services in the Axigen messaging solution. Functionally, it is considered an Axigen service, and it can be started and stopped at any time.

WebAdmin is enabled by default in the latest versions of Axigen, and can be accessed by default on the 127.0.0.1:9000 address.

Thread management

Axigen can run on a large variety of systems and machines, in networks with very different traffic loads, structures, domain configurations, user rights, authorization procedures, etc. Depending on your specific network specifications and conditions, you can adapt the workload to the server's processing power, in order to prevent a system overload or to improve server performance by setting different numbers of processing threads for the WebAdmin service, depending on your traffic load. First, you need to set a number of threads to be allotted when the WebAdmin service is started. To efficiently manage peak periods, a corresponding number of threads is allotted for overloads caused by high traffic.

Log control

Just like all the other Axigen main services, the WebAdmin module can log different types of events. You can specify what events are logged, where and how they are logged.

WebAdmin flow control

In WebAdmin, to efficiently manage the traffic flow, you can allow a maximum number of simultaneous connection, a maximum number of connection from a distinct remote IP, and further fine tune your options by limiting the number of total connections or connection from a certain IP in a given time frame.

HTTP protocol options for WebAdmin

WebAdmin allows you to set HTTP limits for any request made to the WebAdmin service. This prevents you from automatically accepting excessive amounts of data (HTTP headers, HTTP body and upload data).

Session options for WebAdmin

In WebAdmin, you can impose time limits on sessions, either active or idle. By doing this, you can better manage security and resource related issues.

CLI

The Command Line Interface (in short CLI) is an interface the configuration of the Axigen service and permits the automation of specific administrative tasks via custom tools. In order to do that, a CLI listener will be available on a specified address, thus the commands can be issued using common tools such as Telnet, Netcat, etc.

Service description

CLI is a TCP service for the Axigen messaging solution, just like SMTP, IMAP, POP3, etc. The CLI service can be configured in its turn similarly to the other services, either by editing the configuration files or by using the remote configuration tools like CLI and WebAdmin. It has common parameters such as maxErrors, logLevel, etc. and also a list of listeners for configuring incoming connections.

The connection to the service must be authenticated using an Axigen server administrator account. This can be the default "admin" account or a delegated admin user.

CLI is structured in contexts, each of them including a specific set of commands. CLI also uses a common set of commands. Each context provides commands allowing switching to the previous and next context and a HELP command to view the available commands at that specific location. When connected, the login context is activated and an username and password must be provided. After activation, the initial context becomes active. The initial context is the only one not having a name in the command prompt.

CLI is a TCP service with specified dedicated socket accessible using Telnet applications and Netcat. CLI provides added functionality such as, apart from providing an alternate method of performing basic configuration tasks, it allows automating administration tasks using scripts (adding users, migration).

Logging

Log service overview

Axigen offers an extremely flexible logging service, allowing you to select among different logging levels (how detailed the information logged should be), logging types (internal, external and system services are available) and where to store the information logged. You can set all these options for each Axigen TCP service and for the Log Service itself. The Log Service is responsible with collecting events relevant for the you. You can log (internally, remotely or using the system log) the activity of all services available in Axigen. The Axigen Log Service can log internal data coming from other Axigen modules / services or data coming from the UDP port 2000 (default option). This data can be logged in the same location or in different locations for separate services, depending on the configuration you have applied.

For the Axigen Log service, you can also specify the following information:

• on what address the Log listener should be listening (see the "Log Listener" section for more information);
• what hosts should be rejected by the Log service (using the listener "denyRules", a priority and an enable / disable switch);
• what hosts should be accepted by the Log service (using the listener "allowRules", a priority and an enable / disable switch).

Log types

Axigen's modules should define the log type using the "logtype" parameter, which can have any single values from the following three:

1. "internal",
2. "remote" or
3. "system" log.

• Use the "internal" option to send events to the Log Service running on the same Axigen server. The server should have the Log Service activated.
• Use the "remote" option to send events to a Log Service running in another Axigen server, remotely, at the address specified using the "hostname" attribute. This Axigen server must have the Log Service activated.
• Use the "system" option to send events to the syslog (for instance sysklogd) with facility "LOG_MAIL" and levels mapped as:
  • 0 - no message sent
  • 1 - LOG_CRIT
  • 2 - LOG_ERR
  • 4 - LOG_WARNING
  • 8 - LOG_INFO
  • 16 - LOG_DEBUG

Axigen log levels

In Axigen the events are organized in 6 categories and you can select which category of events to collect. Axigen modules must define the "loglevel" parameter. In order to specify the desired sets of events to log you have to specify the correspondent log levels or a combination of thereof. The log levels in the Axigen mail server are:

• 0: no messages are logged
• 1: log critical messages
• 2: log errors
• 4: log warnings
• 8: log informative messages
• 16: log protocol communication

and the corresponding one-time combinations. Therefore the accepted values for the "loglevel" parameter are from 0 to 31.

Example 1 - Combining log levels in the Axigen mail server:

If you set
loglevel=15 = 1+2+4+8
then the Axigen mail server will log the following information: critical errors and errors and warnings and information.

Example 2 - Disabling the log service for one Axigen service:

Remember the log service is configured separately for Axigen's main services (IMAP, POP3, SMTP Incoming), so if you set 
loglevel = 0
in the IMAP log service section, no data for that specific service will be logged by the Log Server for the Axigen IMAP service.
However, the Log server will continue logging other Axigen services according to the settings defined for logging the respective 
services.

Logging format

The format used for data logging is the following:

date hostname modulename:sessionId: user_message\n

The Axigen Log service then transforms this data in a format similar to the one described below:

date loglevel hostname modulename:sessionId: user_message\n
05-19 17:08:01 0300 08 johnd-l SMTP:00000005: connection accepted from [127.0.0.1]

Example - log service configuration using the axigen.cfg file:

loglevel = 01-31
hostname = 'yourcompany.com' (this is the result of the standard 'hostname' command)
modulename = 'SMTP' (other accepted values are: POP3, IMAP, WEBMAIL, RELAY, PROCESSING)
sessionId (this is an UINT value written in hexa incremented separately for each connection of a protocol. 
For the processing module, as there is no relevant protocol, the value is currently 0. 
Future versions will provide however as value the ID of the message in the working queue.

loglevel is a 5 bits mask for the following values:
LOG_none = 0x00,
/// critical
LOG_crit = 0x01,
/// errors
LOG_err = 0x02,
/// warnings
LOG_warn = 0x04,
/// information
LOG_info = 0x08,
/// log protocol communication
LOG_proto = 0x10,

Rules

Log Rules are used to define circumstances under which certain restrictions will be imposed on log files and the log level. Rules can be associated with host names, module names or both. For instance, a rule can be defined in order to specify the size, duration and number of old files kept for logs generated on a certain host, for a certain module (e.g. SMTP In).

An ordered list is created with all log rules configurations using the "priority" parameters as ordering key. You can define the Log rules at the Axigen main module's level, in the corresponding sections of the configuration file. The Log Service will check if the information sent by the modules is the information that is supposed to receive, according to the Log Service configuration.

A log rule set includes the following information:

• the rule's priority ("1" means the rule has the highest priority possible);
• the hostname of the user of this rule;
• the module of the user of this rule;
• the level of log generated by the user of this log;
• the name of the destination file;
• the maximum size of the destination file in KB;
• the maximum duration the destination file is used in seconds;
• the maximum number of old files (saved) to be kept;
• the rotate period (how often a new log file is created - daily, monthly, yearly).

Attributes of the Log service

The Axigen Log service can log internal data coming from other modules / services or data coming from the UDP port 2000 (default value). This data can be logged in the same location or in different locations for separate services, depending on the configuration applied by you. Axigen's main modules must define the log type to be used by that specific module. The definition is executed via the "logtype" parameter that can have any of the following three values: "internal", "remote" or "system" log.

The value for the "loglevel" parameter from the log clients (the services sending information for logging to Axigen Log service) specifies the log levels sent to the Log service.

The value for the "loglevel" parameter from the log service's rule specifies the log levels accepted by the service from clients.

Therefore if:

• clientlevel = 15 (the log level specified in the SMTP-In service page in WebAdmin for instance)

and

• rulelevel = 9 (the log level specified in the rule defined for the SMTP-In module)

the Log service will only log the lines on level 9 (critical information), even if the information retrieved from client also contains errors and warnings (this information is ignored).

Reporting

The reporting service helps you check server activity at global traffic and module level. The server jobs can be overseen by assigning the reporting service to collect data for parameters such as:

• Inbound WebMail connections
• IMAP append requests
• POP3 inbound connection
• Queue size
• SMTP outbound connections
• SYSTEM load average
• Messages rejected by built-in filters

and many others. The reporting service collects and reports information on 3 levels of administration: server, domain and account, that can be further customized to achieve comparison charts.

Data collection

All server parameters are automatically collected, with a 1 minute granularity, while the reporting service is running. You may enable or disable, on the reporting service level, collection of parameters for domain scope and account scope.

You may define, for each collector, the following boolean options:

• Collect per-domain data (default off);
• Collect per-account data (default off).

Additionally, you may also configure the maximum collection interval, in week increments. If new value is smaller, historic data older than the new value is automatically deleted. A warning is displayed prior to setting a smaller value and deleting old historic data.

Only an administrator that has the "Manage Reporting" on the site level has the permission to modify these service parameters.

Charts

You can create charts with the "Manage reporting" site-level permission and with the "Manage domain reporting" permission on a respective domain. However, if the "Manage reporting" site-level permission is not available, the chart can only display data for domains on which the administrator (that created the respective chart) has the "Manage domain reporting" permission on.

When creating a new chart, the following options are available:

• Chart name
• Chart group (the chart group in which the chart is created)
• Timeframe (date / hour start, date / hour end)
• Displayed data (one or more entries)
  • Parameter
    • Name (POP3 connections, SMTP messages, etc), if a collector (hence collected data) exists
    • Scope
      • Server
      • Domain
      • Domain Object
  • Aggregation Function
    • Average
    • Min
    • Max
    • Total
  • Chart type
  • Fill color
  • Outline color

The displayed chart has the following properties:

• Ox axis:
  • Scale: defined by user
  • Origin: start date and end date defined by user
  • Value: timestamp for each value according to chart width
• Oy axis:
  • Scale: selected automatically based on the highest value in the interval
  • Origin: 0
  • Value: the collected value associated with the timestamp on the Ox axis

Export

All chart data is exported in the requested format, in raw form (no downsampling), for the timeframe and all parameters of the respective chart. Data from one chart can be exported in XML or CSV form. The "Export" option may be selected from an already defined chart, also in XML or CSV form. Also a summary can be exported.

Backup and Restore

The backup and restore operations are based on a hierarchy of elements (nodes - directories and files). This hierarchy will allow you to perform backup and restore operations for one of the following specific elements in Axigen:

• Domain
• Public Folder
• Account
• Maillist (mailing list)
• Group
• Folder Recipient (object associated with a (Public) Folder for receiving mail through SMTP)
• Folder
• Message

FTP backup

The Axigen messaging solution provides a FTP backup / restore service meant to enable regular backup operations for your entire domain and user configuration. This service is based on FTP (File Transfer Protocol, standard RFC 959).

The FTP Backup service allows using any FTP client (including standard Web browsers) in order to connect to the backup machine using the admin username and password. You can replicate the entire domain and user (accounts, lists forwarders, folder recipients) folder structure on the backup machine. The FTP service generates a virtual structure, from which you can retrieve files whenever you need them.

Listeners

Listeners can be defined and managed to add extra flexibility and configurability to this service. For that, global access limitations, SSL Settings and access lists can be enforced on the address used by this service for binding.

Access control

Access rules allow you to control connection to this service by defining simple access lists for specific Networks / IP Ranges / IP’s. Service level access rules are automatically applied to all its listeners and will override for this service any existing Global Access rules.

Flow control

Flow control parameters can be adjusted to fine tune the server’s performance and avoid overloading it. Global access limitations to this listener can be enforced by setting the total number of simultaneous connections, concurrent connections from each remote IP address, number of new connections to the listener made in a time period interval, number of total connections from each remote IP address on a time interval period. The default interval for this time period is set to 1 minute.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Message Packaging

The "Use the TAR format to pack messages" option, when activated, it will enable the creation of a .tar package of all the messages in a specific account message folder, that in turn can be used when performing regular FTP backups to simplify and speed-up the backup operations, as you do not need to download all the separate message files in the user's folder, but only the .tar package.

NOTE: The messages.tar package will only contain the user emails of that folder (ex: Inbox). It will not contain the user configuration files, which need to be downloaded together with the messages.tar package for a complete account backup.

This improves the backup experience using the FTP backup by reducing the number of transfers and connections (and thus the communication overhead) on FTP, in case of large number of messages in a folder.

Error control

To protect the server, the number of failed / wrong commands received from FTP clients during one session can be limited. When these limits are exceeded, incomplete connections or connections that are not RFC compliant will be dropped thus freeing important bandwidth.

Thread management

The Axigen mail server is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

For more details about how to configure the FTP Service please consult the 3.2.9.1 FTP Back-up & Restore section.

File system access

Another method of performing Axigen backup is by using FUSE Virtual File System. File System Access allows back-up and restore processes through file system mounts. Tutorials on how to access the Axigen domain storage via FUSE can be found in our related articles:

• How to mount the Axigen storage in a virtual file system on a Linux platform;
• How to mount the Axigen storage in a virtual file system on a Windows platform.

This method consists of an even simpler backup procedure by copying the Axigen data to a backup location. You can use certain tools that are normally used for filesystem backups. these can now be used to backup the directory under which the Axigen domain storage or objects were mounted.

Also ONLY starting with the Axigen 7.6.0 version you can use our custom tools to backup your storage via FUSE to a specified local directory. These can be downloaded from: axi_backup_tools.zip

Unzip the archive and consult the README file from the extracted directory to learn how to use the scripts.

A full backup of the Axigen working directory is also possible, by directly copying the files, as described in the following article:

• How to back up Axigen without the FTP service.

Modules

The next sections will provide an overall view of the Axigen modules.

SMTP Sending

The SMTP Sending module is responsible for sending messages directly to message recipients. Axigen SMTP Sending uses DNR (Domain Name Resolver) for mapping domain names to IP addresses and includes complete rescheduling procedures.

SMTP Outgoing module overview

By default, Axigen is configured not to allow open relaying. This means that the server does not automatically dispatch mail that is neither for nor from a local user. By using client management, SMTP Sending blocks spammers' attempts to relay large quantities of mail.

Routing rules

Configuring Routing Rules allows you to customize SMTP Sending actions for all or a part of the transmitted email communication.

If Axigen fails to send messages to a specific domain because this domain was down for some time, when the domain is up again, the first message that goes successfully to that domain will also queue the rest of the pending messages from the queue and will force delivery of all messages.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Thread management

The Axigen messaging solution is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

Queue processing

The Processing module manages the mail messages, transmitted from the SMTP Incoming and WebMail modules, in the Axigen Queue and delivers them to Axigen Storage (for local delivery) and to the SMTP Sending module (for external delivery).

Processing module

The processing module interacts with:

1. the IMAP module - it uses the Axigen Processing module to Append operations executed on mailboxes;
2. the WebMail module - it uses the Axigen Processing module to Compose operations (after the message is composed, it is placed in the Axigen Queue);

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Email delivery

In case a message cannot be delivered for some non-critical reason, it can be re-scheduled, meaning Axigen will try to re-send it after a defined time interval is elapsed. Axigen's mail scheduling feature can be adjusted in terms of: first delivery retry timeout for an email, stop doubling retry timeout when it reaches and max. number of retries.

Delivery reports

Temporary and permanent delivery error reports can be configured to be sent automatically when reaching a number of failed delivery attempts. The message can be customized by setting a specific notification sender, subject, beginning and ending body, or appending variables. Also the headers or even the entire original message can be set to be attached to your notification.

Queue parameters

The messages received from SMTP clients are stored in a queue that is processed by Axigen according to specific rules. Different operations can be executed on this queue, such as inspecting the queue, specifying / modifying the path where the queue is stored, setting the maximum number of queue subdirectories, processing size (number of messages) and number of local delivery threads for local SMTP transactions.

Message statuses

A message in the queue can have one of the following statuses:

• Incoming: The message is currently being received. It has not been treated in either way by Axigen.
• Received: The email has been received. No action has been taken on it yet.
• Processing: Message processing is underway.
• Processed: The email processing ended, successfully or not. If the message is successfully processed, the next specific action (for instance delivery) specified for the message is carried out. If the email processing ends unsuccessfully, the message remains in Processed status.
• Sending: The process of sending the message is underway.
• Send Failure: The email sending failed.
• Sent: The message has been sent.
• Raw received: The email was received from the WebMail module.
• Relay error: The SMTP Sending module did not manage to send the message to the addressing server.
• Local error: The SMTP Sending module did not manage to send the email to the Axigen Storage.
• Filter reject: The message was rejected by a configured filter.
• Filter discard: The email was deleted by a filter without any notification.
• Cleanup error: The NDR message could not be send to the sender.
• New mail: The email has just arrived in the queue.
• Removed: The message was deleted.
• IO Error: The message could not be read from the disk.

DNR

Th Axigen messaging solution includes a Domain Name Resolver (DNR) module used to extract information from domain servers. The module implements the specifications from RFC1034 and RFC1035 and communicates with Domain Name Servers using UDP sockets on port 53.

Axigen services using DNR:

• The SMTP Receiving service uses DNR for performing the SPF tests (this action involves PTR and TXT queries).
• The SMTP Sending service queries DNR for MX and A information about the domain where to relay the mail messages.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

DNR options

In this section you can configure the time period after the first DNR query is closed, maximum number of DNR query retries to be executed and number of results (IP addresses) cached for each DNR query type to be executed.

Nameservers

When performing DNR searches, Axigen uses a list of known nameservers (specified in the OS configuration). In order to limit bandwidth and time consumed with DNS traffic, a list of known hosts can be defined. Different priority values can be assigned to nameserver IPs to set the order in which you wish to query nameservers (the servers with the higher priority are queried first).

Remote POP

The Axigen RPOP module establishes remote POP connections to already existing email accounts and retrieves all incoming traffic into the Axigen account.

Each Axigen account user can configure and add RPOP connections when connected to WebMail. In order to establish such a connection, the user must specify the hostname and the port for the existing email account, as well as the username and the password required to login. Users can choose the folder to which the retrieved emails will be directed, the time interval between subsequent retrievals and if the email is deleted from the remote account or not after being transferred. Encryption options are also available.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Thread management

The Axigen messaging solution is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power, in order to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

Mobility

Push Email & PIM Synchronization

Instant access to messages, contacts, calendar, or tasks regardless of time and location makes it easier for mobile workers to manage business operations, to stay in touch with customers and partners, and abreast of the latest changes and events on the market. It also ensures a better balance between professional and personal lives, enabling frequent travelers to keep in close contact with family and friends at all times. As a result, instant email retrieval has become more and more popular in both business and personal communication environments.

Smartphones and PDAs have also raised the bar in this sense and personal information management along with wireless (GPRS, 3G etc.) email access are visibly embraced by a fast-growing community of users. This is a known fact and the trend seems to pick up the pace with each month.

How It Works:

Email and PIM synchronization is the next best thing in email since the invention of the IMAP protocol. Through a technology, now known as “Push Email”, the tables have turned on email servers and clients. Normally, the client (desktop or mobile) would connect to the server and log in with the account credentials. Once the authentication is complete the client would poll the account by asking the server if any new messages are available. As opposed to this, Push email instructs the server to instantly notify the client when a new email arrives. The main difference between these two approaches consists in the fact that the server will always know when a new message exists, while the client does not and has to check for them in a timely fashion. Push email is also much more economic in terms of data transfer amount and bandwidth usage. Establishing a single connection and maintaining it in an idle state is a very relaxed way to help the server contact the client whenever required.

Almost the same thing happens when speaking about PIM database synchronization. Appointments, tasks, notes and all of the data stored as PIM information are translated into email objects formatted in a special way, so that the contents can later be interpreted appropriately. So both emails and PIM data rely on the same standard and look a lot alike, despite some major differences. What needs to be remembered is that from an email server’s perspective, the above mentioned objects are considered emails in the general meaning of the word.

Axigen's mobility services

At this time, quite a lot of PIM sync and email pushing technologies exist and they are all implemented differently, even though they perform the same task. By far, the most popular technology, used world-wide, is Microsoft’s ActiveSync protocol. Therefore, Axigen has chosen to first implement support for this specific technology in order to reach and provide this feature to the largest base of users possible. The series of mobile devices and handsets that support the ActiveSync protocol includes Nokia / SymbianOS devices, Windows Mobile (since 2003 up to latest version), Apple iPhone and other devices that can have compatible software installed.

While using the ActiveSync protocol, handsets and PDAs will be able to get instant email notifications and save personal and contact data to and from the email server in real time. The transfer is performed just like the regular desktop synchronization between mobile devices and the Microsoft Outlook email client through the ActiveSync desktop application. It is automatically triggered by the server when a new event occurs or by the client if the modification or update is performed on the handset.

The Push email technology can definitely help you work more effectively and get mission-critical information in real time, right when you need it. However, this is not the only approach that an Axigen user has to take in order to access email-related information using a mobile device. Axigen’s Mobile WebMail Interface (MWI) allows users to check their messages using the web browser on their handsets in a friendly and intuitive way. This service is mandatory if you plan on using the main account with ActiveSync, but still check your second email account via the MWI on demand. Also, the IMAP idle feature and regular IMAP/POP3 account polling are supported. So if you feel this is the best option, or should you like to test this old school method for checking your email on the handset, you can always give it a spin.

The list of the supported terminals is available here.

Mobile WebMail

The Axigen messaging solution uses an advanced mobile WebMail interface that supports all mobile web browsers compatible with the XHTML format for page rendering. The mobile WebMail is integrated into the same server module and therefore provides seamless access to information to all users just like the regular WebMail interface. When accessing the Axigen WebMail interface, the end-user Mobile Browser ID String (User Agent ID) is identified and the mobile WebMail is loaded and rendered automatically.

The Axigen mobile WebMail interface provides access to the following features:

• Basic email access (read, write, reply etc.)
• Advanced email access (move, delete, attachments etc.)
• Folder management
• Public folder access
• Advanced email search
• Sharing and permissions management

Moreover, the Mobile Browser ID String (User Agent ID) can be further added, therefore extending the integration capability of the Axigen mobile WebMail with newer terminals.

The mobile WebMail setup involves the activation of the WebMail service from the web administration interface (WebAdmin) for users intended to have access to it and enabling the mobile capabilities for this service by checking the corresponding option on the service setup page. Once this simple procedure is completed, any supported mobile terminal will have access to this feature.

IMAP/POP3 and SMTP access

The majority of modern mobile terminals have now built-in email clients that can be used to connect to the Axigen messaging solution using the same settings that apply on the MUA (Mail User Agent / Email client) on the desktop systems. The same credentials are used for these mobile accounts, and from the server’s perspective the same communication process takes place.

This method is very comfortable both from the user’s perspective and from the network / system administrator’s perspective. Because these email clients typically use standard protocols such as POP3, IMAP4 and SMTP, the configuration overhead is completely avoided. To allow users access to their mailbox content, no server-side configuration is required (given the desktop clients can access the mailboxes). The users need to configure the email clients according to specifications provided by the terminal manufacturer.

In most cases, email client software comes free of charge from terminal manufacturers, but may require a data plan from mobile operators.

On the server side, the Axigen messaging solution needs to have the following services activated and accessible from outside the LAN:

• The SMTP service for sending and receiving messages;
• The IMAP or the POP3 service(s) for reading messages.

In addition to this simple and convenient method to achieve email access on mobile terminals, the IMAP Idle feature can be used whenever the mobile terminal email client supports this feature. The IMAP Idle feature allows the client to poll the Inbox regularly for new messages without having to transfer large amounts of data (during the authentication process and folder refresh) each time.

This helps reduce the data transferred and the time needed for notification in case new message arrivals. The IMAP Idle feature is built into the Axigen IMAP service and is enabled at all times. If a client supports and requests an IDLE command, the Axigen server will correctly interpret it.

The client mobile terminal needs to have the following settings configured:

• Username, password;
• Email address and account type (IMAP/POP3);
• Incoming mail server address;
• Outgoing mail server address (SMTP).

This set-up is very similar to the procedure required on desktop email clients, but the parameters may be located differently for different devices.

Logging

Log service overview

Axigen offers an extremely flexible logging service, allowing you to select among different logging levels (how detailed the information logged should be), logging types (internal, external and system services are available) and where to store the information logged. You can set all these options for each Axigen TCP service and for the Log Service itself. The Log Service is responsible with collecting events relevant for the you. You can log (internally, remotely or using the system log) the activity of all services available in Axigen. The Axigen Log Service can log internal data coming from other Axigen modules / services or data coming from the UDP port 2000 (default option). This data can be logged in the same location or in different locations for separate services, depending on the configuration you have applied.

For the Axigen Log service, you can also specify the following information:

• on what address the Log listener should be listening (see the "Log Listener" section for more information);
• what hosts should be rejected by the Log service (using the listener "denyRules", a priority and an enable / disable switch);
• what hosts should be accepted by the Log service (using the listener "allowRules", a priority and an enable / disable switch).

Log types

Axigen's modules should define the log type using the "logtype" parameter, which can have any single values from the following three:

1. "internal",
2. "remote" or
3. "system" log.

• Use the "internal" option to send events to the Log Service running on the same Axigen server. The server should have the Log Service activated.
• Use the "remote" option to send events to a Log Service running in another Axigen server, remotely, at the address specified using the "hostname" attribute. This Axigen server must have the Log Service activated.
• Use the "system" option to send events to the syslog (for instance sysklogd) with facility "LOG_MAIL" and levels mapped as:
  • 0 - no message sent
  • 1 - LOG_CRIT
  • 2 - LOG_ERR
  • 4 - LOG_WARNING
  • 8 - LOG_INFO
  • 16 - LOG_DEBUG

Axigen log levels

In Axigen the events are organized in 6 categories and you can select which category of events to collect. Axigen modules must define the "loglevel" parameter. In order to specify the desired sets of events to log you have to specify the correspondent log levels or a combination of thereof. The log levels in the Axigen mail server are:

• 0: no messages are logged
• 1: log critical messages
• 2: log errors
• 4: log warnings
• 8: log informative messages
• 16: log protocol communication

and the corresponding one-time combinations. Therefore the accepted values for the "loglevel" parameter are from 0 to 31.

Example 1 - Combining log levels in the Axigen mail server:

If you set
loglevel=15 = 1+2+4+8
then the Axigen mail server will log the following information: critical errors and errors and warnings and information.

Example 2 - Disabling the log service for one Axigen service:

Remember the log service is configured separately for Axigen's main services (IMAP, POP3, SMTP Incoming), so if you set 
loglevel = 0
in the IMAP log service section, no data for that specific service will be logged by the Log Server for the Axigen IMAP service.
However, the Log server will continue logging other Axigen services according to the settings defined for logging the respective 
services.

Logging format

The format used for data logging is the following:

date hostname modulename:sessionId: user_message\n

The Axigen Log service then transforms this data in a format similar to the one described below:

date loglevel hostname modulename:sessionId: user_message\n
05-19 17:08:01 0300 08 johnd-l SMTP:00000005: connection accepted from [127.0.0.1]

Example - log service configuration using the axigen.cfg file:

loglevel = 01-31
hostname = 'yourcompany.com' (this is the result of the standard 'hostname' command)
modulename = 'SMTP' (other accepted values are: POP3, IMAP, WEBMAIL, RELAY, PROCESSING)
sessionId (this is an UINT value written in hexa incremented separately for each connection of a protocol. 
For the processing module, as there is no relevant protocol, the value is currently 0. 
Future versions will provide however as value the ID of the message in the working queue.

loglevel is a 5 bits mask for the following values:
LOG_none = 0x00,
/// critical
LOG_crit = 0x01,
/// errors
LOG_err = 0x02,
/// warnings
LOG_warn = 0x04,
/// information
LOG_info = 0x08,
/// log protocol communication
LOG_proto = 0x10,

Rules

Log Rules are used to define circumstances under which certain restrictions will be imposed on log files and the log level. Rules can be associated with host names, module names or both. For instance, a rule can be defined in order to specify the size, duration and number of old files kept for logs generated on a certain host, for a certain module (e.g. SMTP In).

An ordered list is created with all log rules configurations using the "priority" parameters as ordering key. You can define the Log rules at the Axigen main module's level, in the corresponding sections of the configuration file. The Log Service will check if the information sent by the modules is the information that is supposed to receive, according to the Log Service configuration.

A log rule set includes the following information:

• the rule's priority ("1" means the rule has the highest priority possible);
• the hostname of the user of this rule;
• the module of the user of this rule;
• the level of log generated by the user of this log;
• the name of the destination file;
• the maximum size of the destination file in KB;
• the maximum duration the destination file is used in seconds;
• the maximum number of old files (saved) to be kept;
• the rotate period (how often a new log file is created - daily, monthly, yearly).

Attributes of the Log service

The Axigen Log service can log internal data coming from other modules / services or data coming from the UDP port 2000 (default value). This data can be logged in the same location or in different locations for separate services, depending on the configuration applied by you. Axigen's main modules must define the log type to be used by that specific module. The definition is executed via the "logtype" parameter that can have any of the following three values: "internal", "remote" or "system" log.

The value for the "loglevel" parameter from the log clients (the services sending information for logging to Axigen Log service) specifies the log levels sent to the Log service.

The value for the "loglevel" parameter from the log service's rule specifies the log levels accepted by the service from clients.

Therefore if:

• clientlevel = 15 (the log level specified in the SMTP-In service page in WebAdmin for instance)

and

• rulelevel = 9 (the log level specified in the rule defined for the SMTP-In module)

the Log service will only log the lines on level 9 (critical information), even if the information retrieved from client also contains errors and warnings (this information is ignored).

Reporting

SNMP is a networking management protocol used to monitor network-attached devices. SNMP allows messages (called protocol data units) to be sent to various parts of a network. Upon receiving these messages, SNMP-compatible devices (called agents) return data specific to certain parameters that are monitored to the SNMP manager. Furthermore to supporting SNMP services, starting version 6.0, Axigen also supports SNMP Traps.

How chart information is collected & processed

Now we will detail how the Axigen mail server collects and processes chart data and how various settings can influence the display of the charts. This will help you in the process of understanding and reading the defined charts, and further help in the process of creating new charts based on the available parameters.

When the sample interval is reached (default: once every minute), Axigen performs the following operations:

• Increases or decreases all the SNMP counters based on the read parameter information;
• Stores all the parameter information based on which charts can be created;
• The Axigen configuration file is checked for defined charts;
• After all the defined charts are inventoried. The remaining parameter data that does not correspond to a defined chart is discarded;
• If the aggregation interval is reached, the aggregation function is applied on the previously recorded values of the remaining parameters. The resulted value is written in the defined chart's database used for displaying charts;
• If the aggregation interval is not reached, then the recorded values of the parameters are stored in memory with each sample interval until the aggregation interval is reached.

SNMP configuration steps

In addition to the charts displayed in the WebAdmin interface, starting with version 6.0 of Axigen, a SNMP service (Simple Network Management Protocol) has been implemented. This service can be used as an agent that can be queried using the SNMP protocol. The SNMP agent is read-only for the Axigen configuration settings.

Additionally, the SNMP service is able to send trap signals to configured hosts in one of the following situations:

• Server start;
• Server reloading;
• Server shutdown.

This feature can be used to notify other monitoring tools about the status of the server. In their turn, these tools can be configured to notify you about the status of the server, by email, phone, pager or other means.

The SNMP Send Traps To All Managers option will determine the Axigen mail server to send trap signals to all the hosts that queried the server using the SNMP protocol when one of the previously mentioned conditions are met.

In order to find the parameters that can be monitored using the SNMP protocol, a MIB file can be downloaded by navigating to the following location:

• Login to the WebAdmin interface;
• Click on Status & Monitoring;
• Click the Reporting service link;
• Within the SNMP Parameters section, there is a link for downloading the mentioned file.

Generally, this type of file can be viewed using specialized tools that are able to interpret the format of the file and display it in a human readable form, most often as a tree. These tools are also called MIB browsers and they can be used as SNMP managers, meaning that they can query Axigen for information regarding its reporting parameters’ values. The MIB browsing tools can also be used to send and receive trap signals.

In practice, the tool for interpreting the MIB file is not necessarily required since MIB files are essentially text files that can be viewed using a text editor also.

The MIB file is used for associating a reference tag (also called OID), used to query Axigen for the value of the parameter, with the name of the parameter in a human readable way.

For example, the OID 1.3.6.1.4.1.29463.2.1 represents the reference tag for the Total mails placed in the queue parameter that returns a value which is interpreted as described below.

By querying the reporting parameters using the SNMP protocol, an odd behavior can be observed: the returned values are always increasing instead of reflecting the actual status of the reporting parameter being queried. The explanation is that the tools that retrieve information from Axigen using the SNMP protocol create charts based on the changes from the previous value of the parameter being queried, and not its actual value.

The SNMP reporting feature of the Axigen mail server was designed with the purpose of creating performance representation charts, based on the information provided by the server, in a centralized solution where multiple other services are also monitored.

A typical example is a Network Operations Center where multiple machines and devices are monitored in a centralized way and all the information is consolidated using a SNMP managing tool that interprets trap signals when critical events occur or generates charts reflecting the usage of the managed devices.

Storage

The Axigen Storage is a specific file structure with index based access allowing fast mail delivery, retrieve and query. Axigen Mail Storage checks the consistency of the messages placed in the storage and empties the queue only if the mail message is correctly stored.

All domain and user configuration along with user messages are stored in Axigen's specific storage.

Each Axigen storage is defined by three elements:

1. Storage directory: the directory where all storage file will be created
2. Max. file size: maximum size of a data file (Storage Container). The default value is 256 MB.
3. Max. files: maximum number of files. The default value is 128 files.

Therefore the maximum capacity of each storage is Max. file size * Max. files and the default capacity is 32 GB.

Structure

Inside storage directory, a list of files, named with 2 hexa digits followed by the .hsf extension - e.g. 2A.hsf - are created. There is also a file named hsf.dat which contains an unique ID of the storage and the relation with other storages of the same domain. This information is useful in case some of the storage directories are moved to other locations.

Another feature of Axigen storage is that it supports transactions, so that some critical operations of domain configuration changes are made safely.

Filling the containers

When a storage container approaches its maximum size, (defined by the Max. file size parameter), another storage container will be created and the new messages will be stored herein. If the number of storage containers reaches the maximum value (defined by the Max. files parameter) and all of them have reached the maximum size, the storage is considered full and no more messages will be inserted.

The data in the storage containers is written in blocks of 4KB, therefore usually the files size is a multiple of 4KB. These memory blocks are called nodes. Smaller blocks of memory are also available, for message parts smaller than 4KB. These smaller blocks are called formatted nodes.

Each storage file can contain a maximum of 16 millions messages, and the maximum theoretical file size is 64GB (some limitations might apply, depending on your system configuration; currently Axigen limits this maximum size to 2GB). There can be maximum 128 files in one storage, and one domain can have over 4 billion message storages defined.

The actual maximum capacity in terms of total message count and size depends on the specific messages in the storage. For more details, see Domains section.

For each domain, at least three storages are used:

• one storage for domain configuration, where all domain specific configuration, the public folder and the list of domain objects (users, maillist, forwarders, etc) are stored;
• one storage for domain objects configuration, where all domain objects configurations and folders are stored;
• one or more storages for messages, where all mails and other data associated with mails are stored; it is recommended to define each message storage on a different physical disk, since Axigen will use these storages in parallel.

Space saving filling procedure

The storage files with more free space have a priority when it comes to selecting the files in which a new message is added. The usage of the free space is also enhanced by message deletion.

Each message in a storage file is identified by a pointerID (type UINT). The information related to these pointers-to-messages is stored in the same storage file.

Storage advantages

• Indexed data structure - Ensures an optimal balance between the space used for storing indexes and the time to access information by introducing multiple levels of indexes depending on how often information is accessed.
• Transactional access - Provides structural integrity for the stored information by performing transactional data access.
• Expandable storage - You can add subsequent storage units to one domain, thus increasing the available space.
• Single storage of emails with multiple recipients - Only one copy of a message received by multiple recipients is stored (particularly useful for distribution lists and groups).
• Repairing corrupted accounts - If an account’s data becomes corrupted (due to, for instance, disk failure), Axigen allows you to attempt account data recovery.
• Storage overload prevention - Ensured by limiting allowed message sizes according to specific policies based on multiple message or connection parameters.

Integrating with other solutions

The Axigen messaging solution provides two main methods of integrating third party filters with the processing engine and message filtering. The scanning process is performed during the processing stage of the messages in both cases, after multiple SMTP checks, such as DNS, GeoIP and SPF, are applied.

Axigen direct connectors for third party scanners

Also known as Axigen direct connectors, these filters apply once the SPAM and malicious messages have already been thinned-out by the previous SMTP level filters. They provide the most performance-effective method of integration by closely communicating with the third party scanners installed on the system.

The scanners receive instructions from the Axigen messaging solution through these filters and once the scan is complete, provide the relevant results back to the server. Using the results, Axigen decides the fate of the messages, including dropping or accepting the message. These actions can be fully customized to fit the requirements of any email traffic regulations.

The Axigen messaging solution provides custom-built and tested connectors for the following list of scanners, reducing the configuration required for the integration process to a minimum:

• avast! for Linux/Unix Servers
• SpamAssassin
• Clam AntiVirus
• AVG AntiVirus Email Server Edition
• Commtouch
• Kaspersky AntiVirus & AntiSpam

Axigen Milter integration for third party scanners

The Milter integration method acts at the SMTP level and follows the same baseline functionalities as the direct integration method through the connectors. Though, a few differences exist between the two approaches, such as lower performance results and a broader compatibility with third party scanners for the Milter, as opposed to the direct integration.

The Milter is actually a protocol that was originally designed for open-source mail transfer agents, but is currently being adopted as the new standard in the industry by a large number of email-related software vendors. Through this standard approach, any scanner that supports the Milter can be integrated with the Axigen messaging solution. The result of this feature is an extensive list of scanners that can be integrated with it, thus expanding Aixgen's ability to fit the needs and requirements of the environment it's being deployed in.

The complete list of scanners supported and tested through the Milter integration method follows:

• avast! for Linux/Unix Servers
• SpamAssassin
• AntiVir UNIX MailGate
• Avira MailGate Suite (AV/AS)
• Clam AntiVirus
• Nod32 for Linux / BSD Mail Server
• F-PROT Antivirus for Linux x86 / BSD x86 Mail Servers
• Kaspersky AntiVirus for Mail Servers
• BitDefender Security for Mail Servers (AV/AS)
• Brightmail AntiSpam

In addition to the above-mentioned list, other scanners that support the standard can easily be integrated with Axigen. One of these, although not a scanning software in itself, is the MailArchiva email archiving and storing solution. Indeed, the Milter protocol does provide close to limitless integration, compatibility and interoperability between the mail server and third party, related, software packages.

AD Snap-in

Active Directory integration

The integration and configuration process that relates to the Active Directory is performed entirely using the Microsoft Management Console (MMC) and the add-in snap-in provided for this purpose as an extension. This snap-in application can be downloaded free of charge from the download page on Axigen's website.

Once the installation of the ".msi" (Microsoft Installer) package for the snap-in is complete, the integration process can begin and the configuration of the existing Active Directory accounts can be performed. Before any actions can be performed, the Axigen mail server has to be configured correctly to use the AD server for syncing purposes. For this reason, an LDAP connector must exist before the following procedure is executed. If the Axigen mail server is not correctly configured, the sync process will fail.

With the "Axigen AD extension" package installed, a new tab will appear in the "Properties" section of the domain accounts. This tab can be accessed whether the selected account has the Axigen extensions enabled or not. To activate the Axigen extensions you need to right-click the account and select the "Create Axigen Account" option. This tab contents, for an account that has the Axigen extension enabled, is depicted in the following screenshot:

The options and configuration changes performed in this section apply exclusively to Axigen's configuration for this account. Service related changes and account information do not apply and are not inherited by the domain data of this account. Changing the contact information for this account (e.g. first name) will not change the "first name" attribute of this account in the Active Directory database.

Options and settings available while using the Active Directory add-in include:

• Alias management - allows the addition, modification and removal of email account aliases. These aliases can be used during the login procedure and for email delivery purposes.
• Configuration inheritance - allows the modification of the default (implicit) inheritance scheme (settings inherited from the domain level configuration).
• Service management - allows explicit definition of access levels for the email services, including SMTP, IMAP, POP3, WebMail and remote POP.
• Quota management - allows the configuration of the maximum allowed storage space that can be used by the account. By default this setting is inherited from the domain level. The following screenshot depicts the available service-related options:
• Restriction management - allows the explicit definition of certain restrictions related to password enforcement, email number, folder number etc. By default the settings here are inherited from the domain level.
  • Password - the password enforcement section allows the configuration of various rules that aim to increase the difficulty of password guessing. To change the default inherited options here, you need to click the "Set Explicit" button and the make the necessary modifications.
  • Sessions - allows the configuration of maximum concurrence values accepted per service for the respective account. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • WebMail - allows the configuration of attachment size and number as well as the maximum message size for WebMail generated messages. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • Body Filtering - this option applies to HTML message contents read through the WebMail interface. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • Message Sending - allows the setup of limitations on the number of messages delivered by the account in a certain time interval. To change the default inherited options here, you need to click the "Set Explicit" button and the make the necessary modifications.
  • Remote POP - allows the definition of a maximum number of RPOP accounts and the minimum RPOP polling time. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • Temporary Email - allows the activation or deactivation of this feature for the account, the number of addresses that can be created and the maximum expiry time for each of them. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • Send / Receive - these options limit the behavior of send or received emails by this account. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
• Contact information management - allows the modification of the contact data for the account owner (first name, address, email address, phone number etc.). These settings can be changed by the account owner upon login in the WebMail interface, through the use of the "Settings" panel.

In order to gain access to these settings the Active Directory administrator needs to enable the Axigen configuration for each account. This process requires each account to be added the Axigen set of parameters and enabling the sync options for the account. To perform this step and activate the Axigen configuration for a user account in the Active Directory database, you need to open the "Domain Users and Computers" snap-in and right-click one of the user accounts. Within the right-click menu a new option will be available if the snap-in was installed correctly:

Once the "Axigen Account" is appended to the Active Directory user, the sync for this account will be performed by the Axigen mail server on each lookup if modifications are detected. The sync process will take place in one direction or the other depending on the settings defined for the LDAP connector used to perform the sync.

WebMail Interface skins

The WebMail interface comes in two versions: Standard and the Ajax interface. You can set a default interface that will be provided to users when they access the WebMail link. You can also restrict access to one of the interfaces if you do not wish to use one of the two WebMail alternatives.

Additionally each domain can have it's customized WebMail interface by using the Virtual Hosts Template Mapping.

The Standard interface has three skins to choose from: classic, collwater and webreflection. You can choose one of the skins to be the default for all users. However, each user can then modify the default skin using the WebMail settings from the account.

Since version 7.2, the Ajax WebMail interface comes with advanced usability and manageability options. User-centric features such as keyboard navigation and shortcuts, drag-and-drop, live email list view and frequent folders render email related tasks more effective and pain-free, by allowing users to rely on shortcuts and time saving tricks they have already learned while using classic desktop email clients such as Outlook or Thunderbird.

For Service Providers, this innovative WebMail technology brings a series of features aimed to help them create new services and generate additional streams of income. Starting v7.2, Axigen offers multiple and customizable advertising capabilities, also allowing the integration with third-party ad servers.

The Ajax-powered WebMail can be used in parallel with the standard, localized WebMail interface, users being able to freely switch between interfaces from their login panel.

PHP CLI API

CLIClient is an API that allows easy configuration of Axigen. CLI is an Axigen service that allows configuration of the Axigen mail server. To access CLI, one must enable it and telnet on the port the service binds to, usually 7000. CLI uses contexts in order to group together similar operations, like server configuration (the "server#" context), POP3 service configuration (the "server-pop3#" context) or domain configuration (the "domain#" context). These contexts are positioned in a tree-like structure, so if one wants to configure something, one must go to the necessary context, make the changes through the use of commands and then commit the changes.

The CLIClient assigns objects to the various CLI contexts. These objects embed all the properties specific to a CLI context - for example the "domain" object has the 'name' property representing the domain name, like "mydomain.com". Also, the CLIClient has various methods for getting and setting the object properties. Once changes on the object are finalized, the object configuration can be saved back to Axigen, thus committing the changes. Also, the CLIClient has methods that return other objects, for example from the "account" object one can obtain the "quotas" object, representing the restrictions for that specific account. Naturally, Axigen's CLI service must be enabled for the CLIClient library to configure that server.

Examples:

• Create a new domain

<?php
require_once("Axigen.php");
$session=new Axigen();
/**Connect to Axigen server*/
$session->connect("IP", "CLIPORT", "ADMINUSER", "ADMINPASSWORD");
/**Create a new domain on Axigen server*/
$result=$session->createDomain("localdomain", "domains/localdomain/", "postmasterPassword");
/**Check domain creation result*/
if($result) {
print "Domain has been created<br>";
/**Save configuration to Axigen, for the domain to be registered on server restart*/
$saveResult=$session->saveConfig();
/**Check save result*/
if ($saveResult){
print "Configuration saved<br>";
}else{
print "Unable to save configuration<br>";
}
}else{
print "Unable to create domain<br>";
}
?>

• List all the domains

<?php
require_once("Aixgen.php");
$session=new Axigen();
/**Connect to Axigen server*/
$session->connect("IP", "CLIPORT", "ADMINUSER", "ADMINPASSWORD");
/**Get all the domains from Axigen server*/
$domains=$session->listDomains();
/**Print the resulted array*/
var_dump($domains);
?>

Archiving

MailArchiva is an email archiving system that makes use of highly scalable search engine technology, complying at the same time with specific legislation that acts in the email archiving field.

MailArchiva adds to the existing cutting edge features of the Axigen messaging solution quick access to information based on advanced search criteria, a smart storage system preventing overhead and ensures compliance with highly debated international standards such as the Sarbanes Oxley act (SOX), Gramm-Leach Bliley act (GLBA) and the Freedom of information act (FOIA). Therefore, the integrated Axigen-MailArchiva solution brings palpable benefits to businesses from all market segments:

• reliability and security in messaging and archiving policies;
• easy access to older information exchanged via emails;
• full history on your electronic communications;
• no overhead in email archive storage or in message delivery;
• safe operations with respect to local legislation and standards (for example, in certain countries legal requirements force companies to preserve all company email communications for seven years);
• credibility as a business partner through compliance with all major international standards.

Integration with Axigen is done using the Milter interface. An article presenting the configuration steps for integrating Axigen with MailArchiva, using the Milter interface is available here.

Clustered Operations

Having the system administrators' needs in mind, Axigen provides Clustering Support starting with version 3.0. Clustering support is based on LDAP integration with Axigen and allows routing for the SMTP Incoming, POP3 Proxy and IMAP proxy services. This feature enables you to spread mailboxes on several Axigen servers and have a separate machine that routes POP3/IMAP connections to the appropriate mailbox server.

Another important feature of the LDAP integration with the Axigen mail server is the LDAP Authentication mechanism. This method is available for all the Axigen services that require authentication: SMTP In, POP3, IMAP, WebMail, POP3 Proxy and IMAP Proxy.

Integration with LDAP (OpenLDAP and Active Directory) evolved and now synchronization of users and groups is possible in three different manners:

• Axigen to LDAP;
• LDAP to Axigen;
• Both ways.

For a detailed example on how to setup a high availability distributed solution see this related article:

• Implementing, Deploying and Managing a High Availability Distributed Solution on AXIGEN Mail Server.

Cluster overview

This section includes a brief LDAP introduction, Axigen Mapping and Authentication systems, as well as front-end and back-end services setup in Axigen.

Multi-tier cluster architecture

The solution uses three tiers to provide the required functionality. The load balancer tier provides services for network layer 4 (transport), TCP connections, and is completely unaware of account information; it only provides distribution of connections to the nodes in the front-end tier.

The front-end tier comprises of nodes running proxy services and SMTP routing services. Its task is to ensure that messages and connections are routed to the appropriate node (depending on the account for which a request is being performed) in the backend tier.

Finally, the backend tier provides access to persistent data (such as account configuration and mailbox data); each node in the backend tier is capable of responding to requests for a set of accounts. No node in the backend tier is capable of servicing requests for an account that is serviced by a different node.

LDAP information

During the first stages of cluster planning the most important service that needs to be considered is the LDAP directory. The LDAP server will be a part of the cluster back-end section and will be set to make use of the high-availability clustering ability.

The directory services are required for routing and authentication purposes. Without it, the proxies cannot route traffic to the designated node that stores an account. There are two situations a cluster engineer can encounter while setting up a cluster:

• No LDAP / Active Directory service is available and needs to be set up.
• A directory already exists and the cluster must be built around it.

Setting up a new directory service for the cluster

This type of setup can be created quite fast. The directory service must be installed and configured according to the cluster requirements, using the recommended default values, to be integrated as smoothly as possible with Axigen. Once the service is running, the next phase of cluster deployment should start and the proxies set in place.

Integrating an existing directory service with the cluster

The toughest configuration scenario is the use of an already existing directory service within the cluster environment. There are special requirements that must be dealt with, such as directory and entry structure, as well as the information provided to the mail server during normal operation. However, in most cases, to the existing entries some new fields need to be added and the already existing ones need to fit perfectly into the default entry model used by Axigen mail server. If Axigen and another application require the same field to have different types of values, then another, custom field, must be added to the entry structure to allow Axigen to behave as expected.

Axigen mapping system

Mapping information is required to establish the routing behavior in any Axigen cluster. The theory behind the mapping system is fairly simple: using the entry returned by the front-end query, the field referring to the mail host (back-end) is assigned as the destination system for that user’s session. The mapping data actually provides the information required by the front-end to decide what back-end holds the actual user account.

The mapping system performs this routing task in two basic ways:

• Using a local user database mapping information is retrieved by parsing a locally defined file, containing all mapping patterns.
• Using an LDAP directory mapping information is retrieved from the LDAP directory.

Both methods have the same result as long as they are configured properly. Mapping information is gathered using the Axigen User Map defined in the proxy configuration. The user map is used for routing and can also be used in the authentication process. The mapping system is one of the key elements in the front-end node configuration.

Local user maps are read from a file formatted in a specific way so that Axigen can interpret and retrieve information from it. Single entries can be provided for individual users as well as regular expressions to match and map multiple user accounts to the same back-end system. An LDAP directory is more recommended than the use of local files, because it is more productive while using a resource intensive setup such as a cluster.

An LDAP directory can be used to perform the authentication process too, so using it makes more sense in a complex setup because it helps keep track of front-end behavior from a central point. Most clusters will use LDAP or Active Directory to perform the mapping process and all that is required for this to work is setting up the routing property. It is a very straight forward method and is preferred because of the multiple advantages LDAP provides.

The mapping information is defined by selecting a user map in the proxy configuration. The selected user map will route connections to the back-end system using a local file or an LDAP directory.

While using an LDAP directory, the cluster engineer is presented with two possible connection options:

• Password (Simple) should be used whenever the information held in the LDAP directory can be retrieved using a plain LDAP search. This would also include password fields that should be available in plain text (un-hashed).
• Bind (Authenticated) is required only if the information stored in the directory tree has one or more fields that are hashed (such as DSA or RSA encrypted passwords). In this case only an authorized user can retrieve useful information.

Depending on the setup, both connections can be used in complete safety. However, some setups allow only bound connections. The most common example of such setup is Active Directory as it only allows authenticated users to search the directory tree and retrieve information.

While using a local file to define mapping information, in the user map configuration, the file path and name must be specified. In addition, Axigen must be able to access the file and read information from it. The local mapping file syntax is simple and flexible. The basic format of the local file used by the mapping system is:

<account-name-pattern> <back-end-system>

Example:

user1@example.tld 192.168.20.3

In the above example, the account "user1" in the domain "example.tld" will be assigned the back-end with the IP address 192.168.20.3. The back-end system can also be specified with its domain name and its fully qualified domain name:

user1@example.tld backend3.example.tld and user1@example.tld backend3

However, the above examples will also match the pattern "testuser1@example.tld" because the address contains the search pattern "user1@domain.tld". To prevent this behavior, regular expressions must be applied to the entry:

^user1@domain.tld backend3

Using this format, the pattern will match only if the account name starts with the pattern entered. Using the above examples, any standard Perl regular expression can be designed to match the required accounts. This way, accounts can be mapped alphabetically, based on domain name and other types of criteria.

Axigen authentication system

The authentication process is one of the most common safety measures used for any service. Axigen clusters also use authentication and support a wide variety of algorithms as well as password encryption.

Any Axigen cluster can make use of the two authentication methods available:

• Internal Authentication - the account information defined and stored on the back-end is used to process the authentication request.
• LDAP Authentication - the LDAP directory tree is used to search, retrieve and process the authentication request.

While using the internal Axigen authentication system, the password is retrieved by the server from its local user information data. The password is defined during the account creation process and can be changed at a later time, either by you or by the user from within the WebMail interface. This method does not require an LDAP server to be set up but is very slow by comparison.

LDAP authentication is very widely used in cluster setups because of the speed gain. Also, while using LDAP, the mapping system can be assigned to it and the resulting setup becomes a centralized configuration point for the proxy services. In addition, the LDAP server may already exist and contain the entries required, in which case the configuration overhead is reduced considerably.

The LDAP authentication isolates the process from the actual Axigen account defined. This can arise some unexpected results such as different passwords within the directory and the back-end server. While a user can still change its password from the WebMail interface, this password will not be updated in the LDAP tree structure and the user can become easily confused. To prevent such issues, a thorough synchronization process must be implemented within the cluster.

This type of authentication overrides the standard Axigen authentication method. As such, using LDAP to authenticate sessions for one service will also disable the internal authentication method for all services. LDAP authentication is performed using an LDAP connector that must be defined in advance. The directory tree must also be configured before the authentication process will succeed.

The authentication process consists of a three stage process:

• LDAP query - During this stage, Axigen performs a lookup in the directory tree and expects the account password information as the result.
• Credential information matching - Using the information gathered during the first stage, Axigen compares what the client provided against what LDAP returned.
• Session authentication - If the above process was successful the session becomes authenticated.

If any of the above stages fail for some reason, the session will not be authenticated. Thus, for the account that requests an authentication, the LDAP server must be able to return an entry and a valid password property.

LDAP synchronization

The LDAP/Active Directory synchronization feature built into the Axigen mail server product aims to provide data and option setting synchronization between the email service and an external directory database providing service on the network. This feature facilitates the administration and configuration processes as it ensures and maintains the consistency of the two sub-systems with minimum interaction and supervision overhead.

The Active Directory (AD) is based on regular LDAP implementations and the same methods can be used to access it as for the OpenLDAP software package. Consequently, the LDAP sync feature is compatible with both solutions. If one is interested in using the LDAP sync feature, one will have to make sure the minimum requirements are met, so incompatibility issues are avoided entirely.

Minimum requirements

This section lists the software requirements that the systems involved in the LDAP sync communication process and in the management of the entire solution should meet. The hardware requirements are not listed in this section as they can vary to great extent from one environment to another. For details on the hardware required in specific scenarios you should contact either the Sales Department or the Professional Services department for information.

1. Mandatory Software Packages:
   • An operating system compatible with the Axigen messaging solution, version 7.0 or newer
   • The Axigen messaging solution, version 7.0 or newer
2. Optional Software Packages:
   • OpenLDAP Version 2.4.11 or later. Any version that supports the multi-master replication technology (optional).
   • Active Directory Services – Included in Windows Server 2003 editions (optional).

Feature design & data flow

This section explains the behavior of the synchronization process and the options available to be set for this synchronization between the Axigen mail server and the supported directory database of your choice. The design and data flow section includes an overview of the technology and the processes it involves as well as a list of possible configurations for the sync process.

LDAP integration design

The standard LDAP (OpenLDAP) schema extension files are provided within the Axigen installation package to permit an OpenLDAP server administrator to extend the currently used schema (if any) with the Axigen mail server specific attributes. These attributes must be present in the schema file for the sync process to work as expected. If the attributes are not available, the sync process will fail and unexpected errors may be encountered.

The Axigen server, being configured to perform automatic syncs with an LDAP server, performs periodical queries in the directory database to detect changes. Whenever a change of a relevant LDAP entry is received, a specific event, that triggers a sync action, is generated. A relevant LDAP entry has to match either the account filter or the group filter (depending on what is being synced), in the appropriate LDAP "BaseDN" property for that entry.

The following LDAP service configuration options (in the case of accounts and, respectively, groups) are used when inquiring the LDAP server for changes:

• The LDAP BaseDN setting - This setting refers to the top of the directory tree that is used in the sync process.
• The entry Object Class type - The class refers to the type of object listed in the database. This affects the other sync options that are specific to each object type.
• Additional Filters - This value specifies the filters that apply to each entry. It is dependent on the object class type above.
• The LDAP Polling Interval - LDAP searches (that detect changes) are performed periodically, based on the settings configured in the LDAP connector (the LDAP polling interval value).

When changes between the two databases are detected, they are queued up for syncing. After no more changes are detected for the entries in the LDAP database, the Axigen service will wait for the "LDAP Polling Interval" seconds before looking up changes in the database again. This process is repeated over and over and ensures that the consistency between the two databases is achieved regularly.

Active Directory integration design

The Active Directory integration involves the use of the Axigen extension provided, to allow extending the standard AD schema with the required Axigen attributes, as well as a Management Console (MMC) property page, to allow graphical editing of Axigen specific attributes when an account is modified to include the aforementioned properties.

The Axigen server, being configured to perform automatic syncs with an Active Directory service, performs periodical queries in the directory database to detect changes. Whenever a change of a relevant Active Directory entry is received, a specific event, that triggers a sync action, is generated. A relevant Active Directory entry has to match either the account filter or the group filter (depending on what is being synced), in the appropriate Active Directory "BaseDN" property for that entry.

The following LDAP service configuration options (in the case of accounts and, respectively, groups) are used when inquiring the LDAP server for changes:

• The LDAP BaseDN setting - refers to the top of the directory tree that is used in the sync process.
• The entry Object Class type - refers to the type of object listed in the database. This affects the other sync options that are specific to each object type.
• Additional Filters - this value specifies the filters that apply to each entry. It is dependent on the object class type above.
• The LDAP Polling Interval - LDAP searches (that detect changes) are performed periodically, based on the settings configured in the LDAP connector (the LDAP polling interval value).

Active Directory searches (that detect changes) are performed periodically, based on the parameter configured in the LDAP connector (LDAP polling interval). If changes are detected, they are queued. After no more changes exist in LDAP, the thread sleeps for "LDAP Polling Interval" seconds, then a new search is performed.

Synchronization options

To understand the synchronization methods and options, the association between the Axigen object and the LDAP / Active Directory entries needs to be taken into account. When the first successful synchronization of an Axigen account or group with an LDAP entry takes place, Axigen stores an identification of the corresponding LDAP / AD entry for further reference. Once this process takes place, the Axigen account or group will only be synchronized with the specific entry it was associated with and no other.

The association cannot be removed easily and should not be necessary in regular conditions. However, to perform this task, an administrative account with sufficient privileges needs to use the Axigen command line interface to remove it. The association between these elements can therefore only be removed by means of a CLI command.

1. Bidirectional synchronization

To perform bidirectional syncs between LDAP /AD and Axigen entries, the LDAP connector needs to be configured to reflect this fact. In the LDAP Connector configuration available in the Axigen WebAdmin interface, the "Synchronization direction" option needs to be set up with the "Both Ways" value.

Bidirectional syncs also need to have another parameter set up to be used in solving conflicts that may appear during the syncs. Conflicts arise when an entry was changed during the "LDAP Polling Interval" both in LDAP / AD and Axigen. This is not a situation encountered often, but it has to be addressed nonetheless. In this sense, the connector can be instructed which source of information will take precedence in case conflicts appear. By setting up the "Conflict resolution" option, one of the following three resolutions is attained:

• Axigen wins. This case states that the changes performed in Axigen will take precedence and get written to LDAP / AD. The changes performed in the LDAP / AD configuration prior to the sync will be lost and only the changes performed in the Axigen configuration will remain.
• LDAP wins. This case states that the changes performed in LDAP / AD will take precedence and get written to Axigen. The changes performed in the Axigen configuration prior to the sync will be lost and only the changes performed in the LDAP / AD configuration will remain.
• No change. This case discards all changes and no service takes precedence. The entry is not modified at all and all changes, performed in both LDAP or AD and Axigen, are lost. The initial configuration will be kept without altering it in any way.

Depending on the setup requirements and the goals one wishes to achieve, only one of these bidirectional mechanisms can be used at any given time. You may, however, define more than one connector in the configuration of your Axigen server, each using a different sync mechanism.

2. LDAP/AD to Axigen synchronization

While using the LDAP / AD to Axigen sync method, the LDAP changes or modifications always take precedence. In addition, all changes expressly performed within the Axigen configuration will not be synced to LDAP or Active Directory, but will be disregarded completely.

You should use this method especially when you use an Active Directory setup and you plan on using the MMC add-on snap-in to manage the Axigen configuration for the users, and then sync it to the server itself to be applied. This method can also be applied if you use and OpenLDAP database and you are used to manipulating the settings of various other network services through its contents.

3. Axigen to LDAP/AD synchronization

While using the Axigen to LDAP / AD sync method, the Axigen changes or modifications always take precedence. In addition, all changes expressly performed within the LDAP / AD database will not be synced to Axigen, but will be disregarded completely.

This method should be used by administrators that use LDAP exclusively for Axigen related purposes and use the Axigen administration interface to perform changes setting regularly. It is also possible to use this method with Active Directory, though some seasoned administrators will always prefer using the AD specific administration tools over a new interface for each product.

Categories of synced data

The following categories of data and individual element changes are considered relevant with respect to the LDAP / Active Directory synchronization:

1. Account objects - The account objects are user accounts present in the Axigen domain storage and directory entries that are associated with them. For the account sync to work, the "Account base DN" option must be specified in the LDAP connector configuration.
2. Group objects - To sync groups the "Enable Group Synchronization" check-box must be enabled in the LDAP connector configuration and the "Group base DN" must be specified correctly.

For these two types of objects, the following table lists available events that result in sync actions. The last column (Account Type) also specifies the permissions required to make the listed changes in the server's configuration. Some changes require administrative privileges while others can be performed by account owners:

Regarding the list of contact information data that can be synced between Axigen and LDAP or AD services, only the ones listed below are included:

• Account owner First Name;
• Account owner Last Name;
• Account owner Nickname;
• Account owner Personal Email;
• Account owner Business Email;
• Account owner Phone;
• Account owner Mobile Phone;
• Account owner Home Phone;
• Account owner Business Phone;
• Account owner Home Address;
• Account owner Business Address.

These values refer to the Axigen account personal information only and do not include any data related to Contacts or other data that may be stored by that account (address book, contact details, appointments, attendees etc.)

Integration processes

This section describes the configuration options and example setups that need to be used during the implementation of the LDAP/AD sync feature in new and existing setups. The integration consists in specific steps and procedures that must be abided to in order to achieve a successful integration of the sub-systems.

Important notices

1. Always back-up the information that may be damaged or lost in the synchronization process. Failure to do so may result in permanent data loss.

2. Make sure you fully understand the implications of each setting you change before committing or saving any new configurations. Changes that are not saved are automatically discarded by the server.

3. Once you enable the automatic sync process, make sure you only perform changes in a single administration interface to avoid inconsistencies. Failure to do so may result in changes not being applied correctly or being discarded during the sync process.

4. Do not use "Both Ways" sync methods unless absolutely necessary. Although conflict resolution takes care of any conflicts, changes performed on the same database by multiple agents can often lead to unexpected results and make any issue debugging process tedious.

Axigen LDAP connector configuration

This section describes the settings available in Axigen's configuration that apply to the LDAP synchronization feature and affect its behavior. Some of them are also briefly described in other sections of the documentation, but for centralization purposes all options will be explained in this section as well.

1. Synchronization options

The following screenshot provides a section preview of the modal window used during the creation of a new LDAP connector within the Axigen WebAdmin interface. The same options are available in the connector properties page, once it was created:

Option names and functions:

• Server type - Specifies the type of LDAP server to use while performing the synchronization. This option can take two values only:
  • OpenLDAP – Enable this option if you plan on using an OpenLDAP type of server.
  • ActiveDirectory – Enable this option if you plan on using an Active Directory service.
• Timeout - Specifies the maximum allotted time for each lookup being performed. Once this set value is exceeded, the lookup is terminated and a timeout is returned and logged.
• Synchronization direction - This option specifies the source and destination of the sync. It can have one of the following values:
  • Axigen to LDAP – By using this setting only information from the Axigen storage is synced to LDAP. Any changes made in LDAP do not get saved at all and are discarded.
  • LDAP to Axigen – By using this setting only information from the LDAP database is synced to Axigen. Any changes made in Axigen do not get saved at all and are discarded.
  • Both ways – By using this option you will let both Axigen and LDAP update the entry configuration. While this option is enabled, the "Conflict resolution" option must be set up correctly.
• Conflict resolution - This option is only available if the synchronization direction is set to "Both ways" and specifies which of the two possible sources takes precedence in case a conflict arises. It can take one of the following three values:
  • Axigen wins – By using this option, Axigen changes take precedence over LDAP changes.
  • LDAP wins – By using this option, LDAP changes take precedence over Axigen changes.
  • No change – By using this option, all conflicts are ignored and the changes discarded.

2. Directory lookup options

The following screenshot provides a section preview of the modal window used during the creation of a new LDAP connector within the Axigen WebAdmin interface. The same options are available in the connector properties page, once it was created:

Option names and functions:

• Account base DN - This setting refers to the top of the directory tree that is used in the sync process for the user account objects.
• Enable Group Synchronization - While this option is enabled group synchronization is activated for the LDAP connector in question. If this option is disabled, the "Group base DN" option is not available.
• Group base DN - This setting refers to the top of the directory tree that is used in the sync process for the group objects. This option is not available while the "Enable Group Synchronization" option is disabled.
• Use custom schema - While this option is enabled, a custom LDAP schema file may be loaded and used during the sync process. If this option is disabled, the "Custom schema file" variable is not available. Do not enable this option if you plan on using Active Directory instead of LDAP.
• Custom schema file - This setting contains the path to the custom schema file to use. This option is not available while the "Use custom schema" option is disabled.

While configuring the LDAP connector, certain expanding variables can be used to substitute domain, account and other variable elements. The table below lists all of the usable variables, their meaning and an example of how they expand in practice:

3. Domain-specific options

The following screenshot provides a section preview of the domain-related options within the Axigen WebAdmin interface. The same options are available for all domains by entering their properties page, once they were created:

Option names and functions:

• Enable LDAP synchronization. While this option is enabled, syncing for accounts and/or groups can take place for the objects part of this domain. While this option is enabled, a correct LDAP connector must also be specified.
• LDAP connector. This option is not available unless the "Enable LDAP synchronization" option is active. To set the domain to synchronize with a LDAP service, you have to choose the correct connector from the drop-down list.

Active Directory integration

The integration and configuration process that relates to the Active Directory is performed entirely using the Microsoft Management Console (MMC) and the add-in snap-in provided for this purpose as an extension. This snap-in application can be downloaded free of charge from the download page from Axigen's website.

Once the installation of the ".msi" (Microsoft Installer) package for the snap-in is complete, the integration process can begin and the configuration of the existing Active Directory accounts can be performed. Before any actions can be performed, the Axigen mail server has to be configured correctly to use the AD server for syncing purposes. For this reason, an LDAP connector must exist before the following procedure is executed. If the Axigen is not correctly configured, the sync process will fail.

With the "Axigen AD extension" package installed, a new tab will appear in the "Properties" section of the domain accounts. This tab can be accessed whether the selected account has the Axigen extensions enabled or not. To activate the Axigen extensions you need to right-click the account and select the "Create Axigen Account" option. This tab contents, for an account that has the Axigen extension enabled, is depicted in the following screenshot:

The options and configuration changes performed in this section apply exclusively to the Axigen mail server configuration for this account. Service related changes and account information do not apply and are not inherited by the domain data of this account. Changing the contact information for this account (e.g. first name) will not change the "first name" attribute of this account in the Active Directory database.

Options and settings available while using the Active Directory add-in include:

• Alias management - This section allows the addition, modification and removal of email account aliases. These aliases can be used during the login procedure and for email delivery purposes.
• Configuration inheritance - This section allows the modification of the default (implicit) inheritance scheme (settings inherited from the domain level configuration).
• Service management - This section allows explicit definition of access levels for the email services, including SMTP, IMAP, POP3, WebMail and remote POP.

• Quota management - This section allows the configuration of the maximum allowed storage space that can be used by the account. By default this setting is inherited from the domain level. The following screenshot depicts the available service-related options:
• Restriction management - This section allows the explicit definition of certain restrictions related to password enforcement, email number, folder number etc. By default the settings here are inherited from the domain level.
  • Password - The password enforcement section allows the configuration of various rules that aim to increase the difficulty of password guessing. To change the default inherited options here, you need to click the "Set Explicit" button and the make the necessary modifications.
  • Sessions - Allows the configuration of maximum concurrence values accepted per service for the respective account. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • WebMail - Allows the configuration of attachment size and number as well as the maximum message size for WebMail generated messages. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • Body Filtering - This option applies to HTML message contents read through the WebMail interface. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • Message Sending - This section allows the setup of limitations on the number of messages delivered by the account in a certain time interval. To change the default inherited options here, you need to click the "Set Explicit" button and the make the necessary modifications.
  • Remote POP - Allows the definition of a maximum number of RPOP accounts and the minimum RPOP polling time. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • Temporary Email - Allows the activation or deactivation of this feature for the account, the number of addresses that can be created and the maximum expiry time for each of them. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
  • Send / Receive - Options that limit the behavior of send or received emails by this account. To change the defaults you need to click the "Set Explicit" button next to the required option and make the changes.
• Contact information management - This section allows the modification of the contact data for the account owner (first name, address, email address, phone number etc.). These settings can be changed by the account owner upon login in the WebMail interface, through the use of the "Settings" panel.

In order to gain access to these settings the Active Directory administrator needs to enable the Axigen configuration for each account. This process requires each account to be added the Axigen set of parameters and enabling the sync options for the account. To perform this step and activate the Axigen configuration for a user account in the Active Directory database, you need to open the "Domain Users and Computers" snap-in and right-click one of the user accounts. Within the right-click menu a new option will be available if the snap-in was installed correctly:

Once the "Axigen Account" is appended to the Active Directory user, the sync for this account will be performed by Axigen on each lookup if modifications are detected. The sync process will take place in one direction or the other depending on the settings defined for the LDAP connector used to perform the sync.

OpenLDAP integration

The integration between the Axigen mail server and the OpenLDAP software package and service is rather straight-forward in the sense that only some initial configuration is involved for the latter solution with the rest of the details being synced from the mail server database automatically. To set up the LDAP service appropriately, you must first make sure the version you are running is compatible with Axigen. You need to be using a LDAP version newer than 2.4. If you are not running a correct version you have to upgrade your LDAP server before attempting to run the sync. It is important to run the latest version of LDAP to make sure the integration is performed as smoothly as possible.

Once you have a supported LDAP version, you need to configure it appropriately before populating the database. The configuration file should include the correct schemas for the objects to be created and managed:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/axigen.schema

Also very important, you have to enable support for the second version of the LDAP protocol:

allow bind_v2

Following are the recommended database options, as well as the indexing options that are normally used for the Axigen entry value (expected) contents:

serverID 1
database bdb
suffix "dc=localdomain,dc=test"
checkpoint 32 30
rootdn "cn=admin,dc=localdomain,dc=test"
rootpw secret
directory /var/lib/openldap-data
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index entryUUID,entryCSN eq

Of course, you always have to replace the "dc=" sections with the domain name you plan on using and the administrative password which is only provided here for reference purposes. The indexing options should be specified at all times if you plan on having a decent performance for your lookups. Failure to set the indexing options before populating the database may result in additional future configuration overhead to apply this change.

To enable replication support, you need to enable the following configuration options in the LDAP configuration file:

overlay syncprov
syncprov-checkpoint 100 30
syncprov-sessionlog 1000

In the above example, the "syncprov-checkpoint" arguments create a new checkpoint every 30 minutes or every 100 operations. Also, the "sessionlog" will be limited to 1.000 entries and if you plan on making (or expect) a lot of syncs to take place in a short while (or at once), you should consider increasing this number of kept records.

Lastly, you have to enable support for "Member-of" support (for groups) if you plan on using this feature:

moduleload memberof.la
overlay memberof
memberof-refint true

This concludes the LDAP configuration file contents and requirements. On top of this initial setup you will have to consider a couple of more details before moving on with the integration. First off, if you already have a populated LDAP database you should either use another (different) database for Axigen related syncs or upgrade the current entry layout to match the following design:

• Root node layout:

dn: dc=localdomain,dc=test
objectclass: organization
objectclass: dcObject
o: localdomain.test
dc: localdomain

• Organization node layout:

dn: o=localdomain, dc=localdomain,dc=test
objectclass: organization
o: localdomain

• Groups unit layout:

dn: ou=Groups, o=localdomain, dc=localdomain,dc=test
objectclass: organizationalUnit
ou: Groups

• User unit layout:

dn: ou=Users, o=localdomain, dc=localdomain,dc=test
objectclass: organizationalUnit
ou: Users

Based on the node and unit (entry) layout above you should be able to generate the appropriate LDIF files for your specific scenario. Relevant information on the actual properties attached to the Axigen entries in LDAP can be found in the LDAP schema file called "axigen.schema".

In addition to this approach you may also choose to let Axigen sync the data and automatically create the entries in the LDAP server through the regular update process of the database. In fact the second approach is the recommended one in most cases, except of course if you already have a populated database that may be corrupted during this process.

LDAP routing

The Axigen mail server provides routing options at SMTP In, POP3 Proxy and IMAP Proxy level through its integration with OpenLDAP. LDAP stands for Lightweight Directory Access Protocol. It is a model for Directory Services that provides a data/namespace model for both the directory and a specific protocol.

A directory is a specialized database with a hierarchical structure designed for frequent queries but infrequent updates. Unlike general databases, they don't contain transaction support or roll-back functionality. Directories are easily replicated to increase availability and reliability.

In order to be configured for use within Axigen, OpenLDAP has to already be set up. OpenLDAP installations may very, depending on your preferred operating system. Integrating OpenLDAP with Axigen is a two-step process, as described below:

1. Configuring OpenLDAP for Axigen

• please run the following command and then place the following text:

# ldapadd -D "cn=admin,dc=localdomain,dc=test" -W
dn: dc=localdomain,dc=test
objectClass: dcObject
objectClass: organization
dc: localdomain
o: test

• In order to add users to the LDAP directory, add the following into a file. You may add as many users as you want in this file:

dn: cn=user1,dc=localdomain,dc=test
objectClass: inetOrgPerson
objectClass: inetLocalMailRecipient
cn: user1
sn: user1
mail: user1@localdomain
userPassword: user1
mailHost: 127.0.0.1

• Then run the following command:

# ldapadd -D "cn=admin,dc=localdomain,dc=test" -W -f file.txt

• You will be asked for the password you set up in the /etc/openldap/slapd.conf file (in our example, "secret").
• You can test if the user was added using the following command (the second version of the command includes authentication:

# ldapsearch -b "dc=localdomain, dc=test"
# ldapsearch -b "dc=localdomain, dc=test" -D "cn=admin,dc=localdomain,dc=test" -W

• In order to delete an entry, use the command:

# ldapdelete -D "cn=admin,dc=localdomain,dc=test" -W
# cn=user7,dc=localdomain,dc=test

• To edit an LDAP entry, just use:

# ldapmodify -D "cn=admin,dc=localdomain,dc=test" -W
# dn: cn=user5,dc=localdomain,dc=test
# changetype:modify
# mailHost:10.10.247.5
#

2. Configuring LDAP connectors in Axigen

The LDAP connector can be configured via Webadmin -> "Clustering" -> "Clustering Setup" -> "LDAP Connectors" tab -> "Connector List" section -> press the "Add Connector" button.

The connector options should be entered based on the settings of your LDAP server. Enter a name for the connector in the "LDAP Connector name" field.

In the "LDAP Server Parameters" enter:

• the IP/Hostname and Port on wich the LDAP server is listening. By default the port is 389;
• from the "Server type" drop-down box select the server type you wish to use the connector with: OpenLDAP or ActiveDirectory;
• if you are setting up the Axigen server for a cluster environment check the box related to the "Enable Clustered Operations" option, which when enabled will determine Axigen to match entries based on the backend hostname attribute).

• in this section you can also set the "Timeout" counter (interval corresponding to the timeout on an Axigen <-> LDAP connection) which is by default set to 4 seconds and can take values between 1-600 seconds, the "Polling interval" (time period between two automatic Axigen to LDAP queries) which is by default set to 10 seconds and can take values between 2-600 seconds and "Transient error retry interval" counter which is by default set to 5 seconds and can take values between 2-600 seconds.
• select the required synchronization method from the drop-down box related to the "Synchronization direction" entry. You can choose to use Axigen to LDAP, LDAP to Axigen or Both ways. If you choose both ways synchronization you will then have to choose a winner for the situations when there is a parameter synchronization conflict (LDAP and Axigen have a different value for a parameter).

In the "LDAP Search Parameters" you can set:

• enable the "Use Administrative DN" - This option instructs Axigen to authenticate, using the defined user, to the LDAP server before requesting information. This user is the admin user defined in the LDAP rootdn configuration;
• enter the proper "Admin DN" and "Admin DN Password";
• in the "Account base DN" field enter the DN of the LDAP organizational unit where the user accounts are defined. For example: ou=Users,dc=example,dc=test. You can also use the %x parameter, to create a connector that can be used in a multiple domain setup, which will expand depending on the name of the synchronized domain.

if you wish to also synchronize the Axigen Groups with the LDAP server, you can optionally check the box related to "Enable Group Synchronization" and enter in the "Group base DN" field the DN of the LDAP organizational unit where the group accounts are defined. For example: ou=Groups,dc=example,dc=test.

• if you wish to use a custom correspondence between the Axigen account parameters and the LDAP parameters, you can check the box related to the "Use custom schema" option. Then enter the custom schema file name in the related text box. To obtain a custom schema for your setup, please contact our support line, making sure you provide them with your requirements and examples of what custom account parameters you wish to use.

In the "LDAP Routing Configuration" section you can set the "Hostname attribute" which has to point to the LDAP account parameter that holds the hostname of the server where the account is located (ex: mailHost). This parameter is used by Axigen when you configure SMTP or WebMail/IMAP/POP3 proxy routing, to determine to which server it will route the respective connection. This is useful in a clustered environment.

Configuring mapping parameters

In order to successfully route connection on either of the supported protocols, SMTP, POP or IMAP, you need to set mapping parameters. The easiest and most intuitive way of setting mapping parameters is through WebAdmin, Axigen's web-based administration interface.

In the User Maps page you can add and configure a list of User Maps at server level. In order to do so, you should access "Clustering" -> "Clustering Setup" -> "User Maps" page and hit the "Add User Map" button.

{{borderedimage|[[Image:WebAdmin_-_Axigen_Clustering_-_User_Maps.png}}

For each new user map, the following parameters are available: name, type (Local file, LDAP Password, LDAP Bind) and, as the case may be , either file location or defined LDAP Connectors.

POP3 Proxy service

The Axigen POP3 Proxy module establishes connection trough remote servers with POP3 clients. The server accepts connections as specified by the POP3 Proxy listeners defined in the configuration file. By default the server accepts connections on 127.0.0.1:110 .

Listeners

Listeners can be defined and managed to add extra flexibility and configurability to this service. For that, global access limitations, SSL Settings and access lists can be enforced on the address used by this service for binding.

Access control

Access rules allow you to control connection to this service by defining simple access lists for specific Networks / IP Ranges / IP’s. Service level access rules are automatically applied to all its listeners and will override for this service any existing Global Access rules.

Flow control

Flow control parameters can be adjusted to fine tune the server’s performance and avoid overloading it. Global access limitations to this listener can be enforced by setting the total number of simultaneous connections, concurrent connections from each remote IP address, number of new connections to the listener made in a time period interval, number of total connections from each remote IP address on a time interval period. The default interval for this time period is set to 1 minute.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Encryption and authentication

The POP3 Proxy service only supports PLAIN authentication, which is why it is recommended that StartTLS or SSL are used for encrypting the connection. The authentication can be performed on the POP3 proxy or on the back end server.

Error control

To protect the server, the number of failed / wrong commands received from POP3 clients during one session can be limited. When these limits are exceeded, incomplete connections or connections that are not RFC compliant will be dropped thus freeing important bandwidth.

Thread management

The Axigen mail server is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

Back-end server connection settings

In this section, you can allow a connection timeout to be set, specify the maximum number of connections between POP3 Proxy and the back-end Server, another local network interface IP address to be used for connections with the back-end server and whether or not to use SSL to connect to the back-end server.

IMAP Proxy service

The Axigen IMAP Proxy module establishes connection trough remote servers with IMAP clients. The server accepts connections as specified by the IMAP Proxy listeners defined in the configuration file. By default the server accepts connections on 127.0.0.1:110 .

Listeners

Listeners can be defined and managed to add extra flexibility and configurability to this service. For that, global access limitations, SSL Settings and access lists can be enforced on the address used by this service for binding.

Access control

Access rules allow you to control connection to this service by defining simple access lists for specific Networks / IP Ranges / IP’s. Service level access rules are automatically applied to all its listeners and will override for this service any existing Global Access rules.

Flow control

Flow control parameters can be adjusted to fine tune the server’s performance and avoid overloading it. Global access limitations to this listener can be enforced by setting the total number of simultaneous connections, concurrent connections from each remote IP address, number of new connections to the listener made in a time period interval, number of total connections from each remote IP address on a time interval period. The default interval for this time period is set to 1 minute.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Encryption and authentication

The IMAP Proxy service only supports PLAIN authentication, which is why it is recommended that StartTLS or SSL are used for encrypting the connection. The authentication can be performed on the IMAP proxy or on the back end server.

Error control

To protect the server the number of failed/wrong commands, received from POP3 clients during one session, can be limited. When these limits are exceeded, incomplete connections or connections that are not RFC compliant will be dropped thus freeing important bandwidth.

Thread management

The Axigen mail server is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

Back-end server connection settings

In this section, you can allow a connection timeout to be set, specify the maximum number of connections between IMAP Proxy and the back-end server, another local network interface IP address to be used for connections with the back-end server and whether or not to use SSL to connect to the back-end server.

WebMail Proxy service

The Axigen WebMail Proxy is an Axigen service (somewhat similar in functionality and configuration with the IMAP Proxy and POP3 Proxy services) that allows connection proxy-ing from the front-end layer to the back-end layer in a clustered environment.

Listeners

Listeners can be defined and managed to add extra flexibility and configurability to this service. For that, global access limitations, SSL Settings and access lists can be enforced on the address used by this service for binding.

Access control

Access rules allow you to control connection to this service by defining simple access lists for specific Networks / IP Ranges / IP’s. Service level access rules are automatically applied to all its listeners and will override for this service any existing Global Access rules.

Flow control

Flow control parameters can be adjusted to fine tune the server’s performance and avoid overloading it. Global access limitations to this listener can be enforced by setting the total number of simultaneous connections, concurrent connections from each remote IP address, number of new connections to the listener made in a time period interval, number of total connections from each remote IP address on a time interval period. The default interval for this time period is set to 1 minute.

Logging

All Axigen main services can log different types of events. You can specify what events are logged, where and how they are logged.

Encryption and authentication

When the user performs the login post, from the login page, the WebMail proxy picks up the username and password and performs either of the following steps:

• Proxy authentication

If proxy authentication is selected, the proxy attempts to verify the credentials through LDAP Password or LDAP Bind. If authentication fails, the login page is presented again, with the username filled-in with the same value as the user input and a message informing the user that the authentication has failed. After re-typing the password the user may request login again and the process is resumed.

• Back-end authentication

If proxy authentication is disabled, the proxy looks-up the user in LDAP, identifies the back-end Axigen node, performs the authentication request and, if the authentication is successful on the back-end, provides the client with the session token and redirects it to the Inbox.

HTTP Protocol options

WebMail allows you to set HTTP limits for any request made to the WebMail Proxy service. This prevents automatically accepting excessive amounts of data (HTTP headers, HTTP body and upload data).

Instruct the WebMail service to start device detection, if a "mobile" device is detected the mobile WebMail interface will be displayed instead of the regular interface.

WebMail Proxy options

The maximum number of pending requests to each back-end can be controlled by defining the request queue size. If, for a specific back-end, a new request is incoming and the queue is at its maximum size, the "503 Service Unavailable" error is immediately returned.

Virtual host WebMail templates

The WebMail service can be configured so that each virtual host (determined by URL) is associated with a certain HSP template. All available templates are placed in a specific directory.

Thread management

The Axigen mail server is designed to run on different machine configurations and operating systems, on networks with various traffic loads, structures, domain configurations, user rights etc. That is why, depending on all these variables, you can adapt the workload to the server’s processing power to improve its performance or avoid overload by setting the minimum and maximum number of threads that can be opened at a specific moment of time.

Back-end server connection settings

In this section, you can allow a connection timeout to be set, specify the maximum number of parallel requests that can be performed on the back-end server, another local network interface IP address to be used for connections with the back-end server and whether or not to use SSL to connect to the back-end server.

Front-end services setup

The services that run on the front-end nodes of the cluster are only the proxy services. All of these services can run on any number of systems without affecting the overall cluster availability. As long as one of the front-end nodes is still serving incoming requests, the cluster will be fully functional.

Because all front-end nodes are identical, you can add or remove nodes at will. The more front-end nodes your cluster has, the more requests will be processed at the same time. It is important to have sufficient front-ends to keep up with the number of the requests, especially during peak activity times.

The following services provide proxy abilities within Axigen:

• SMTP Proxy routes and authenticates incoming SMTP sessions. This service is vital for mail delivery within the cluster.
• IMAP Proxy routes and authenticates IMAP sessions. This service allows users to retrieve their messages from their back-end account through the proxy using the IMAP protocol.
• POP3 Proxy routes and authenticates POP3 sessions. This service allows users to retrieve their messages from their back-end account through the proxy using the POP3 protocol.
• WebMail Proxy routes and authenticates WebMail access requests. This service also renders the web pages requested by the web browser, using the information retrieved from the back-end server holding the user account.

The SMTP Proxy

While configuring the Axigen cluster, the SMTP service can be set up using two methods. The default state of this protocol enables it to run as a 'local' service, meaning it will try to deliver messages locally if the destination of an email is a domain defined in the Axigen configuration. The second state, that can be enabled and disabled as required, is the 'routing' state.

If the SMTP service is set up to route connections, it will use its assigned user map to decide where an incoming connection must be forwarded. This action will only be taken for entries found in the user map. If the destination is not present in the mapping system and no result is returned, then the service will relay the message and normal SMTP policy rules will apply.

The SMTP proxy uses the same authentication method as all of the other services that run on that particular node. This is why, in the event that LDAP authentication is used, the same connector will be used for all services.

The IMAP and POP3 Proxies

Both of these services provide similar functions within the cluster and from a configuration standpoint, they are identical. They both use the same authentication method, internal or LDAP, and in the second situation, they use the same connector. In a similar way, the same user map is used for the routing section of these services.

The only notable difference between configurations of these services is the failover address and port used. The failover address is used in case a match is not found in the user map. As these services use different ports and different protocols, an IP-port pair can be specified as failover for each individual service.

Both IMAP and POP3 proxy services can run on the same system as the IMAP and POP3 services, forwarding requests to the same system or another system when required. This helps with the design of single tier clusters that have neither stand-alone front-end nodes, nor load balancers.

The WebMail Proxy

The WebMail proxy replaces the standard WebMail interface available on an individual Axigen server. The public area of the interface and the main login page are identical to the normal WebMail interface but the session information displayed after the login procedure has been completed and is preloaded from the back-end nodes.

Mapping setup

User maps are used to provide routing information to the proxy services running on a cluster node. More than one user map can be defined and each can be configured separately.

A user map can have one of the three following types:

• Local File - Uses a specified path to load a local file containing the routing information.
• LDAP Password - Connects to an LDAP server using one of the defined connectors.
• LDAP Bind - Uses bound connections to an LDAP server requiring authentication such as an Active Directory tree.

Once the type of the mapping is set, the configuration details must be solved. For the local file mapping to work, a local file with mapping information must exist. This file must have the correct permissions set for Axigen to access it and retrieve the information.

With the LDAP mapping type, an LDAP connector must be selected from the list of defined connectors. If no connector has been defined, a new one must be set up so Axigen can retrieve the mapping information from the LDAP server.

Back-end services setup

Axigen back-end services setup

The cluster back-end systems are the actual information center for the entire setup. The system or systems that make up the back-end area of any cluster require access to storage resources. Thus, the Axigen services that run on these systems are very similar in configuration to the services that run on any stand-alone Axigen server.

The back-end services used by the cluster nodes are:

• SMTP Services will provide functionality for the incoming and outgoing mail received by the accounts stored on the cluster node. The SMTP incoming service will accept connections from the SMTP proxies on the front-ends.
• IMAP and POP3 Services will accept routed connections from the respective proxy services. They will retrieve the information from the storage and pass it to the proxies to be displayed in the mail client.
• WebMail Service will provide the information required by the WebMail proxies to render the pages requested by the client. It will not be accessible directly, only through routed connections from the proxies.
• Other Services include other modules supported by the server that are independent on the cluster setup. These include the FTP Backup service, the CLI, the WebAdmin interface, RPOP etc.

These systems have domains and accounts set up locally and take care of the imposed restrictions regarding disk space usage and quota management. All details concerning the actual user account settings must be defined and configured on the back-end systems, through any of the administration interfaces.

All services that make use of an authentication mechanism in a cluster, using LDAP authentication, should also use this type of authentication in the back-end section. This is recommended because using the same resource to authenticate sessions provides increased integrity to the whole clustering system. Because LDAP authentication can be used by both routing and non-routing services, this approach should make sense in most cluster setups.

Individual service configuration, except the authentication method, should be fairly straight-forward and easy to perform, as the services themselves are not different in any way from the services used by any other Axigen server.

Administration Tools Overview

The Axigen mail server provides several alternatives for mail server administration.

• WebAdmin

WebAdmin is a central administration Web interface that allows configuring the mailserver using a tab-organized GUI. Allowing secure access (HTTPS protocol), WebAdmin provides fully described parameters (long description, default values, possible values, suggested values). WebAdmin allows configuring the email server remotely, over the Internet and provides access to most parameters for every module. This configuration method is highly intuitive, has a fast learning curve and can be used by anyone with users-level skills.

• CLI - Command line configuration interface

CLI is a TCP service with specified dedicated socket accessible using Telnet applications and Netcat. CLI provides added functionality as, apart from providing an alternate method of performing basic configuration tasks, it allows automating administration tasks using scripts (adding users, migration).

• Delegated administration

Delegated administration enables the easy creation of administrative groups, with predetermined membership hierarchies and permissions, assigned to specific domains. Administrative users can further be created within one or more of the available groups. An administrative user will then automatically inherit the parameters of the group it is being created in. Administrative users can be assigned to one or more groups with a few mouse clicks. Membership can be limited or expanded by you at any time.

Permissions are assigned to each user through a "Quick Add" button and allow in-depth configuration. Fine-tune user access by allowing or denying permissions at server and domain management level. For example, a certain user cannot create accounts or access the WebMail service, while being able to create public folders and configure CLI service parameters.

Delegated administration options are implemented by Axigen's AACL module, which comes with a distinct storage that handles permissions for all administrative users.

• Config file

The configuration file allows you to perform extensive configuration by manually editing this text file - axigen.cfg. This administration method allows fine tuning the server functioning to existing hardware configuration and mailing requirements. Experienced System Administrators have a readily accessible method of setting both basic and very advanced parameters directly, without going through an administration interface.