Architecture of email system

FAQ – Recommendations on the arrangement of architecture of the domain mail system and its integration with the RBL/DNSBL services.

The section is under development.

If you have suggestions or questions that should be covered in this section, please mail us to Contact .

The use of services for SPAM filtering based on the RBL/DNSBL technology is often associated with the difficulties in operation both for administrators and common users of email. Most of the problems are connected with architectural arrangement of domain mail system, which initially is built under the classical scheme, excluding the principles of RBL/DNSBL service operation.

It is important to remember that: the RBL/DNSBL service is nothing but a constantly changing ACL hosted on an external server. Check of reliability of a client is performed at the moment of his connection by IP-address. Thus, the client may receive a denial of service, up to the moment when he will be able to log in to the server, confirming his rights. To avoid such problems, it is necessary to choose and configure correctly the mail system architecture.

This section covers the most common architectural variations of mail system of the domain and methods of their integration with the RBL/DNSBL services.

Email on the hosting. (click to show/hide)

Characteristics:

Email servers are owned and administered by the hosting operator.
Email system serves the email service of a large number of domains simultaneously.
All email users are connected to the servers consistently in accordance with the recommendations of the operator.

The initial and most simple variant of a domain’s mail system arrangement. The majority of the companies passes through it.

Arch-0

Scheme "Corporate email on the hosting."

« Advantages »:

Email system of a domain is located on equipment of the hosting operator.
Sending and receiving of e-mail is uniform for all domain users and does not depend on the geographic location of the user.
The problem of SPAM for users of email of such domain is usually absent or is solved by the means and methods offered by the hosting operator with acceptable efficiency.

« Disadvantages »:

The size of a user mailbox is limited by the hosting operator, and usually is not large. This causes some users to use POP3-protocol. As a result, an email archive is not saved on the hosting, and at WEB-access to the mailbox it is not possible to review the whole history of correspondence.
The use of own tools and services for SPAM filtering is impossible. The toolkit for the domain email management depends entirely on the hosting.

Use of RBL/DNSBL service:

The use of RBL/DNSBL services is strictly regulated by the hosting. Most often, the use is not provided.
ЕEven when RBL/DNSBL services are offered, their list is usually the same for the entire email system of the hosting. The effectiveness of the proposed services is low. First of all, the use of RBL/DNSBL services shall not cause problems for the hosting clients, and only secondarily, provide SPAM filtering.

Setting of DNS domain zone:

You must specify:

MX-records that refer to the email servers of the hosting operator.
SPF-record that refers to/includes SPF-records of primary domain of the hosting operator.

As a rule, these records are entered into the zone automatically at its creation.

The more detailed description of use of RBL/DNSBL technology in complicated email systems see below.

Email server (s) is on the territory of the company. There are no external email users. (click to show/hide)

Characteristics:

All users of the mail system of the domain are located in the company's local network (LAN).
External users of the email service either connect to the company's LAN through VPN, or use WEB-access.

A dead-locked method of realization of the domain email. Companies overgrow it rapidly, and it is better to build a universal email system at once.

Arch-1

Scheme. Email servers located in the territory of the company, on the hosting of auxiliary Relay.

« Advantages »:

Mail system of the domain is located in the territory and under control of the company.
Flexible configuration of the mail system, including a variety of Anti-SPAM and Anti-Virus software.
Email server of the hosting operator is not used or is used as an auxiliary Relay for an incoming email, as well as, in some cases, for an outgoing email.
The size of the user's mailbox is determined by internal policy of the company. The server uses POP3, IMAP and WEB access to the mailbox.

« Disadvantages »:

To maintain the E-mail server an administrator(s) and technical resources (server, power, reliable communications, etc.) are required.
When using the RBL/DNSBL technology, the E-mail users out of LAN and those who are not connected to office network through the VPN can only use WEB mail. The use of SMTP protocol to send email is difficult because the majority of users are connected from dynamic addresses of different internet providers that are blocked by most of RBL/DNSBL.

Use of RBL/DNSBL service:

