See my previous post, Install Ubuntu, LEMP, and WordPress on an Unmanaged VPS, to learn how to set up an unmanaged VPS (virtual private server) with Ubuntu, LEMP, and WordPress. In this post, I will configure Nginx to support multiple domains (aka virtual hosts) on the VPS, get Postfix email send and receive working, and install a Mailman mailing list manager.
Note: Though I’m doing the work on a DigitalOcean VPS running Ubuntu LTS 12.04.3, the instructions may also apply to other VPS providers.
Host Another Domain
To host another domain (say mydomain2.com) on the same VPS, we need to add another Nginx server block (aka virtual host) file. Run the commands below on the server.
Note: You don’t need to input the lines that start with the pound character # below because they are comments.
sudo mkdir /var/www/mydomain2
# Create a test page.
sudo nano /var/www/mydomain2/index.html
# Input this content:
<html><body>
Welcome to mydomain2.com.
</body></html>
# Change owner to www-data (which Nginx threads run as) so Nginx can access.
sudo chown -R www-data:www-data /var/www/mydomain2
# Create a new Nginx server block by copying from existing and editing.
sudo cp /etc/nginx/sites-available/wordpress /etc/nginx/sites-available/mydomain2
sudo nano /etc/nginx/sites-available/mydomain2
# Change document root from "root /var/www/wordpress;" to:
root /var/www/mydomain2;
# Change server name from "server_name mydomain.com www.mydomain.com;" to:
server_name mydomain2.com www.mydomain2.com;
# Activate new server block by create a soft link to it.
sudo ln -s /etc/nginx/sites-available/mydomain2 /etc/nginx/sites-enabled/mydomain2
# Reload the Nginx service so changes take effect.
sudo service nginx restart
The server block files allow Nginx to match the “server_name” domain to the inbound URL and to use the matching “root” directory. When a browser connects to the VPS by IP address (and thus, doesn’t provide a domain for matching), Nginx will use the first virtual host that it loaded from the “/etc/nginx/sites-enabled/” directory (the order of which could change every time you reload Nginx).
To select a specific virtual host to load when accessed by IP address, edit the related server block file under “/etc/nginx/sites-available/” directory and add a “listen 80 default_server” statement to the top like so:
#listen 80; ## listen for ipv4; this line is default and implied
#listen [::]:80 default ipv6only=on; ## listen for ipv6
listen 80 default_server;
Note: The “listen 80 default_server;” line should only be added to one of the server block files. The behavior may be unpredictable if you add it to more than one block file.
Send Email (using Postfix)
We will install Postfix, a Mail Transfer Agent which works to route and deliver email, on the VPS to support sending and receiving mail. WordPress (and its plugins like Comment Reply Notification) uses Postfix to send emails. While we could use a more simple, send-only mail transfer agent like Sendmail, we will need Postfix later when we install Mailman (a mailing list service) which depends on it. In this section, we will configure Postfix and test the send mail function.
Before we start, we need to talk about Postfix. Postfix is very sophicated and can be configured in many different ways to receive mail. I want to suggest one way which I believe works well for many domains on a VPS. The setup I’m suggesting is to have one default local delivery domain (mydomain.com) and many virtual alias domains (mydomain2.com, etc). A local delivery domain is an endpoint domain, meaning that when mail arrives there, it is placed into the local Linux user’s mailbox. A virtual alias domain is used to route mail sent to it to a local delivery domain.
For example, if you send an email to “susan@mydomain2.com” (virtual alias domain), Postfix will route the email to “susan@mydomain.com” (local delivery domain), and then delivered the mail to the local Linux “susan” user’s inbox.
Keep the above in mind as we configure Postfix and hopefully everything will be understandable. We will go step by step and build upon our understanding. We will get the local delivery domain working first and then later, add the virtual alias domain into the mix.
Install Postfix by running these commands on the server:
sudo apt-get install postfix
# Select "Internet Site" and input our local delivery domain (mydomain.com).
# Configure Postfix to use local delivery domain.
sudo nano /etc/postfix/main.cf
# Update "myhostname = example.com" to:
myhostname = mydomain.com
# Double-check that "mydestination" includes local delivery domain:
mydestination = mydomain.com, localhost, localhost.localdomain
# Reload Postfix so changes will take effect.
sudo service postfix reload
Note: I had trouble inputting the domain name when installing Postfix and ended up with a combination of the default “localhost” and my domain name, specifically “lomydomain.com”. To fix this, I had to modify the “mydestination” value in “/etc/postfix/main.cf” and in the content of “/etc/mailname” file to be the correct domain name. The “myorigin” value in “/etc/postfix/main.cf” file references the “/etc/mailname” file.
The Postfix service should be started already and it is configured to start on boot by default. To send a test email, use the Sendmail command line (Sendmail was installed as dependency of the Postfix installation) on the server:
To: emailto@domain.com
Subject: PostFix Test Email
This is the subject of a test email sent after configuring Postfix.
# Press CTRL-D key combo to end
Note: The From email address is constructed based upon the currently logged-in Linux username and the “myorigin” value in “/etc/postfix/main.cf” (which in turn, points at the “/etc/mailname” file that contains the local delivery domain name). Thus, the From address should be “mynewuser@domain.com”).
To test the PHP send mail feature, run the following commands on the server:
sudo apt-get install php-cli
# Enable logging of PHP-CLI errors to a file
sudo nano /etc/php5/cli/php.ini
# Add this line:
error_log = /tmp/php5-cli.log
# You must use a writeable directory like /tmp.
# Open the PHP interpretive shell and call the mail() function
php -a
php > mail('emailto@domain.com', 'Subject here', 'Message body here');
php > quit
If the PHP mail function works, then most likely WordPress and its plugins should be able to send emails. To be absolutely sure, you can install the Check Email plugin to test sending an email from within WordPress.
Receive Mail (to Local Delivery Domain)
By default, Postfix is configured to deliver emails sent to “postmaster@mydomain” to the local Linux “root” user’s inbox. You can tell this from the following Postfix settings:
...
alias_maps = hash:/etc/aliases
mydestination = mydomain.com, localhost, localhost.localdomain
...
cat /etc/aliases
...
postmaster: root
In the Postfix’s “main.cf” file, the “alias_maps” value points to an email-to-local-user mapping file for the local delivery domain, and the “mydestination” value contains the default local delivery domain “mydomain.com” (ignore the localhost entries).
In the “alias_maps” file “/etc/aliases”, the “postmaster” email username is mapped to the root user’s inbox. Putting it together, any email sent to “postmaster@mydomain.com” will be delivered to the root user’s inbox.
Note: Mail can be delivered to any of the local Linux users by using their exact usernames, even though they are not listed in “alias_maps”. For example, emails sent to “root@mydomain.com” will be delivered to the local root user and emails sent to “mynewuser@mydomain.com” will be delivered to the local mynewuser user.
To receive external emails sent to the VPS, we need to open up the SMTP (Simple Mail Transfer Protocal) port in the firewall and create a DNS MX (Mail exchange) record. (Port 25 is the default SMTP port use for receiving emails.)
To open up the SMTP port, run the following commands on the server:
sudo ufw allow smtp
# Double-check by looking at the firewall status.
sudo ufw status
I used DigitalOcean’s DNS management web interface to add a MX record pointing at “@” (which is the A record that resolves to mydomain.com) and priority 10 for mydomain.com. The priority allows us to add more than one MX record and determines the order of mail servers to submit the emails to. Rather than using the highest priority 0, using priority 10 will allow me to easily add a mail server before or after this one in the future.
Note: Most websites will suggest creating a CNAME record (redirecting “mail” to “@”) for mail.mydomain.com and then configuring the MX record to point at mail.mydomain.com. This is not necessary. The most simple configuration is to just point the MX record to the A record “@” as I did above.
To see if the DNS was updated with the MX record, I ran the following test command on the server (or any Linux machine):
# technical details are returned, the most important is the ANSWER SECTION.
;; ANSWER SECTION:
mydomain.com. 1797 IN MX 10 mydomain.com.
In the above example “ANSWER SECTION”, we can see that the MX record for mydomain.com points at mydomain.com (as the mail receiving server) with priority 10 (as configured). The 1797 value is the TTL (Time to Live) setting in seconds (1797 seconds is about 29.95 minutes) which indicates how long this MX record is valid for. DNS servers which honor this TTL setting will refresh at that rate; however, some DNS servers may ignore the TTL value in favor of much longer refresh times. (The A and CNAME records also have TTL values. DigitalOcean does not allow me to customize the TTL values for any DNS record.)
If the “ANSWER SECTION” is missing from the output, then your VPS provider may not have updated its DNS servers yet. (DigitalOcean DNS servers took 20 minutes to update the MX record.) Similar to the mydomain.com’s A and CNAME record changes, you may need to wait for the MX record to propagate across the internet (most DNS servers will be updated in minutes, while some may take hours).
Also, you can use the intoDNS website to check your MX record details. Input your domain name, click on the Report button, and look for the “MX Records” section. If your domain’s MX record shows up there, you can be reasonably certain that it has propagated far enough for you to start sending emails to your domain.
Test by sending an email to “postmaster@mydomain.com” from your local mail client (or Google Mail or Yahoo Mail). To see if the mail was received, do the following on your server:
sudo more /var/spool/mail/root
# Alternatively, install the mail client to view and delete received emails.
sudo apt-get install mailutils
# Read mail sent to the local root user.
sudo mail
# type "head" to see a list of all mail subject lines.
# type a number (ex: 1) to see the mail content.
# type "del 1" to delete that mail.
# type "quit" to exit mail client.
Note: If you want to check a non-root user’s inbox, log in as that non-root user and just run “mail”, instead of “sudo mail”.
Note: According to Internet standards, all mail-capable servers should be able to receive emails sent to their “postmaster” address. While it may be overkill, I decided to create MX records and postmaster aliases for all the domains that I host on the VPS.
Receive Mail (to other Virtual Alias Domains)
Now that we know that the server can receive emails, we want to configure Postfix to support emails sent to the multiple domains hosted on the VPS. (If you want more local users than “root” and “mynewuser”, use the “adduser” command per the previous post to create new users.)
Recall our earlier discussion about how a virtual alias domain will route mail to the local delivery domain (“mydomain.com”), which will finally deliver the mail to the local user’s inbox. We will configure the additional domains like “mydomain2.com” to be virtual alias domains.
First, we need to create a mapping file that will map from the virtual alias domain to the local delivery domain. Run this command on the server to create that file:
In the “virtual” mapping file, input the following lines:
postmaster@mydomain2.com postmaster
In the first line, we are using a newer feature of Postfix to declare a virtual alias domain “mydomain2.com” by starting the line with it. (The previous, alternative method was put the virtual alias domain declarations into a “virtual_alias_domains” property in the “/etc/postfix/main.cf” file.) The rest of the first line, “IGNORE …”, is ignored. The second line indicates that mail sent to “postmaster@mydomain2.com” should be routed to “postmaster” at the local delivery domain; that is, “postmaster@mydomain.com”.
Configure Postfix to use the new virtual alias domain mapping file:
# Add a new virtual_alias_maps line:
virtual_alias_maps = hash:/etc/postfix/virtual
# Update the hash db version of /etc/postfix/virtual that Postfix uses.
sudo postmap /etc/postfix/virtual
# Reload Postfix so changes take effect.
sudo service postfix reload
Test by sending an email to the email address configured in the virtual alias mapping file; in this case, “postmaster@domain2.com”. Per the previous instruction, check the root user’s inbox by using the “sudo mail” command.
Install Mailing List Service (Mailman)
Besides supporting mailing lists, Mailman (GNU Mailing List Manager) allows mailing list administration by web interface or by sending email messages (like subscribe or unsubscribe messages).
Update: Recently (latter half of 2016), emails sent to my mailing list were not delivered to Google Mail recipients. I found the following error from Google in the ‘/var/log/mail.log’ file: “Our system has detected an unusual rate of 421-4.7.0 unsolicited mail originating from your IP address. To protect our 421-4.7.0 users from spam, mail sent from your IP address has been temporarily 421-4.7.0 rate limited.” The issue is not spam because my mailing list gets only a few emails per week. This support page suggests that Google now requires SPF+DKIM for mail relays. I decided to migrate the mailing list to Google Groups for now.
To install Mailman, run the following commands on the server:
sudo apt-get install mailman
# Create a mandatory site list named mailman
sudo newlist mailman
The “newlist” command will request the following:
equivalent) file by adding the following lines, and possibly running the
`newaliases' program:
## mailman mailing list
mailman: "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin: "|/var/lib/mailman/mail/mailman admin mailman"
...
Ignore that instruction. You don’t need to manually edit the Postfix “/etc/aliases” file. Later on, we will configure Mailman to automatically generate its own aliases file, which Postfix will read from.
Once the site wide “mailman” list is created, we can start the Mailman service by running this command:
Mailman is configured to start on boot by default. (Running “sudo service mailman status” won’t output anything useable; to see if Mailman is running, list its processes using “ps -aef | grep -i mailman” instead.)
To get Mailman’s web interface working, we will need to install FcgiWrap (Simple CGI support) so that Nginx can integrate with Mailman. FcgiWrap works similarly to how PHP-FPM (FastCGI Process Manager for PHP) was used by Nginx to pass the processing of PHP files to the PHP platform. FcgiWrap will be used by Nginx to pass the Mailman-related interface calls to Mailman.
To install FcgiWrap, run the following command on the server:
FcgiWrap will be started automatically after installation. By default, FcgiWrap is configured to start at boot time. FcgiWrap uses a unix socket file “/var/run/fcgiwrap.socket” (similar to how PHP-FPM uses “/var/run/php5-fpm.sock”) to communicate with Mailman. (Similar to Mailman, running “service fcgiwrap status” won’t output anything useable; to see if FcgiWrap is running, list its processes using “ps -aef | grep -i fcgiwrap” instead.)
Edit the Nginx server block file belonging to the domain that you want to make the Mailman web interface accessible under. For example, run this command on the server:
In the mydomain2 server block file, add the following lines to the end of the “service” section:
...
location /cgi-bin/mailman {
root /usr/lib/;
fastcgi_split_path_info (^/cgi-bin/mailman/[^/]*)(.*)$;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include /etc/nginx/fastcgi_params;
fastcgi_param PATH_INFO $fastcgi_path_info;
#fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
fastcgi_intercept_errors on;
fastcgi_pass unix:/var/run/fcgiwrap.socket;
}
location /images/mailman {
alias /usr/share/images/mailman;
}
location /pipermail {
alias /var/lib/mailman/archives/public;
autoindex on;
}
}
Note: I did two things above differently from what most websites would say to do:
- I put the “fastcgi_param SCRIPT_FILENAME …” line before “include /etc/nginx/fastcgi_params;” to avoid it getting overwritten by “fastcgi_params”; otherwise, the call to Mailman would fail with a 403 Forbidden Access error message.
- I commented out “fastcgi_param PATH_TRANSLATED …” because it is not necessary.
Reload Nginx to make the changes take effect:
You can now browse to the following Mailman administrative pages:
- http://mydomain2.com/cgi-bin/mailman/admin/mylistname – manage the “mylistname” list.
- http://mydomain2.com/cgi-bin/mailman/listinfo/mylistname – info about the “mylistname” list.
- http://mydomain2.com/pipermail – view the mailing list archives.
We still need to integrate Mailman with Postfix so that emails sent to mailing lists, especially those belonging to virtual alias domains, will be routed to Mailman by Postfix.
Edit the Mailman configuration by running this command on the server:
In the “mm_cfg.py” file, add or uncomment and modify these lines like so:
POSTFIX_STYLE_VIRTUAL_DOMAINS = ['mydomain2.com']
Mailman has the capability of generating aliases for Postfix. We will use that capability. Run these commands on the server:
sudo /usr/lib/mailman/bin/genaliases
# Make the generated files group-writeable.
sudo chmod g+w /var/lib/mailman/data/aliases*
sudo chmod g+w /var/lib/mailman/data/virtual-mailman*
Note: The “genaliases” command will generate “aliases”, “aliases.db”, “virtual-mailman”, and “virtual-mailman.db” files in the “/var/lib/mailman/data” directory.
We then add the generated Mailman aliases and virtual aliases files to the Postfix “alias_maps” and “virtual_alias_maps” properties.
To edit Postfix, run this command on the server:
In the Postfix “main.cf” file, add to the end of the “alias_maps” and “virtual_alias_maps” lines like so:
virtual_alias_maps = hash:/etc/postfix/virtual, hash:/var/lib/mailman/data/virtual-mailman
Note: The changes above will configure Postfix to read and process Mailman’s generated aliases files, in addition to its own aliases files.
Reload Postfix to have the changes take effect:
Recall earlier, I said to ignore the instructions by “newlist” to add Mailman aliases to the Postfix “/etc/aliases” file because we would do it automatically later. That is just what we did above.
Look at the Mailman’s generated “aliases” file by running this command on the server:
# STANZA START: mailman
# CREATED: Tue Mar 25 05:53:44 2014
mailman: "|/var/lib/mailman/mail/mailman post mailman"
mailman-admin: "|/var/lib/mailman/mail/mailman admin mailman"
...
# STANZA END: mailman
It should look exactly like the aliases outputted by the “newlist” command. Mailman’s generated “aliases” file is included in Postfix’s “alias_maps” and thus is processed by Postfix along with the contents of the original “/etc/aliases” file.
To test a mailing list belonging to a virtual alias domain, run these commands on the server:
sudo newlist test@mydomain2.com
# Reload Postfix to make changes take effect.
sudo service postfix reload
The “newlist” command will automatically update Mailman’s “aliases” and “virtual-mailman” aliases file with entries for “test@mydomain2.com”. However, we still need to manually reload Postfix so that Postfix will pick up the changes. (Reloading Postfix requires sudo/root access, so Mailman can’t do it automatically).
Let’s look at Mailman’s updated “aliases” and “virtual-mailman” files to see what was added (the pre-existing, generated “mailman” list aliases are omitted below):
# STANZA START: test
# CREATED: Tue Mar 25 05:56:47 2014
test: "|/var/lib/mailman/mail/mailman post test"
test-admin: "|/var/lib/mailman/mail/mailman admin test"
...
# STANZA END: test
sudo cat /var/lib/mailman/data/virtual-mailman
# STANZA START: test
# CREATED: Tue Mar 25 05:56:47 2014
test@mydomain2.com test
test-admin@mydomain2.com test-admin
...
# STANZA END: test
Recall that a virtual alias domain routes to a local delivery domain, which then delivers to an endpoint (inbox or in the case above, a program called Mailman). For example, when a mail is sent to the “test@mydomain2.com” mailing list, it is routed to “test@mydomain.com” (local delivery domain), and then passed to the “mailman post test” program, which then forwards a copy to each member of the “test” mailing list.
Note: Because all mailing lists also exist under the local delivery domain, the mailing list name must be unique across all the domains hosted on the machine.
To test, access the Mailman web interface at “http://mydomain2.com/cgi-bin/mailman/admin/test” to add members to the “test@mydomain2.com” mailing list. Then send an email to that mailing list and its members should each receive a copy.
Once, you are done testing, you can delete the list by running this command on the server:
sudo /usr/lib/mailman/bin/rmlist -a test
# Reload Postfix to make changes take effect.
sudo service postfix reload
Debugging Mail
Both Postfix and Mailman will output error messages and debug logs to:
/var/log/mail.log
At this point, my VPS is hosting several domains, I can send and receive emails, and I have mailing lists working. See my followup post, Nginx HTTPS SSL and Password-Protecting Directory, to learn how to configure Nginx to enable HTTPS SSL access and to password-protect a directory.
Most info above derived from:
- How To Set Up nginx Virtual Hosts (Server Blocks) on Ubuntu 12.04 LTS
- nginx default virtual host
- How To Install and Setup Postfix on Ubuntu 12.04
- Postfix – MX records and receiving emails
- Running Mailman On Nginx (LEMP) On Debian Squeeze/Ubuntu 11.04/11.10
- Re: SOLVED: Re: Running mailman within a domain
- 6.1.1 Integrating Postfix and Mailman