User:Paul/sandbox/Mail-in-a-Box with Namecheap and Vultr

From UNPM.org Wiki
Jump to navigation Jump to search

Configuring a mail server has never been easier than it is today with Mail-in-a-Box (MiaB), a free and open source project that automatically configures everything required to have a personal mail server.

This article covers installing MiaB using Namecheap as a registrar and Vultr as a VPS provider. It assumes an understanding of basic command line skills and establishing remote SSH sessions. For those who are new to SSH, please see the Intro to command line article.

Advantages and disadvantages

Nothing is without risk and everything has advantages and disadvantages, especially when evaluating mail servers.

Advantages

The primary advantage to having a personal mail server is the mail is only viewable to ISP admins with access to the server and the ISP customer using the server. Most ISP admins are generally unconcerned with anything that isn't criminal or damaging to their servers, as their business model does not incorporate amassing vast amounts of data to analyze and sell. (Note that is possible to serve MiaB from a local, physical computer, but that configuration is not covered in this article.)

MiaB also has the advantage of hosting nearly as many domains, email address, and aliases as desired, so users desiring different email address for different purposes can easily create one for every desired need.

MiaB includes an automated backup system that, when properly utilized, can completely restore the installation should something happen to the

Disadvantages

Disadvantages include more time required in managing the service. MiaB does do most of the heavy lifting automatically, but it is necessary to log into the server every now and then to perform some basic housekeeping.

Security comes in various forms, and while the developers of MiaB have gone to good length to provide a reasonable amount of security in the project, it is not possible to have a mail server as secure as one managed by professional administrators. This is largely due to professionals having network and firewall diagnostic tools that are beyond the scope of what is necessary for a typical personal mail server or reasonable even for enthusiasts to manage.

Time: Anyone reading this article is likely new to administrating a mail server, and there is also a good chance the same person is brand new to server administration, in general. This will mean that even with a fantastic project such as MiaB, there will be a lot to learn in order install and maintain MiaB. There is some additional time required to maintain MiaB on a weekly basis of usually not more than 20 minutes, and then every four years or so there will be a major time project of migrating MiaB to a new version of the server operating system that may require an entire weekend, though the project has been working hard to minimize the time and pain of these evolutions, as the maintainers of the project also do not like spending so much time.

Create and establish domain or domains

Where there are many domain registrars to choose from, not all domain registrars support all of the features necessary to run MiaB.

Namecheap provides all features necessary to run MiaB as standard with all domains managed by Namecheap. They also offer additional features such as free whois record privacy and a free mail forwarding service when using their free DNS service - particularly useful if a server should ever go away completely.

For domains not registered with Namecheap, transferring the domain will require purchasing an additional 12 months of registration for Namecheap to accept the domain.


Maintenance

Updates

When running an update of packages it is normal to see something similar to the following:

username@servername:~$ sudo apt-get upgrade 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
  base-files netplan.io ubuntu-server
The following packages will be upgraded:
  apport libc-bin libc-dev-bin libc6 libc6-dev locales multiarch-support
  python3-apport python3-problem-report
9 upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 9,967 kB of archives.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 

Note that it is normal for some packages to be kept back.

reboot-required

Check to see if /run/reboot-required exists:

username@servername:~$ ll /run/reboot-required
-rw-r--r-- 1 root root 32 Dec 18 07:07 /run/reboot-required

When this file is present the server should be rebooted:

username@servername:~$ sudo reboot

Ubuntu version upgrades

Ubuntu versions will be in the form of 18.04.x, 20.04.x, etc.

The server will sometimes include a message to upgrade to a newer version of Ubuntu using the do-release-upgrade or possibly other commands.

Never upgrade Ubuntu to a new version of Ubuntu in MiaB because it will break MiaB.

Replace reject_rhsbl_sender dbl.spamhaus.org with stronger spamassassin scoring

This PR removes `reject_rhsbl_sender dbl.spamhaus.org` from `main.cf` so the emails will be received by the server and adds score values to spamassassin so it always marks Spamhaus Zen blacklisted emails as spam.

I realize this is potentially a contentious PR...

In the process of adding DMARC checks, it was communicated that the project prefers receiving emails and marking them as spam to rejecting emails. In the example of DMARC, this means receiving an email even when the administrators of a domain configure their policies to instruct other admins to reject the email.

In the case of blacklists, blocking the receipt of blacklisted email is the equivalent of granting strangers the ability to control what can be received by a server, essentially creating an externally managed gateway. This could be said to be more arbitrary even than following the instructions of a domain's administrators.

More reasonable seems to be to configure MiaB to receive blacklisted emails but always send them to the spam folder.

I have been running with the Spamhaus Zen blacklist disabled for a long time (two or three years) and I have not observed an appreciable increase of spam received by the server. Initially, I ran without using any custom spamasassin rules, and in that time a total of one Spamhaus Zen blacklisted spam arrived in an inbox, as most of the blacklisted spam has so many other problems that even without special rules, spamassassin will do its job of sending the spam to the spam folder.

Typical Spamhaus Zen listed email (without custom rules):