Using RBL/DNSBL services is trivial. It is enough to set their parameters in the appropriate email server settings.

Setting of DNS domain zone:

MX-records that refer to the company’s email servers.

If the e-mail system of the hosting supports sending of email, it can be specified as a secondary server for receiving email for a period of unavailability of email servers of the company (an emergency case).

SPF-record that indicates the domain policy with respect to email.

When using additional RELAY servers that are involved only in sending email (add. offices, sending of notifications, marketing systems, etc.), they must also be specified in the SPF-record as trusted.

For all servers that are involved in sending email, you must specify PTR records that clearly connect them to your domain.

These records are necessary for check of the reverse zone which is used in almost all modern mail systems.

The more detailed description of the use of RBL / DNSBL technology in complicated mail systems see below.

A universal architecture of the company's mail system. (click to show/hide)

Characteristics:

Geographical location of email users is not regulated or is determined by the internal policy and regulations of the company.
Email system provides a uniform access for all users of mail system of the domain, both within the local network of the company and outside it.
To access email, users can use any available software (Web, MS Outlook, Mozilla Thunderbird, etc.).

This variant of arrangement of domain mail system is the most flexible and functional.

Arch-2

Scheme. Universal architecture of mail system.

IS IMPORTANT TO UNDERSTAND that the operation of e-mail consists of three connected but separate stages:

Receiving of incoming email from email servers of other domains.

An incoming email server is responsible for receiving of email, i.e. the server specified in MX-records of DNS domain zone (on Fig. there is an MX-server).

ATTENTION: The server of incoming email should not accept direct connections of end email users of domains which are served by it.

Sending of outgoing email to users.

Sending is carried out from email client or WEB client via SMTP protocol on outgoing email server of MTA (MTA - Mail Transfer Agent), which in turn carries out its delivery to email servers of destination domains (on Fig. there is an SMTP server), as a particular case, sends it to the MX-server of the domain, and such an operation allows simplifying the domain setting, but increases the load on the MX-server..

The SMTP server, if it does not send emails to another trusted Relay (for example: to the MX server), and is engaged in delivery of emails on its own, should be specified in the SPF record of DNS domain zone, i.e., be declared as a trusted sender of email of the domain.

ATTENTION : The server of outgoing email receives direct connections of email end users and performs Relay of their mailings. It doesn’t receive and deliver incoming email for the domain.

User access to the email on the server.

Receipt and review of email is carried out through WEB / POP3 / IMAP protocols (on Fig. there is Web / IMAP / POP3 server)..

ATTENTION : If you use RBL / DNSBL services, the combination of servers of incoming and outgoing email, i.e. of MX and SMTP servers (see. fig.) – IS NOT PERMISSIBLE. All other variations of combination and separation of incoming and outgoing email servers, as well as access to mailboxes are performed at the discretion of email system administrator.

A PARTICULAR CASE: when there is a single email server, but you need make a formal separation of MX and SMTP servers.

For solving the problem, an ordinary TCP / IP Redirector (redir, tcpredir, pen, etc.) is used. The main goal is to redirect client connection to MX email server from the address that for sure will not be blocked by RBL/DNSBL services. A redirector is usually installed on email server itself or on an adjacent server (for example: Proxy).

IS IMPORTANT TO REMEMBER:

For external users, as an outgoing email server, the address and port of redirector is specified.

So if the company has few addresses, you can use the address of the principal email server, but not the standard port, such as port 2525.

If you use a secondary address, it is better to leave a standard port 25.

During sending of email, connection of external users passes through the redirector from the address which is excluded from the list of client addresses on the email server (i.e. it is not allowed to send email to external or all domains from it without authorization), but at the same time, it is not included in address ranges blocked by RBL/DNSBL services.
If a redirector is installed on the email server, then you need to take into account that most of the MTAs consider all their local addresses as trusted and not all MTAs allow changing the status of these addresses to the level which requires authorization. Thus, hasty installation of a redirector on email server can turn it into a Free Relay.