The theoretical minimum for the mail administrator. Configuring mail on the Communigate Pro server

This article provides basic information you need to know in order to begin administering your mail server, some of the text (~ 30%) concerns standard protocols, or widely used practices, and therefore relevant not only for Communigate Pro .

Admin panel
Create accounts

We continue the setting from the place where we stopped in the previous article . We have already installed the server and selected the name of the main domain. It is time to get users. Go to the Users-> Domains admin page and select the main domain:
')


There are already 2 service users in the domain - postmaster is the main administrator and pbx is the technical account on behalf of and with the settings of which the voice applications installed are started by default (we will tell more about voice functions in the following articles)

It is easy to create a new user - enter a name, for example recipient, in the text field next to the “Create account” button and click on it. You will open the new user settings page where you can enter the password for the account - the “Communigate password” field:

Reception

This is the most time-consuming setup of the mail section, primarily due to the fight against spam. On the one hand, we don’t want to receive unnecessary letters (so as not to chase too many letters through the lexical spam filter, if there is one, and simply don’t load the server once again with garbage), on the other hand, we don’t want to deny normal senders.

DNS

Although we can already accept emails in newly created accounts, it will be necessary to use the IP address in the domain part of the recipient's name. This is quite inconvenient for users, so all mail protocols use DNS.

The main protocol for mail delivery is SMTP, it is used both between servers and from client to server (but not vice versa).
At the same time, the process of delivering a letter from the mail client to the server for sending further we will call the registration (submission) of the letter, and the process of delivering the letter to the addressee (in the case of SMTP, the addressees are on other servers).

For the full operation of this protocol, DNS records of type MX are necessary. They contain three fields - the name of the mail domain, the priority and the name of the server serving the domain. A type A DNS record must exist for each server name.

The entry with the highest priority is considered the primary mail server, and the rest is backup servers.

For example:

>nslookup -type=MX google.com google.com MX preference = 50, mail exchanger = alt4.aspmx.l.google.com google.com MX preference = 10, mail exchanger = aspmx.l.google.com google.com MX preference = 20, mail exchanger = alt1.aspmx.l.google.com google.com MX preference = 30, mail exchanger = alt2.aspmx.l.google.com google.com MX preference = 40, mail exchanger = alt3.aspmx.l.google.com aspmx.l.google.com internet address = 74.125.143.26 alt1.aspmx.l.google.com internet address = 173.194.64.26 alt2.aspmx.l.google.com internet address = 74.125.142.26 alt3.aspmx.l.google.com internet address = 74.125.140.26 alt4.aspmx.l.google.com internet address = 173.194.74.26 

Client IPs (Client IPs)

In Communigate Pro, there is the concept of Client Addresses. In essence, these are trusted IP addresses - they usually have a number of privileges as compared to regular ones, and in some settings responsible for security, you can select the values ​​“only for clients” and “for all but clients”.

In the CGPro admin area, client addresses are specified by the “address list” type field; this field type is actively used in other settings (the Setting-> Network-> Client IPs page):

Listeners

Each protocol for which Communigate Pro is able to accept connections has its own list of receivers (server objects creating sockets), for example, SMTP (Settings-> Mail-> SMTP-> Receiving-> “Listener”):



Each receiver opens sockets on a specific port and a specific IP address (this is necessary so that CGPro can stand on one machine, with a Web server — the web server occupies the 80th port on one IP, and CGPro on the other).

By default, only port 25 is configured in the SMTP module, we will immediately add 2 more, which are set according to the standard:

In the modern version of SMTP, port 25 is intended mainly for servers, but clients should use 587, its difference in the mandatory use of authentication through the SMTP AUTH command.

Protection

There are many protocols besides SMTP that allow registering a letter on the server, but all of them work with authentication on behalf of one of the accounts. SMTP in some cases can not afford such luxury, as it is designed to receive letters from arbitrary servers.

Because of this, there are a number of measures that must be taken in order to make life a little more difficult for spammers.

Relaying

Relaying is the reception of a letter by the server, for forwarding it to the addressee.

SMTP basically allows you to register emails destined for third-party servers, but in practice it’s better to close this option for all senders except trusted ones, since if you allow forwarding to someone else’s servers from an IP address under the control of spammers, the administrators of these servers will most likely block all emails from you .

Relay settings are located on the <nobr /> Settings-> Mail-> SMTP-> Relaying page and the default values ​​are quite optimal:

The main thing is not to change them by accident or without a specific reason.

Header Checks

The main headers when receiving SMTP emails are the sender and recipient. Consider an example of an SMTP session:

 220 mycgpro.com ESMTP CommuniGate Pro 6.0.4 is glad to see you! helo 250 mycgpro.com domain name should be qualified Mail from:sender@gmail.com 250 sender@gmail.com sender accepted rcpt to: recipient@mycgpro.com 250 recipient@mycgpro.com will leave the Internet data: 354 Enter mail, end with "." on a line by itself From: Name That Everybody See <tvoya@mama.com> Tra ta ta Prishli mne deneg na telephon! . 250 90001 message accepted for delivery 

