E-mail server hosting on Amazon EC2

In the previous post I described how to set up web hosting with HTTPS and WordPress. All those steps require less work compared to settings up a fully secured e-mail server.


For e-mail self-hosting we need postfix as a message transfer agent (MTA), dovecot for POP3 e-mail server, cyrus SASL (simple authentication security layer) for SMTP relay security, Amazon SES (simple e-mail service) for SMTP relay authority and reverse DNS lookup, SSL certificate from Let’s Encrypt described in the previous post. For more new technologies look at ThePayStubs for a business financial safety.

Base setup

  1. Install postfix, dovecot, cyrus SASL, start them and enable the correspondent services (postfix, dovecot, saslauthd), and remove sendmail.
    1. sudo yum install postfix dovecot cyrus-sasl
    2. sudo yum remove sendmail
    3. sudo yum postfix start # repeat for dovecot and saslauthd
    4. sudo chkconfig postfix on # repeat for dovecot and saslauthd
  2. Create real user with password + directory (or a virtual user with a virtual mailbox).
    1. sudo useradd admin
    2. sudo passwd admin
    3. sudo mkdir /home/admin/mail/
    4. sudo chown admin /home/admin/mail
  3. Configure postfix for basic SMTP on port 25
    1. Edit /etc/postfix/main.cf to specify
      1. myhostname=yourhostname.com
      2. mydomain=yourhostname.com
      3. inet_interfaces=all
      4. inet_protocols=all
      5. home_mailbox=mail/
      6. message_size_limit=10485760 # for 10MB
      7. mailbox_size_limit=1073741824 # for ~1GB
      8. smtpd_recipient_restrictions=permit_mynetworks, permit_auth_destinations,permit_sasl_authenticated,reject
  4. Configure dovecot for basic POP3 on port 110
    1. Edit /etc/dovecot/10-auth.conf to specify
      1. disable_plaintext_auth=no
      2. auth_mechanisms=plain login
    2. Edit /etc/dovecot/10-mail.conf to specify
      1. mail_location=maildir:~/mail
    3. Edit /etc/dovecot/10-ssl.conf to specify
      1. ssl=no
  5. Open ports 25 and 110 in EC2 security groups, restart dovecot, postfix, and check that you can send e-mail to yourself and receive it via your favorite e-mail agent (SMTP and POP3 hosts are yourhostname.com, no encryption, no SSL/TLS).

Authenticated SMTP

The above setup is the least secure. The first step for amending is to require authentication for SMTP. For that, use dovecot for SASL authentication with SMTP server (smtpd).

  1. Edit /etc/postfix/main.cf to specify
    1. smtpd_sasl_type = dovecot
    2. smtpd_sasl_path = private/auth
    3. smtpd_sasl_auth_enable = yes
    4. smtpd_sasl_security_options = noanonymous
    5. smtpd_sasl_local_domain=$myhostname
    6. broken_sasl_auth_clients=yes
    7. smtpd_sasl_authenticated_header = yes
  2. Edit /etc/dovecot/10-master.conf to specify
    1. unix_listener /var/spool/postfix/private/auth  {
    2. mode = 0666
    3. user = postfix
    4. group = postfix
    5. }
  3. In your favorite e-mail application set “My outgoing server (SMTP) requires authentication” -> “Use same settings as my incoming mail server” and test that the new set up can send and receive e-mails to self and to/from one external account.

Secure SMTP and POP3

The above setup doesn’t allow for anonymous access to the e-mail server. However, the established connections are not secure. Both POP3 and SMTP can be secured with the same SSL certificate, we used for HTTPS as long as the connection server names coincide with the domain name.

  1. Enable SMTP port 587, which makes life easier as an addressee, as many popular mailservers would prefer to send to port 587. Note that SMTP port number itself has little to do with the use of SSL.
    1. Edit /etc/postfix/master.cf and uncomment “submission inet n …” line.
  2. Configure smtpd setting to require SSL by editing /etc/postfix/main.cf:
    1. smtpd_tls_cert_file=/etc/letsencrypt/live/yourhostname.com/fullchain.pem
    2. smtpd_tls_key_file=/etc/letsencrypt/live/youthostname.com/privkey.pem
    3. smtpd_tls_security_level = encrypt # this is the main setting to require SSL
    4. smtpd_tls_loglevel = 1 # raise to 2 or 3 if you plan to dig through logs /var/log/maillog
    5. smtpd_tls_received_header=yes
  3. Configure dovecot to require SSL:
    1. Edit /etc/dovecot/conf.d/10-auth.conf to specify
      1. disable_plaintext_auth = yes
    2. Edit /etc/dovecot/conf.d/10-master.conf to specify
      1. service pop3-login { …
      2. inet_listener_pop3s {
      3. port = 995
      4. ssl = yes
      5. }
      6. }
    3. Edit /etc/dovecot/conf.d/10-ssl.conf. Mind “<” signs for ssl_cert and ssl_key.
      1. ssl = required
      2. ssl_cert=</etc/letsencrypt/live/yourhostname.com/fullchain.pem
      3. ssl_key=</etc/letsencrypt/live/yourhostname.com/privkey.pem
  4. Restart postfix and dovecot, open ports 587 and 995 on EC2 instance, configure SMTP in your client to use port 587 and “Use the following type of encrypted connection = TLS”, configure POP3 in your client to use port 995. Tests should pass.

