Email Servers are much harder to configure than webservers. First of all, we need to create two servers, an SMTP server for sending mail and a POP3 server for downloading received email to a user. Secondly, a complete mail service involves more than these alone. It includes setting up an MTA (Mail-Transfer-Agent) and also a means of authenticating who is authorized to use the servers.
Although there are other options, I believe that postfix is the application most frequently used to supply the SMTP server, while dovecot is the application most frequently used to supply the POP3 server. Dovecot also can be used to set up an IMAP server, which I did not do. There are a number of applications that provide the MTA: sendmail is the oldest, easiest to configure, and still under active development; exim, which was written as and frequently used as a replacement for sendmail, but whose configuration is insane; and postfix, which is the most modern and while not offering as much flexibility as one might like, is much easier to configure than exim. Postfix works well with dovecot, so long as they both are configured properly to do so. That will require a little work on your part.
To install postfix for a Debian-based OS, simply issue the command "sudo apt install postfix." The installation will presents you with the option of configuring as an Internet Site or as a SmartHost. Both have a slightly different configuration in /etc/postfix/main.cf and both can be made to work. I think that Debian requires that for the Internet Site choice, the response to the question about what the server should be should be a FQDN, or fully-qualified-domain-name. In contrast to what I previously wrote here, the FQDN entered does not have to correspond to the hostname of the machine acting as the server.
I remind both newbies and veterans alike, that the FQDN entered when setting up Postfix as an Internet Site is not a dommainname you make up, but must be a domain registered to you, usually for a fee, by an appropriate authority, usually called a domain name registrar. Before things can work, you, at some point, need to log into your account with your registrar, and add or modify your Zone DNS record so you have an A record that tells the world that your FQDN should by directed to the fixed IP address your ISP assigned to your server. There are alternative ways of accomplishing this, but if you know about them, you likely do not need any help from me.
Now let's discuss configuring postfix by hand. I strongly
recommend, in this day and age, to use only secure communication for both the
SMTP and POP3 protocols. This requires telling postfix the location of the
private key and fullchain of your security certificate by adding the following
two lines to /etc/postfix/main.cf.
smtpd_tls_key_file = /path/to/security/certificate/privkey.pem
smtpd_tls_cert_file = /path/to/security/certificate/fullchain.pem
We need also to add a few lines to /etc/postfix/main.cf to tell it how
to determine who is authorized to use the email servers and here I took a path
less-travelled. The recommended way of doing this involves using a database of
users and passwords, and Debian currently recommends using mariaDB. I
chose not to do this, not because I thought it was a bad idea, but because I
knew nothing about databases and it seemed like a poor idea, when I was
struggling to learn about servers, also to start learning about databases when
the database would have only a single entry, mine. I instead chose to use the
same authorization method used when logging into the system in the first place,
which I think is referred to as auth/PAM. To do as I did, the following lines
should be added to /etc/postfix/main.cf.
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
It then is necessary, as discussed below, also to configure dovecot to use auth/PAM.
To my knowledge, there is no reason why, in theory, userA cannot use the pop3 server on serverA to retrieve mail for userB on serverB, but to accomplish this I believe you would need to use a database solution rather than auth/PAM, since PAM just knows the passwords for users on serverA and you cannot enter usernames like someotheruser@someotherserver.
If you want to enable secure smtp, and I recommend strongly you do, you
should uncomment (by removing the leading # that starts) seven of the lines
defining smtps in /etc/postfix/master.cf so they look as follows.
smtps inet n - y
- - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_sasl_auth_enable=yes
-o smtpd_reject_unlisted_recipient=no
-o smtpd_recipient_restrictions=
-o smtpd_relay_restrictions=permit_sasl_authenticated,reject
I cannot begin to tell you what each of the above lines actually accomplishes, only that it seems to work.
Different distributions provide different ways of doing this. In some, all the configuration is accomplished in a single configuration file, etc/dovecot/dovecot.conf. In others, including Debian, the dovecot.conf file is fairly vanilla and directs the system to look for multiple configuration files in the /etc/dovecot/conf.d directory.
To install dovecot on Debian-based systems issue the command "sudo apt install dovecot-core dovecot-dev dovecot-pop3d". I did not install or configure dovecot-imapd, but you may wish to.
To configure dovecot:
In /etc/dovecot/conf.d/10-mail.conf, set first_valid_uid = 1000 and last_valid_uid = 2000. Comment out the first_valid_gid and last_valid_gid lines, and uncomment (remove the #) from "#mailbox_list_index_very_dirty_syncs = yes".
In /etc/dovecot/conf.d/10-auth.conf, where it says "auth_mechanisms = plain", I recommend changing this to "auth_mechanisms = plain login". This allows both the "AUTH PLAIN" and the older "AUTH LOGIN" protocol to be used, whereas the default allows just "AUTH PLAIN". If any of the clients you will use to contact your server require the CRAM-MD5 mechanism, also add "cram-md5" to auth_mechanisms and follow these directions. A good description of the various auth_mechanisms is found at https://www.samlogic.net/articles/smtp-commands-reference-auth.htm.
In /etc/dovecot/conf.d/auth-system.conf.ext, in the first passdb section, uncomment args = dovecot. Much further down, in the User databases section, there is the option after driver = passwd of uncommenting #[blocking=no], and #args = . If you are following my unusal way to do authentification, change "driver = passwd" to "driver = passwd-file" and set "args = /etc/passwd.dovecot". Do not uncomment "#[blocking = no]".
PAM does not like to see user root. To prevent dovecot from complaining, you need simply to copy /etc/passwd to /etc/passwd.dovecot, edit out from passwd.dovecot the root entry as well as the entries of any other users you do not want to grant authorization to.
In /etc/dovecot/conf.d/10-master.conf, go to the section Postfix
smtp-auth and uncomment the first two lines and also add the two lines below
user = postfix
group = postfix
and finally, uncomment the trailing closing bracket "}".
In /etc/dovecot/conf.d/10-ssl.conf, near the top, make sure you have ssl = yes. Correct the ssl_cert and ssl_key entries to give the correct locations for your configuration, i. e., the ones you entered in the /etc/postfix/main.cf file.
One suggestion that may be helpful, but does not have to be followed is to edit /etc/dovecot/conf.d/10-logging.conf and set auth_debug = yes. I found the extra debugging information logged to the log files to be helpful during the debugging phase. Afterwards I set it to "no" so that the log files were less cluttered.
Hopefully, the above configuration options should enable the postfix and dovecot services to work properly. To initiate both services immediately, enter the commands "sudo systemctl start postfix" and "sudo systemctl start dovecot". These commands will need to be repeated whenever any changes are made to the configuration files. To enable these services to start each time the system boots up, issue the commands "sudo systemctl enable postfix" and "sudo systemctl enable dovecot".
A quick reminder about ports: I thought that because computers on my network would only be communicating securely, I needed only to port-forward port 995 for POP3S and port 465 for SMTPS. I was incorrect about this. If you do not also port-forward port 25 for SMTP, postfix/dovecot will not listen for incoming Internet connections from externel servers.
There are two considerations not frequently discussed that someone hosting their own mailserver will likely be confronted with. These are 1) rDNS issues and 2) SMTP probers.
With regard to rDNS issues, there are some in the post-modern world who believe that the computing world would be better if it were dominated by large multi-national corporations and organizations. Some of these people are trying to convince the world that only corporations that can afford tens of thousands of dollars to buy their own IP addresses, should be allowed to run email servers. As summarized here, when you purchase a domain name from a domain name registrar, you receive not only authorization to use the domain name, but also authority over its domain space. Effectively this means that YOU control which ip address is reported when someone does a dns lookup of your domain. In contrast, when you you contract with an Internet Service Provider (ISP) to provide you with Internet service, THEY assign you an IP address. If you are willing to pay an additional small fee, they always will assign you the same IP address, a so-called fixed IP address. But THEY do not assign to you the authority to control what that IP address points to.
Although there is not a single RFP standard that demands it, there are some servers that refuse, in violation of existing RFPs, to forward email from servers whose forward and reverse DNS lookups are not symmetric. They demand that the domain name for your server point to your IP (which you can control through your registrar or self-run nameserver) AND that so-called reverse-DNS lookup of your IP address (which your ISP controls) point back to the domainname of your server.
There are scattered Internet reports of ISPs being willing to do this for a customer wanting to run a server, but I believe this is exceeeding rare. I, myself, have been unable to find an ISP willing to do this, with the majority of people I speak with never having heard of reverse DNS.
I have not found the problem of rDNS symmetry to be a serious impediment to runing my own low-volume email server, which I have been running with two different fixed-IPs issued by two different ISPs for close to three years now. The servers of really large corporations like ATT and Bezeq International, and even some of the blacklisting organizations, generally have mitigation procedures for servers blacklisted but not actually sending out spam.
The second less recognized problem the manager of an email server will need to confront is that of smtp-probers attempting to hack into and guess the password of the SMTP server. We have written a package of programs and bash scripts (ManagePort25Abusers) that significantly reduces the number of SMTP probers connecting to our SMTP server (from 1 - 2 thousand per month to more like one per day). We do not know of any other software doing this. We haven't made this package available via direct Internet download, but would seriously consider sharing it under the GNU GPL with a non-prober, non-spammer, who contacted the Webmaster of this site via email.
Related to this is that there have been several reports on the Internet of some he/she or it, identifying as spameri@tiscali.it, improperly interacting with peoples' servers. This entity also was interacting improperly with my server, probing for an open email relay. Some of the Internet references thought that he/she/it had an apparently infinite number of made-up IPs. If he/she/it indeed has an infinite number of ips at their disposal, it would be difficult to block them. Our blocking software, which as of mid-2024 blocked some 60+ cidrs used by spameri@tiscali.it, has reduced the number of contacts by he/she/it from the 49 times seen during the first month and a half of 2023 to more like once/month during the first half of 2024.