Here the sender is specified by the MAIL FROM command, and the receiver is RCPT TO. The most important thing that the administrator should know is that the field that is shown by all mail clients as “From whom” (the “From” header in the letter) is in fact not the sender, but simply a part of the message body. Most header checks (including the popular Remote BlackLists) work with the sender set by the protocol team, but they have no idea about the body of the letter. In MIME format, the sender has the “Return-path” field.


(Letter received in SMTP session given above in MIME format and interface)

The essence of the “Return-path” checks is that when the Mail From command is received, the server retrieves the domain part of the address and checks for the presence of this domain in the DNS. There is also an enhanced version of this check - Reverse Connect; when using this check, CGPro connects to the sender's server and checks whether this server accepts letters to the sender with the name from the Mail From command.

A quite popular Return-path check is SPF check. It requires DNS TXT records of a special format, these records are called SPF records. They contain the name of the mail domain and a list of IP addresses that are legitimate senders of letters with this domain part. For example:

 >nslookup -type=TXT google.com google.com text = "v=spf1 include:_spf.google.com ip4:216.73.93.70/31 ip4:216.73.93.72/31~all" 

The main disadvantage of this method is that it works only with senders whose server administrators know and use this check. In WebAdmin, mail reception settings are collected on one page Settings-> Mail-> SMTP-> Receiving:



RBL and the usual blacklist will not be considered as these types of checks are fairly well known (mainly due to the fact that many people from Russia and the CIS regularly find themselves in them) and there should be no difficulty in setting up.

Letter processing

When receiving a letter, it immediately begins to be recorded on the hard disk in the Queue folder of the base directory with the extension .tmp. As soon as the receiving process is completed, the extension is changed to .msg and the module that received the letter puts it in a common queue.

When a server is suddenly restarted or the server is disconnected, the messages from the queue (.msg files of the Queue folder) are simply put into it again.

Queue

In queues, letters registered with one module are waiting for delivery to other modules and / or to user boxes.

The following events occur in line with the letter:

• Analysis and conversion of the recipient's address.
• We apply server-wide rules.
• Queue file placed in one or more logical queues (depending on which modules are the recipients of the letter)
• Apply domain or user rules
• Processing letters in recipient modules.

Router

Whenever Communigate Pro encounters email addresses, it passes it through the Router module. The administrator, in addition to supporting letter routing management tools (such as rules, domain aliases, and users), has a powerful tool that provides convenient access directly to the address processing process — the routing table:



The format of each row in this table is:

[relay prefix:] [record type prefix:] left = right [; comment]

The table works in the following way: records are viewed one at a time, starting from the top one, if the next one could be used for address translation, then the new address is sent to the routing module from the very beginning.

By default, entries in the table work for addresses encountered in all operations and server functions. An entry can also work only for one of 3 types of operations if it is marked with the appropriate prefix - “Mail”, “Access” and “Signal”.

There is another type of prefix - “Relay”. If a record with such a prefix worked for some recipient, the letter receives a special note and it will be sent regardless of whether it came from a trusted source (from the client IP or from an authenticated user) or not. This is a rather dangerous setting, as it allows spammers to send emails to the server to which you should redirect without difficulty.

Logical queues

There are 4 types of queues for sending emails - to other servers (SMTP), to local mailboxes (LOCAL), to third-party programs ( PIPE ) and to mailing lists (LIST).

Each of these queues is divided into several others. For example, there is an SMTP queue for each domain - the recipient, and there is a LOCAL queue for each account. This allows you to deliver letters in large chunks - in many letters for one connection or opening a mailbox.

rules

The rules are applied in two approaches - at the beginning of the Server rules to all letters (prior to delivery queue), and then Domain and User rules, but only for letters from the queue of local LOCAL mailboxes. From the point of view of the internal structure, domain rules are absolutely indistinguishable from the Users rules, but they apply to all domain accounts.

Such a system for applying rules means that Domain and User rules can only affect incoming emails (outgoing emails do not fall into the LOCAL queue). That is, only Server rules are suitable for performing any manipulations on outgoing emails.

Receiving boxes

As in the case of sending, there are a lot of protocols by which you can get the contents of the boxes stored on the server POP, IMAP, XIMSS, HTTP (AirSync, WebUser). But getting mailboxes almost always involves authenticating the client requesting information.

There are no special settings for these protocols - everything should work right out of the box.

The username in the client settings is desirable to specify fully, including the domain part (if your client, like some versions of Outlook, automatically cuts the domain part by the '@' symbol, you can use '%' instead of it).

Summing up

We looked at the most important settings that a novice mail admin is facing on Communigate Pro. In this article there is a slight bias in the direction of registration settings and sending letters, this is due to the fact that such extensive topics as Router and Rules are difficult to fit into the framework of a small article. We recommend to get acquainted with them additionally in the online manual:

Router eng \ rus
Rules eng1 , eng2 \ rus1 , rus2