Relay sending SMTP messages to Amazon SES.

The above SMTP and POP3 client setup looks identical to the one for Gmail, which brings the false sense that we are done. Your first e-mail from such self-hosted SMTP server to Gmail will end up in a Spam folder. I know as I tried it. The problem is that your own SMTP server doesn’t have an authority standing by it to certify that the sender is good. Amazon SES serves as such authority after you promise them you won’t be doing anything bad. In short, an e-mail from your SMTP server needs to be relayed to Amazon SES server in a correct hosting zone. Then Amazon SES provides reverse DNS lookup.

  1. Sign up with Amazon SES, verify your primary e-mail on yourhostname.com and e-mail on Gmail, obtain a correct relay host based on a hosting zone, obtain SMTP credentials, verify DKIM. Generally follow guide for integration with postfix.
  2. Configure smtp server for relay. As a rule of thumb “smtpd” server handles e-mail by itself, while “smtp” server asks someone else to handle their e-mail => we need “smtp” and many smtpd options need to be duplicated into smtp options:
    1. Edit /etc/postfix/main.cf to specify
      1. relayhost = email-smtp.us-east-1.amazonaws.com:25 # port doesn’t matter – 587 is as good as 25, the server depends on a hosting zone
      2. smtp_sasl_auth_enable = yes
      3. smtp_sasl_security_options = noanonymous
      4. smtp_tls_security_level = encrypt #outgoing connection must be secure as well
      5. smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
      6. smtp_use_tls = yes
      7. smtp_tls_note_starttls_offer = yes
      8. smtp_sasl_mechanism_filter = plain, login # essential, but not found in a official guide
      9. smtp_tls_CAfile = /etc/ssl/certs/ca-bundle.crt # we verify authenticity of Amazon SES server
      10. smtp_sasl_type = cyrus # which is the default
    2. It may come as a surprise, but dovecot doesn’t support SASL authentication for “smtp” and we have to use cyrus-sasl. One can store hashes of passwords in a file, which is simpler than the database:
      1. Ensure saslauthd service is running and is set to start automatically.
      2. Create /etc/postfix/sasl_passwd file with Amazon SES SMTP server and SMTP credentials.
      3. Run “sudo postmap hash:/etc/postfix/sasl_passwd” to generate a hash file referenced by password_maps above.
  3. Restart postfix and test sending/receiving e-mail between your 2 verified account.
  4. Apply on Amazon SES for a production account, which allows sending e-mail to unverified accounts (aka clients).

This is basically it! We now have a production e-mail system, which is fully secured and can send 50,000 high authority e-mails per day.  Dependent on the use case, you may consider forwarding incoming e-mails to Gmail.

Website self-hosting on Amazon EC2 cloud

The upcoming 3-yr renewal of website hosting plan on Hostgator and the desire to learn AWS cloud made me thinking about self-hosting of my personal website http://astroman.org.


Hostgator gradually increased regular costs of its Hatchling shared plan from $3.95/mo to $6.95/mo + the cost of the domain to $15/yr => total for a 3yr term is about $300. For a Positive SSL certificate one has to pay $50/yr + upgrade to the next tier of shared hosting plans => total cost over 3yrs readily rises to $600.
Amazon cloud prices are predictably lower. At present t2.nano EC2 instances are priced at $0.0059/Hour without a long-term commitment and at $69/3yrs = $2.9/mo for a 3 yr dedicated instance. Standard 8GiB of EBS storage go for $0.8/mo. Thus, ones beats even the most discounted pricing of Hostgator… except one has to do much more work!

Typical web hosting consists of a lot of static contents in a form of HTML pages, images, CSS + WordPress blog + e-mail. SSL support is a premium paid feature. Under the hood, web hosting implies:

  • a lot of HTML/PDF/CSS/JPEG/PHP/etc in a folder on a Linux host
  • a domain name with adequate DNS service
  • Apache web server routing to the content
  • PHP engine + MySQL database to run WordPress
  • Postfix SMTP and Dovecot POP3 servers for e-mail
  • CA-signed SSL certificate with a mechanism for certificate renewal

I aimed at replicating all those features on an EC2 instance and succeeded in about 2 weeks of working on it about 5 evenings a week.

Base setup

t2.nano EC2 instance has only 500MB memory, which prohibits installation of WHM/cPanel => more manual work. Luckily, all other software runs on such box without a hitch on a chosen Amazon AMI Linux distribution. Provisioning of EC2 instance is fairly standard, except I got a discounted dedicated instance on AWS marketplace with $2.9/mo pricing, but only a 2yr commitment. An instance should have an associated Elastic IP address, which is free for as long as an instance is running. Regardless of the domain hosting registrar, the DNS service could be provided by Amazon via Route 53 service, which offers seamless integration with other AWS services and best possible access to your domain. A hosted zone costs extra $0.5/month and I decided to pay that.

Web hosting

Amazon Linux is based on RedHat and has standard tools like yum available. However, be careful as the default versions of packages may need to be abandoned in favor of compatible versions, e.g. use httpd24 instead of httpd:

  1. Configure DNS, edit /etc/sysconfig/network set HOSTNAME=yourhostname.com and restart server “sudo reboot”.
  2. Install Apache: “sudo yum install httpd24”.
  3. Copy files to /var/www/html with the entry point file named index.html.
  4. Edit /etc/httpd/conf/httpd.conf and comment out “AddDefaultCharset UTF-8” unless you have a Unicode-compatible website.
  5. Start Apache and set the service to autostart “sudo service httpd start” and “sudo chkconfig httpd on”.

The website should now be accessible at http://yourhostname.com.


A WordPress blog can either be installed at the website root or made available at a specific URL such as http://yourhostname.com/blog. It requires PHP engine and MySQL database. Using PHP56 avoids conflicts with other versions. I migrated WordPress from a different hosting.

  1. Install PHP and MySQL
    1. sudo yum install php56-mysqlnd php56-gd php56 php56-common
      sudo yum install mysql-server mysql
  2. Start and enable autostart of “mysqld” service.
  3. Secure MySQL installation with “sudo mysql_secure_installation”, set root password etc.
  4. Connect to MySQL from command line and create a database for WordPress.
    1. mysql -u root -p password
      CREATE DATABASE wordpress;
      CREATE USER wordpressuser@localhost IDENTIFIED BY ‘password’;
      GRANT ALL PRIVILEGES ON wordpress.* TO wordpressuser@localhost IDENTIFIED BY ‘password’;
  5. On old WordPress instance install Duplicator plugin and create the archives, then copy the archives to the relevant folder in the new hosting.
  6. Access installer.php and follow the prompts to hook up to MySQL database, unpack the archive and make selections.
  7. If the website address/folder changes at a subsequent time, make necessary changes to MySQL database.
  8. Consider using TRUEedit plugin, which prevents conversion of “–” and other symbols to something non-copy-pastable.

SSL certificate

Free self-signed certificates cannot be used for anything other then testing. SSL certificates signed by trusted CA were always a paid premium feature, but not anymore. A new company Let’s Encrypt now provides free SSL certificates for anyone! The certificates are cross-signed by IdenTrust, whose Certificate Authority public key is already present in most major browsers/operating systems. Steps to get the certificate and use it with Apache:

  1. Get Let’s Encrypt project
    1. sudo yum install git
    2. sudo git clone https://github.com/letsencrypt/letsencrypt /opt/letsencrypt
  2. Obtain a certificate. Amazon Linux AMI support is experimental, but –debug flag successfully forces installation of relevant dependencies.
    1. sudo -H /opt/letsencrypt/letsencrypt-auto certonly –standalone -d astroman.org –debug
  3. The resultant 3 certificate files are referenced for Apache in /etc/httpd/conf.d/ssl.conf file as:
    1. SSLCertificateFile /etc/letsencrypt/live/yourhostname.com/cert.pem
    2. SSLCertificateKeyFile /etc/letsencrypt/live/yourhostname.com/privkey.pem
    3. SSLCertificateChainFile /etc/letsencrypt/live/yourhostname.com/fullchain.pem
  4. Include a permanent redirect to HTTPS in Apache config file /etc/httpd/conf/httpd.conf
    1. <VirtualHost *:80>
    2. ServerName yourhostname.com:80
    3. Redirect permanent / https://yourhostname.com/
    4. </VirtualHost>
  5. Allow overrides in VirtualHost on port 443 (otherwise links to individual posts will display error 404)
    1. vi /etc/httpd/conf.d/ssl.conf
    2. <Directory /var/www/html/blog>
    3. DirectoryIndex index.php
    4. AllowOverride All
    5. Order allow,deny
    6. Allow from all
    7. </Directory>
  6. Open 443 port on EC2 instance and restart Apache. All links on your website including the main page and WordPress will now by HTTPS.
  7. Set up automatic certificate renewal to run daily in root crontab and redirect output to a file to check the renewal command runs. Most of the times the renewal script will skip renewal as the certificate is not yet due – it will only renew once in 60 days.
    1. sudo crontab -e
    2. 30 2 * * * /home/ec2-user/renewal.sh
  8. renewal.sh file logs the date and attempts to renew the certificates without Apache restart and without updating dependencies
    1. sudo echo `date` >> /home/ec2-user/renew.log
    2. sudo /opt/letsencrypt/certbot-auto renew –webroot -w /var/www/html –no-bootstrap >> /home/ec2-user/renew.log