Post office. Linux tuning basics
When novice system administrators are faced with the need to configure the mail server, they may have difficulty with understanding the basic principles of the mail mechanism. To clarify, I prepared this article, based on the coverage of those moments that were incomprehensible to me at one time. The article is also suitable for software developers who need to quickly raise the mail server and test their application.
So, before rushing to set up your mail server, you need to understand how mail works in principle.
Literally on the fingers, consider an example. Suppose we have an external static ip - 195.195.122.129 and our own mail server, the domain name of example.ru is registered. When someone sends mail to a postal address, for example, thedude@example.ru, then, sooner or later, a request regarding what ip to send mail to a person with an address on the example.ru domain (that is, a dns request), comes to the dns-server, where the mx-records with the example.ru details are stored, that is to say, it is even simpler - this dns-server responds according to this record that the mail going to example.ru needs to be redirected to 195.195.122.129. And when the letter comes to our server, we already process it ourselves. We will process the received letter using the Message Transport Agent (hereinafter referred to as MTA). Under MTA, we will mean a program that can:
1. To forward letters from the user mail client (Mail User Agent, further MUA), to a remote mail server. MTA forwards emails using the Simple Mail Transfer Protocol (SMTP). Examples of MUA include Mozilla Thunderbird, MS Outlook, etc.
')
2. Deliver letters to local mailboxes (note that here are meant the mailboxes on the server, and not on the users' local computers).
3. Forward emails to other MTAs.
In this article, we will look at Postfix MTA. It is easy to configure, which allows you to focus on the content, not on the form. Below are the main parameters of the main configuration file - main.cf. For example, in openSUSE, this file is located in the / etc / postfix directory. You can change the parameter values ​​to suit your needs.
1. queue_directory = / var / spool / postfix
In the process of receiving and receiving mail, letters may be in a different state. Some have just been sent for shipment, others have already been received and the user just has to pick them up, and the third one is completely frozen because the manager who sent the letter was after hardcore drinking and could not clearly dictate his email, so the mail cannot reach addressee. For each of the groups of letters having the same status, there are separate directories that will be contained exactly where indicated in the queue_directory parameter.
2. mail_owner = postfix
The fact is that it will be bad if the Postfix daemon spins in superuser mode, so when installing Postfix, a new user is created with the name postfix, which will be the owner of this process.
3. myhostname = mail.example.ru
Here we set the fully qualified domain name of our host. This name will be indicated in operations performed on the SMTP protocol, in particular, in the HELO greeting. In principle, this parameter may be absent if the next parameter is specified - mydomain. You can leave the value myhostname generally empty, while setting a non-empty value for mydomain. But it’s better to set it up anyway, since some mail servers to which we send mail may swear that the myhostname value is left unknown from where it was taken and refuse to accept mail from us altogether. In any case, if we set the value of the myhostname parameter, the value of mydomain will be generated automatically based on the value of myhostname.
4. mydomain = example.ru
Here we write the name of our domain. And if we skipped the previous parameter, it will be automatically created by merging the output of the “uname -n” command, defining the name of the current host.
5. myorigin = example.ru
This parameter adds its value to the sender's address when sending mail, if it is not fully specified. For example, if mail is addressed to thedude user (it may even be mail originating from local programs on this server, for example mdadm can send a message with the text “dude, check raid arrays”), then the address, in accordance with the value myorigin = example.ru will be converted to thedude@example.ru.
6. mydestination = localhost, $ mydomain, $ myhostname, localhost. $ Mydomain
As mentioned above, one of the functions of the MTA is to receive mail from one MTA, and send it to another MTA. So, the mydestination parameter serves to ensure that mail arriving at certain addresses specified in the parameter value is not redirected somewhere, but settled on our server in local mailboxes. That is, in our case, we will receive without redirection mail with the addresses thedude@mail.example.ru, thedude@example.ru.
Yes, one more thing! It may still be incomprehensible - and how to get users on the mail server, give them passwords, that is, to exercise full control of user accounts. For example, you need to create accounts coolboy@example.ru and coolgirl@example.ru. To do this, on the mail server just need to have local users, such as useradd coolboy; passwd coolboy; (hereinafter enter the password for the cool guy) and, accordingly, useradd coolgirl; passwd coolgirl; (we will not leave the girl without a password either). We can see that users are added to the / etc / shadow file. There will be logins and password hashes.
Yes, one more thing, the useradd command immediately sets a password (the -p parameter), but unfortunately, you still have to use passwd after this, because authentication occurs using a password hash, and useradd with the -p parameter writes the password to / etc / shadow in clear text, for example, we set the password to 123456, and 123456 will be written to the file, which will be accepted by the authentication program as a password hash, as a result, the user will not receive mail with the message that the password is incorrect.
Thus, by specifying, in accordance with our needs, the above parameters, we get a workable MTA. However, this is not all. Mail came to our server. And who will distribute it to users. Or maybe they will pick it up themselves? Now we will answer these questions.
So, the procedure for users to receive letters from our server will look like this. The interaction between the mail server and the user MUA is carried out using the POP3 protocol, that is, the MUA in its avian language (POP3 commands) tells the mail server that he is not greedy and give him mail.
However, in order to hear something, you first need to listen. Is it logical That is, the server should run a daemon waiting for a request on the POP3 protocol. To do this, turn your gaze towards xinetd. Xinetd (eXtended InterNET Daemon, also called a superserver) is a service that manages network connections. Speaking even simpler, she listens to requests from the network using different protocols and she has instructions on which programs on the server to transmit what she heard. xinetd runs these programs, passing the appropriate parameters. And requests via the POP3 protocol xinetd will transmit to the POP3 server Qpopper (you must first install it). So, go to /etc/xinetd.d, open the qpopper file there and bring it to the following form:
The names of the parameters speak for themselves. Once again we realize what we have done. Compliance with the type of Internet service and its processing program (in our case, service pop3 corresponds to / usr / sbin / popper) are located in the /etc/xinetd.d directory as files that contain information about which program will process requests of a certain type / When installing, Qpopper himself created an indication that it is he who will handle pop3 requests. And we need to activate it by setting disable to no.
Now the final step is to configure MUA. You must set up in the MUA settings, a POP3 server, an SMTP server (their ip-addresses or domain names). In our case, this is the same computer, so we specify the same thing in these parameters. It is necessary to take into account that in the internal local network it is necessary to specify the ip of the network interface that is configured specifically for work with the local network. Next, specify the account name and password.
And now, when the entire postal system is working, you can optimize it, because there are still many things that can be improved and many innovations that simply ask for their introduction. Good luck!
So, before rushing to set up your mail server, you need to understand how mail works in principle.
Literally on the fingers, consider an example. Suppose we have an external static ip - 195.195.122.129 and our own mail server, the domain name of example.ru is registered. When someone sends mail to a postal address, for example, thedude@example.ru, then, sooner or later, a request regarding what ip to send mail to a person with an address on the example.ru domain (that is, a dns request), comes to the dns-server, where the mx-records with the example.ru details are stored, that is to say, it is even simpler - this dns-server responds according to this record that the mail going to example.ru needs to be redirected to 195.195.122.129. And when the letter comes to our server, we already process it ourselves. We will process the received letter using the Message Transport Agent (hereinafter referred to as MTA). Under MTA, we will mean a program that can:
1. To forward letters from the user mail client (Mail User Agent, further MUA), to a remote mail server. MTA forwards emails using the Simple Mail Transfer Protocol (SMTP). Examples of MUA include Mozilla Thunderbird, MS Outlook, etc.
')
2. Deliver letters to local mailboxes (note that here are meant the mailboxes on the server, and not on the users' local computers).
3. Forward emails to other MTAs.
In this article, we will look at Postfix MTA. It is easy to configure, which allows you to focus on the content, not on the form. Below are the main parameters of the main configuration file - main.cf. For example, in openSUSE, this file is located in the / etc / postfix directory. You can change the parameter values ​​to suit your needs.
1. queue_directory = / var / spool / postfix
In the process of receiving and receiving mail, letters may be in a different state. Some have just been sent for shipment, others have already been received and the user just has to pick them up, and the third one is completely frozen because the manager who sent the letter was after hardcore drinking and could not clearly dictate his email, so the mail cannot reach addressee. For each of the groups of letters having the same status, there are separate directories that will be contained exactly where indicated in the queue_directory parameter.
2. mail_owner = postfix
The fact is that it will be bad if the Postfix daemon spins in superuser mode, so when installing Postfix, a new user is created with the name postfix, which will be the owner of this process.
3. myhostname = mail.example.ru
Here we set the fully qualified domain name of our host. This name will be indicated in operations performed on the SMTP protocol, in particular, in the HELO greeting. In principle, this parameter may be absent if the next parameter is specified - mydomain. You can leave the value myhostname generally empty, while setting a non-empty value for mydomain. But it’s better to set it up anyway, since some mail servers to which we send mail may swear that the myhostname value is left unknown from where it was taken and refuse to accept mail from us altogether. In any case, if we set the value of the myhostname parameter, the value of mydomain will be generated automatically based on the value of myhostname.
4. mydomain = example.ru
Here we write the name of our domain. And if we skipped the previous parameter, it will be automatically created by merging the output of the “uname -n” command, defining the name of the current host.
5. myorigin = example.ru
This parameter adds its value to the sender's address when sending mail, if it is not fully specified. For example, if mail is addressed to thedude user (it may even be mail originating from local programs on this server, for example mdadm can send a message with the text “dude, check raid arrays”), then the address, in accordance with the value myorigin = example.ru will be converted to thedude@example.ru.
6. mydestination = localhost, $ mydomain, $ myhostname, localhost. $ Mydomain
As mentioned above, one of the functions of the MTA is to receive mail from one MTA, and send it to another MTA. So, the mydestination parameter serves to ensure that mail arriving at certain addresses specified in the parameter value is not redirected somewhere, but settled on our server in local mailboxes. That is, in our case, we will receive without redirection mail with the addresses thedude@mail.example.ru, thedude@example.ru.
Yes, one more thing! It may still be incomprehensible - and how to get users on the mail server, give them passwords, that is, to exercise full control of user accounts. For example, you need to create accounts coolboy@example.ru and coolgirl@example.ru. To do this, on the mail server just need to have local users, such as useradd coolboy; passwd coolboy; (hereinafter enter the password for the cool guy) and, accordingly, useradd coolgirl; passwd coolgirl; (we will not leave the girl without a password either). We can see that users are added to the / etc / shadow file. There will be logins and password hashes.
Yes, one more thing, the useradd command immediately sets a password (the -p parameter), but unfortunately, you still have to use passwd after this, because authentication occurs using a password hash, and useradd with the -p parameter writes the password to / etc / shadow in clear text, for example, we set the password to 123456, and 123456 will be written to the file, which will be accepted by the authentication program as a password hash, as a result, the user will not receive mail with the message that the password is incorrect.
Thus, by specifying, in accordance with our needs, the above parameters, we get a workable MTA. However, this is not all. Mail came to our server. And who will distribute it to users. Or maybe they will pick it up themselves? Now we will answer these questions.
So, the procedure for users to receive letters from our server will look like this. The interaction between the mail server and the user MUA is carried out using the POP3 protocol, that is, the MUA in its avian language (POP3 commands) tells the mail server that he is not greedy and give him mail.
However, in order to hear something, you first need to listen. Is it logical That is, the server should run a daemon waiting for a request on the POP3 protocol. To do this, turn your gaze towards xinetd. Xinetd (eXtended InterNET Daemon, also called a superserver) is a service that manages network connections. Speaking even simpler, she listens to requests from the network using different protocols and she has instructions on which programs on the server to transmit what she heard. xinetd runs these programs, passing the appropriate parameters. And requests via the POP3 protocol xinetd will transmit to the POP3 server Qpopper (you must first install it). So, go to /etc/xinetd.d, open the qpopper file there and bring it to the following form:
#
# qpopper - pop3 mail daemon
#
service pop3
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/popper
server_args = -s
flags = IPv4The names of the parameters speak for themselves. Once again we realize what we have done. Compliance with the type of Internet service and its processing program (in our case, service pop3 corresponds to / usr / sbin / popper) are located in the /etc/xinetd.d directory as files that contain information about which program will process requests of a certain type / When installing, Qpopper himself created an indication that it is he who will handle pop3 requests. And we need to activate it by setting disable to no.
Now the final step is to configure MUA. You must set up in the MUA settings, a POP3 server, an SMTP server (their ip-addresses or domain names). In our case, this is the same computer, so we specify the same thing in these parameters. It is necessary to take into account that in the internal local network it is necessary to specify the ip of the network interface that is configured specifically for work with the local network. Next, specify the account name and password.
And now, when the entire postal system is working, you can optimize it, because there are still many things that can be improved and many innovations that simply ask for their introduction. Good luck!
Source: https://habr.com/ru/post/143570/
All Articles