Email Server Project

Project Concluded:   Feb 25, 2023

DB Reference:   asl_mail_server

Last Updated:   September 26, 2023

Many people who have their own domain and server prefer not to manage an email server. Several free mail hostingg services for custom domains exist, but they often come with limitations such as a restricted number of mail accounts, limited storage space, or even the ads in outgoing emails.

Moreover, public service providers often prioritize "so-called" security measures. Many require a security email address and phone number for each account, and some even prompt for text verification during login. As an international worker managing multiple domain accounts, this creates significant inflexibility. While security is important, I prefer to take a more personalized approach, such as using unique, 20-byte long random passwords for each account. Additionally, the use of personal information for these security measures is often unclear and raises privacy concerns.

A email server that I have complete control is necessary in this case.

As of April 2023, the system has the following specification:

Software: Modoboa, Postfix, Dovecot, Amavisd, and Spamhaus.

Webserver: Apache 2.4 + Python

Host OS: Debian 11

Hardware: 4 Core CPU + 6G Memory Virtual Server

Reverse Proxy: Nginx

Access Point(s): HongKong 01, Beijing 01, Beijing 02, LosAngeles 01

Given the complexity of email servers, I initially explored existing solutions and tried out both iRedMail and Modoboa. Eventually, I settled on using Modoboa as a "package" manager for a prototype server.

By following various online tutorials, I was able to successfully configure MX, DKIM, DMARC, SPF, and autoconfig records for a fully functional mail server.

The next step involved configuring the network for the mail server. Unlike most other servers, a mail server does not offer much flexibility when it comes to customizing ports, and common mail ports are often blocked by internet service providers (ISPs). However, the ISP for my data center, China Unicom, does not block port 25, which is required to receive emails from other relays.

However, outgoing mail presented a problem due to the requirement for a PTR record (or reverse DNS) to be set on the IP address by the ISP in order to fight against spam, which was not practical in my situation. After conducting some research, I found the optimal solution was to use SendGrid as an outgoing proxy. The free tier of SendGrid has a limit of 100 emails per day, which is sufficient since the domain addresses are primarily used for receiving rather than sending emails. SendGrid was then configured as a relay host for Postfix.

Access the Mail

With primary mail server up and running, we need some means to access it.

To access the mail server from independent clients like Outlook, I have mapped the corresponding ports on different access points. One of these access points is located in LA, which I usually use, while the others are situated in Hong Kong and Beijing and could be utilized by other users.

In order to provide a webmail interface similar to Gmail, I configured Roundcube WebMail to sit in its own virtual machine (VM) and act as a remote mail client within the same network as the mail server. The webmail was associated with the primary domain under the "/webmail" directory, and the login page can be found here.

So far, everything runs smoothly. In the future, I am considering integrating the mail system with our existing Active Directory to enable centralized authentication. This will be part of the Single Sign On Integration Project.

Email

• [email protected]
• [email protected]