The theoretical minimum for the mail administrator. Setting up mail on the Communigate Pro server
- Tutorial
This article provides basic information that you need to know to start administering your mail server, some text (~ 30%) refers to standard protocols or commonly used practices, and therefore is relevant not only for Communigate Pro .
Admin
Create Accounts
We continue the setup from where we left off in the previous article . We have already installed the server and selected the name of the main domain. It’s time to get users started. We go to the
There are already 2 service users in the domain - postmaster - the main administrator and pbx - the technical account on behalf of which the default voice applications are launched (we will tell you more about voice functions in the following articles)
Creating a new user is easy - enter a name, for example, recipient in the text box next to the Create account button and click on it. Your new user’s settings page will open, where you can enter the password for the account - the “Communigate password” field:
Reception
This is the most time-consuming mail section to configure, this is primarily due to the fight against spam. On the one hand, we don’t want to accept unnecessary emails (in order not to send too many emails through the lexical spam filter, if there is one, and just do not load the server with garbage again), on the other hand, we don’t want to refuse normal senders.
DNS
Although we can already accept letters to the 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).
In this case, 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 sending is the process of delivering the letter to the addressee (in the case of SMTP, the addresses are on other servers).
For the full operation of this protocol, DNS records of the MX type are required. They contain three fields - the name of the mail domain, priority, and the name of the server serving the domain. A DNS record of type A must exist for each server name.
The record with the highest priority is considered the main mail server, and the rest are backup servers.
For instance:
>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)
Communigate Pro has the concept of Client Addresses. In fact, these are trusted IP addresses - they usually have a number of privileges compared to ordinary ones and in some settings responsible for security you can choose the values “only for clients” and “for everyone except clients”.
In the CGPro admin panel, client addresses are set by the “address list” field, this type of field is also actively used in other settings (the Setting-> Network-> Client IPs page):
Receivers
Each protocol for which Communigate Pro can accept connections has its own list of receivers (server objects that create 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 the same machine, with a Web server - the web server occupies the 80th port on one IP, and CGPro on the other).
By default, only the 25th port is configured in the SMTP module, add just 2 more, set by default:
In the modern version of SMTP, port 25 is intended mainly for servers, while clients should use the 587th, its difference in the mandatory use of authentication through the SMTP AUTH command.
Protection
There are many protocols in addition to SMTP that allow you to register a letter on the server, but they all work with authentication on behalf of one of the accounts. SMTP in some cases cannot 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 to at least slightly complicate the life of spammers.
Relaying
Relaying is the receipt of a letter by the server to forward it further to the addressee.
SMTP, in principle, allows you to register emails intended for third-party servers, but in practice it’s better to close this option for all senders except trusted ones, since if you allow sending to other servers from an IP address under the control of spammers, the administrators of these servers will most likely block all letters from you .
The relay settings are located on the
The main thing is not to change them accidentally or without a specific reason.
Header Checks
The main headers when receiving SMTP letters are the sender and the 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
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 displayed by all mail clients as “From whom” (the “From” heading in the letter) is actually not a sender, but simply part of the body of the message. Most of the header checks (including the popular Remote BlackLists) work specifically with the sender of the protocol command set, but they have no idea about the body of the message. In MIME format, the “Return-path” field corresponds to the sender.
(The letter received in the SMTP session of the above in MIME format and interface)
The essence of the “Return-path” checks is that upon receipt of the Mail From command, the server retrieves the domain part of the address and checks for the presence of this domain in DNS. There is also an enhanced version of this check - Reverse Connect, when using this check, CGPro connects to the sender server and checks whether this server accepts letters for the sender with the name from the Mail From command.
A fairly popular Return-path check is the SPF check. It requires DNS records of the TXT type in 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 instance:
>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 only works with senders whose server administrators know and use this check. In WebAdmin, mail reception settings are collected on one page
RBL and the usual blacklist will not be considered as these types of checks are quite well-known (mainly due to the fact that many people from Russia and the CIS regularly find themselves in them) and there should not be any difficulties in setting up.
Letter processing
Upon receipt of the letter, it immediately begins to be written to the hard drive in the Queue folder of the base directory with the extension .tmp. As soon as the receiving process is completed, the extension changes to .msg and the module that received the message puts it in the general queue.
In case of a sudden reboot or shutdown of the server, letters from the queue (.msg files of the Queue folder) are simply put into it again.
Queue
In queues, letters registered by one module are waiting for delivery to other modules and / or to user boxes.
The following events occur in the message queue:
- Analysis and translation of the recipient address.
- We apply server-wide rules.
- The queue file is placed in one or more logical queues (depending on which modules are the message recipients)
- Apply domain or user rules
- Processing letters in recipient modules.
Router
Each time Communigate Pro encounters an email address, it passes it through the Router module. The administrator, in addition to auxiliary tools for managing message routing (such as rules, domain and user aliases), has a powerful tool that provides convenient access directly to the address processing process - routing table:
format of each line in this table:
[relay prefix:] [type prefix entries:] left = right [; Comment]
The working table of the table is as follows - records are viewed one at a time, starting from the top, if the next one was used to convert the address, the new address is fed to the input to the routing module from the very beginning.
By default, entries in the table work for addresses found in all server operations and functions. Recording can also work only for one of 3 types of operations if it is marked with the corresponding prefix - “Mail”, “Access” and “Signal”.
There is another type of prefix - “Relay”. If a record with such a prefix has worked for some recipient, the letter receives a special mark and it will be sent regardless of whether it came from a trusted source (from a client IP or from an authenticated user) or not. This is a rather dangerous setting, as it allows spammers to freely send letters to the server to which you are redirected.
Logical queues
There are 4 types of queues for sending letters - to other servers (SMTP), to local mailboxes (LOCAL), to third-party programs ( PIPE ) and to mailing lists (LIST).
Each of these lines is divided into several others. For example, there is an SMTP queue for each recipient domain, and there is a LOCAL queue for each account. This allows you to deliver letters in large portions - many letters in one connection or opening a mailbox.
rules
The rules are applied in two approaches - at the beginning the Server rules for all letters (before being placed in the delivery queue), and then the Domain and User rules, but only for letters from the local LOCAL mailbox queue. Domain rules from the point of view of the internal device are absolutely indistinguishable from the rules of Users, but apply to all domain accounts.
Such a system of applying rules means that Domain and User rules can only affect incoming messages (outgoing messages do not fall into the LOCAL queue). That is, only Server rules are suitable for performing any manipulations on outgoing messages.
Receiving Boxes
As in the case of sending, there are a lot of protocols by which you can get the contents of the mailboxes stored on the POP, IMAP, XIMSS, HTTP server (AirSync, WebUser). But receiving boxes almost always involves authenticating the client requesting the information.
These protocols do not have any special settings - everything should work right away out of the box.
It is advisable to specify the user name in the client settings completely, including the domain part (if your client, like some versions of Outlook, automatically cuts off the domain part by the '@' symbol, you can use '%' instead).
To summarize
We examined the most important settings that a novice mail administrator at Communigate Pro encounters. This article has a slight bias towards the settings for registering and sending letters, this is due to the fact that such extensive topics as Router and Rules are hard to fit into the framework of a small article. We recommend that you familiarize yourself with them additionally in the online manual:
Router eng \ rus
Rules eng1 , eng2 \ rus1 , rus2