X-Spam-Report: 
	*  3.5 BAYES_99 BODY: Bayes spam probability is 99 to 100%
	*      [score: 1.0000]
	*  0.2 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
	*      [score: 1.0000]
	*  3.3 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
	*      [212.116.113.179 listed in zen.spamhaus.org]
	*  0.1 RCVD_IN_SBL RBL: Received via a relay in Spamhaus SBL
	*  0.1 URIBL_CSS_A Contains URL's A record listed in the Spamhaus CSS
	*      blocklist
	*      [URIs: s18.pandaoo.ru]
	*  0.1 URIBL_SBL_A Contains URL's A record listed in the Spamhaus SBL
	*      blocklist
	*      [URIs: s18.pandaoo.ru]
	*  1.6 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL
	*      blocklist
	*      [URIs: s18.pandaoo.ru]
	*  0.1 URIBL_CSS Contains an URL's NS IP listed in the Spamhaus CSS
	*      blocklist
	*      [URIs: s18.pandaoo.ru]
	*  2.5 URIBL_DBL_SPAM Contains a spam URL listed in the Spamhaus DBL
	*      blocklist
	*      [URIs: pandaoo.ru]
	*  1.7 URIBL_BLACK Contains an URL listed in the URIBL blacklist
	*      [URIs: pandaoo.ru]
	* -0.1 DMARC_PASS DMARC check passed
	* -0.1 SPF_PASS SPF check passed
	*  0.0 RCVD_IN_MSPIKE_L3 RBL: Low reputation (-3)
	*      [212.116.113.179 listed in bl.mailspike.net]
	* -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
	*  0.0 HTML_MESSAGE BODY: HTML included in message
	* -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	*      author's domain
	* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	*  0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
	*       valid
	*  1.4 PYZOR_CHECK Listed in Pyzor
	*      (https://pyzor.readthedocs.io/en/latest/)
	*  2.0 RAND_MKTG_HEADER Has partially-randomized marketing/tracking
	*      header(s)
	*  0.0 RCVD_IN_MSPIKE_BL Mailspike blacklisted
X-Spam-Score: 16.4

One time, the spamscore was below 5.0:

X-Spam-Report: 
	* -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5%
	*      [score: 0.0391]
	* -0.1 DMARC_PASS DMARC check passed
	* -0.1 SPF_PASS SPF check passed
	* -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
	*  3.3 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
	*      [109.236.88.21 listed in zen.spamhaus.org]
	*  0.1 URIBL_CSS_A Contains URL's A record listed in the Spamhaus CSS
	*      blocklist
	*      [URIs: df.nevada-land-sales.com]
	*  0.1 URIBL_CSS Contains an URL's NS IP listed in the Spamhaus CSS
	*      blocklist
	*      [URIs: df.nevada-land-sales.com]
	*  0.0 HTML_MESSAGE BODY: HTML included in message
	*  0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
	*       valid
	* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	* -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	*      author's domain
X-Spam-Score: 2.7

With the score values in this PR, the above score would have been:

X-Spam-Report: 
	* -0.5 BAYES_05 BODY: Bayes spam probability is 1 to 5%
	*      [score: 0.0391]
	* -0.1 DMARC_PASS DMARC check passed
	* -0.1 SPF_PASS SPF check passed
	* -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
	*   10 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
	*      [109.236.88.21 listed in zen.spamhaus.org]
	*   10 URIBL_CSS_A Contains URL's A record listed in the Spamhaus CSS
	*      blocklist
	*      [URIs: df.nevada-land-sales.com]
	*   10 URIBL_CSS Contains an URL's NS IP listed in the Spamhaus CSS
	*      blocklist
	*      [URIs: df.nevada-land-sales.com]
	*  0.0 HTML_MESSAGE BODY: HTML included in message
	*  0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily
	*       valid
	* -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	* -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	*      author's domain
X-Spam-Score: 29.2


The Spamhaus blacklists have caused serious problems with reputable domain owners due to their lack of transparency for blacklist removal as well as their unresponsiveness to emailed removal requests.

I personally observed this with the Dovecot mailing list and was informed by the list admin they had followed all of the published instructions to be removed from the list and had attempted to contact Spamhaus directly, but remained on the blacklist. The list admin also informed me that their server and IP address and domain (dovecot.org) had never been used for sending spam. This event is troubling as it not only demonstrates the incredible difficulty some admins experience when attempting to be removed from a Spamhaus blacklist, but also suggests the people at Spamhaus don't even know the major players in their own industry. If you want credibility with mail server admins, then unblocking one of the most popular mail server packages should rank fairly high on your list, which engenders questions of who are these people and what do they actually know about operating a mail server and why do we want them controlling who can send mail to our servers?

It has been stated elsewhere that MiaB prefers a policy of inclusion, and empowering blacklist providers to block email from being received by the server goes against this policy.


I have since added rules which should place all Spamhaus Zen blacklisted email into the spam folder, and those rules in are in this PR.

MiaB does install spamasassin with a set of rules for discovery of emails listed in various blacklists, but the spamscore penalty is not adequate to declare as spam, though usually the email will have so many things wrong with it that the spamscore will total above 5.0 most of the time: