In order to build a mail server you need to own a domain (say example.org) and be able to customize its DNS records.

For each email domain you need something like this on the DNS configuration:

smtp.example.org.    IN    A           10.11.12.13
example.org.         IN    MX    10    smtp.example.org.
example.org.         IN    MX    20    smtp.example.org.
example.org.         IN    TXT         "v=spf1 mx -all"

Note: Yes, both MX records point to the same server, it is not a typo. It is done because the configuration of the server enables postscreen deep protocol tests in order to block spambots (for more details see this article). This means that the server disconnects new/unknown SMTP clients when they connect for the first time, even if they are legitimate. A legitimate client usually goes on to try the second mailserver in the list, and the second time they try to connect they are accepted.

The last line basically tells to the other SMTP servers that only this server is allowed to send emails on behalf of this domain, and no other servers. This is done to prevent spammers from faking your email addresses. If a spammer tries to send a mail as if it is coming from your domain, the SMTP server that is getting this email will consult this DNS recorda nd will figure out that the server of the spammer is not allowed to send emails on behalf of example.org.

Depending on your DNS server, DNS changes may take from a few minutes to a couple of days to propagate. You can use dig to verify that these DNS records have been activated:

$ dig MX example.org +short
10 smtp.example.org.
20 smtp.example.org.

$ dig A smtp.example.org +short
10.11.12.13

$ dig TXT example.org +short
"v=spf1 mx -all"

We need to install fist docker-scripts and wsproxy.

To increase the chances that the other mail servers take seriously the emails comming from our mailserver we have to do some extra DNS configurations. Otherwise the mails that are sent may end up being classified as spam and most probably will not reach the recipient.

For a quick automated test of the basic functionality of the server try: ds test1. Following are some tests that can be done manually.

• Send an email to check-auth@verifier.port25.com:

  swaks --server smtp.example.org -tlso \
        --from info@example.org \
        --to check-auth@verifier.port25.com
  

  The automatic reply will give you important information about the status and health of your email server (for example whether the mails sent from it pass the SPF and DKIM checks, whether they are considered spam or not, etc.)

• Go to https://www.mail-tester.com/ and send a message to the email address displayed there, like this:

  swaks --server smtp.example.org -tlso \
        --from info@example.org \
        --to test-1p4f6@mail-tester.com
  

  Then click the button for checking the score.

• There are lots of other tools and websites that help to check the configuration of a mail server (DNS settings, configuration, security features, etc.) For example:
  • https://ns.tools
  • https://mxtoolbox.com/

This smtp server can support more than one mail domains. If we want to add another mail domain, for example example.COM, we have to do these:

1. Set DNS configurations like this:

   ; mail for example.com
   smtp.example.com.   IN   CNAME    smtp.example.ORG.
   example.com.    IN    MX    10    smtp.example.com.
   example.com.    IN    MX    20    smtp.example.com.
   example.com.    IN    TXT         "v=spf1 mx -all"
   

   Note that the first record (CNAME) redirects the new smtp domain to the first one.

   You can check these DNS configurations like this:

   dig +short smtp.example.com. A
   dig +short example.com. MX
   dig +short example.com. TXT
   

2. Edit settings.sh and add the new domain on VIRTUAL_DOMAINS:

   VIRTUAL_DOMAINS="example.org example.com"
   

3. Run ds make to rebuild the container. The rebuild is needed because we need to request a new SSL cert from letsencrypt, which covers all the domains (including the new one).
4. Go to http://dmarc.postmarkapp.com/ and generate a DMARC record for the new domain.

5. Update the DNS configuration with records like these:

   mail._domainkey.example.com.  IN  TXT  "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQE....kMJdAwIDAQAB"
   
   _dmarc.example.com.           IN  TXT  "v=DMARC1; p=none; pct=100; rua=mailto:re+x2i0yw1hoq7@dmarc.postmarkapp.com; sp=none; aspf=r;"
   

   Note that:

   • The value of the key for the DKIM record can be found on the file: config/dkim-keys/example.com/mail.txt
   • The value of the DMARC record is the one obtained on the previous step.

   You can check them like this:

   dig +short mail._domainkey.example.com. TXT
   dig +short _dmarc.example.com. TXT
   

• Go to SMTP app directory: cd /var/ds/smtp.example.org/

• Edit settings.sh and uncomment the LDAP settings, giving them proper values:

  LDAP_SERVER_HOST="ldap.example.org"
  LDAP_SEARCH_BASE="ou=users,dc=example,dc=org"
  LDAP_BIND_DN="cn=mail1,ou=apps,dc=example,dc=org"
  LDAP_BIND_PW="pass123"
  

• Re-make the container: ds make

For a quick automated test of the basic functionality of the server try: ds test2. It assumes that the test users (user1@example.org, pass1) and (user2@example.org, pass2) exist on the LDAP database. They can be added like this:

cd /var/ds/ldap.example.org/
ds ou add users
ds user
ds user add users user1@example.org forward-address@mail.com pass1
ds user add users user2@example.org forward-address@mail.com pass2

We can also try the manual tests described in the following sections.

• http://acidx.net/wordpress/2014/06/installing-a-mailserver-with-postfix-dovecot-sasl-ldap-roundcube/
• https://www.vennedey.net/resources/2-LDAP-managed-mail-server-with-Postfix-and-Dovecot-for-multiple-domains

Let's assume that you have already installed docker-scripts and wsproxy from the previous sections. Follow these steps to install the WebKey container:

• Get the scripts: ds pull webkey
• Create a directory for the container: ds init webkey @wks.example.org

• Fix the settings: cd /var/ds/wks.example.org/ ; vim settings.sh. On WEBKEY_DOMAINS list the mail domains that will be supported by this container, like this:

  WEBKEY_DOMAINS="example.org example.com"
  

• Make the container: ds make
• Test it: ds play tests/test1.sh

We need to make these configurations on the mail server in order to integrate it with the WKD+WKS server:

1. First of all, we need to add a record like this on the DNS configuration of the mail server:

   openpgpkey.example.org.  IN  CNAME  wks.example.org.
   

   It is needed to tell the mail clients that the WKD of the domain example.org is served by wks.example.org. We should do the same thing for the domain example.com as well.

2. Then we should also add a WKS server with the command ds wks, like this:

   cd /var/ds/smtp.example.org/
   ds wks
   ds wks add wks.example.org 25 example.org example.com
   

   In this case we assume that the WebKey container is in the same docker network as the mail server, so we are using directly the port 25 of wks.example.org. If this was not the case, we should have used instead the port 10025, which is forwarded by docker to the port 25 of the WebKey container.

If we had to make the configurations on the second step manually (without using ds wks), we could do them like this:

1. Add a virtual alias from keys@example.org to keys@wks.example.org. It might be done like this:

   postconf 'virtual_alias_maps = hash:/host/config/virtual_alias_maps'
   
   cat << EOF >> /host/config/virtual_alias_maps
   keys@example.org  keys@wks.example.org
   EOF
   
   postmap /host/config/virtual_alias_maps
   
   postfix reload
   

   This ensures that key submission emails and submission confirmation emails are forwarded to the WKS server.

2. Tell the mailserver to send (transport) the mails for the domain wks.example.org to smtp:[wks.example.org]:10025. It may be done like this:

   postconf 'transport_maps = hash:/host/config/transport_maps'
   
   cat << EOF > /host/config/transport_maps
   wks.example.org smtp:[wks.example.org]:10025
   EOF
   
   postmap /host/config/transport_maps
   
   postfix reload
   

3. Allow the WKS server to send replies (emails) through the mailserver, without authentication, by adding its IP to the list of mynetworks. It might be done like this:

   postconf 'mynetworks = /host/config/trusted_hosts'
   
   cat << EOF >> /host/config/trusted_hosts
   12.34.56.78
   EOF
   
   postfix reload
   

4. The envelope of the emails (replies) sent from the WKS server will have a sender address like webkey@wks.example.org. This may confuse the SPF check of mail providers (in case the emails of the clients are forwarded to external addresses). As a result these emails may be considered less trusty and may end up as spam.

   To prevent this we should configure the mailserver to rewrite this address to keys@example.org. It might be done like this:

   postconf 'smtp_generic_maps = hash:/host/config/smtp_generic_maps'
   
   cat << EOF > /host/config/smtp_generic_maps
   webkey@wks.example.org keys@example.org
   EOF
   
   postmap /host/config/smtp_generic_maps
   
   postfix reload
   

For some basic testing of WKD we can use the tool gpg-wks-client:

1. Make sure that it is installed:

   apt install gpg-wks-client
   /usr/lib/gnupg/gpg-wks-client -h
   

2. Get the WKD url of the key submission address and check that it exists:

   alias wkcl='/usr/lib/gnupg/gpg-wks-client -v'
   wkcl --print-wkd-url test@example.org
   wget -qO- https://openpgpkey.example.org/.well-known/
               openpgpkey/example.org/submission-address
   submission_address=$(wget -qO- https://openpgpkey.example.org/
           .well-known/openpgpkey/example.org/submission-address)
   wkcl --print-wkd-url $submission_address
   wkcl --check test@example.org
   wkcl --check $submission_address
   

Let's assume that we want to publish the GnuPG public key for test1@example.org. We will use the command gpg-wks-client, but we also need a tool for sending emails from the command line; msmtp is a good one.

1. Make sure that msmtp is installed: apt install msmtp

2. Send a key publishing request like this:

   gpg --list-keys test1@example.org
   
   /usr/lib/gnupg/gpg-wks-client \
           --create \
           AB97233AD0EB0180882D1227799020EF6FF16876 \
           test1@example.org \
       | msmtp \
           --read-envelope-from --read-recipients \
           --tls=on --auth=on \
           --host=smtp.example.org --port=587 \
           --user=test1@example.org --passwordeval="echo pass1"
   

   The command gpg-wks-client --create creates a request email in the format that is required by the WKS, and msmtp sends it through the mailserver, with authentication.

3. Soon WKS will send as followup an email with subject Confirm your key publication. Save it as a text file: Confirm-your-key-publication.eml

4. Send the confirmation email with the command gpg-wks-client --receive, like this:

   cat Confirm-your-key-publication.eml \
       | /usr/lib/gnupg/gpg-wks-client --receive \
       | msmtp  \
           --read-envelope-from --read-recipients \
           --tls=on --auth=on \
           --host=smtp.example.org --port=587 \
           --user=test1@example.org --passwordeval="echo pass1"
   

Note: Key publishing process was automated by Thunderbird+Enigmail. However Thunderbird 78 dropped Enigmail. Its functionality is supposed to be merged to Thunderbird, but not all of it is already merged. In particular the features that facilitate and automate the interaction with a WKS server are missing. Let’s hope that they will be added back soon.