My-Tiny.Net :: Networking with Virtual Machines

Using the Submission Port (587)

---

Before moving on there is one more configuration change to take note of: using port 587.

RFC 2476 + RFC 4409 defines the difference between mail transfer and message submission:



In the formal jargon of Three-Letter Acronyms (TLA), our mail client is called the Mail User Agent (MUA), the first mail server is called the Mail Submission Agent (MSA), the destination mail server is called the Mail Delivery Agent (MDA) or the Local Delivery Agent (LDA), any other mail server in between the MSA and the LDA is a Mail Transport Agent (MTA), and the service we call to access our mail messages is the Mail Access Agent (MAA).

So, in our setup, SquirrelMail is the MUA; postfix on the Gateway is a MTA; postfix on the Mailserver is the MSA when it receives mail from SquirrelMail and the MDA when it receives mail from postfix on the Gateway; dovecot on the MailServer is the LDA (called by postfix for putting messages in mailboxes) and the MAA (imap server).

The basic idea of RFC 2476 + RFC 4409 is that administrators can run distinct services configured optimally for each purpose rather than a single MTA service that has to make allowances for different types of use. MTAs are supposed to be neutral, moving mail messages as quickly as possible without worrying too much about the content, source, or destination. To make this work in an era of spam and malicious attachments, MSAs are responsible for deciding if mail should get into the system, and MDAs are responsible for deciding if the intended recipient should actually see the message.

In practice, this means that MTAs may negotiate but cannot require encryption, while MSAs and MDAs may require encryption; MTAs may require authentication in a basic form, while MSAs and MDAs should require authentication. In addition, MSAs and MDAs should be filtering messages according to local rules about acceptable source and destination addresses, attachments, etc. so the MTAs can shuffle messages from source to destination as quickly as they can.

In our setup, we will not do filtering on content, attachments, etc. because there are too many ways to do these things, and every solution has to be tailored to a specific "Acceptable Use Policy". The configuration directives for using native postfix capabilities for negotiation between MTAs are in /etc/postfix/master.cf if you want to see how to do it, although we won't really use it. Similarly, there are some basic source and destination filtering rules in /etc/postfix/main.cf on the MailServer and the Gateway, but they just write messages to the logfile because they are tagged warn.

What we will do is require encryption on the submission port, even though postfix doesn't know it. Again, the configuration directives for using native postfix capabilities for SSL/TLS are there (Dovecot and openLDAP also have them in their configuration files), but we will be using stunnel for SSL/TLS because it is so much simpler.

You can confirm that both the Gateway and the MailServer are set up to listen to port 587 [submission] with netstat -4tulpn and by checking /etc/postfix/master.cf.

You can confirm that Squirrelmail will submit mail to the Gateway on port 587 by checking the $smtpServerAddress and $smtpPort in /var/www/squirrelmail/config/svr_adrs.php.

/**
 * Your SMTP server (usually the same as the IMAP server).
 * @global string $smtpServerAddress
 */

// for initial testing
$smtpServerAddress = 'gw.tinynet.edu';
// for stunnel
# $smtpServerAddress = 'localhost';

/**
 * Your SMTP port number (usually 25 or 587).
 * @global integer $smtpPort
 */
$smtpPort = 587;

The alternative setting for the server address is for using stunnel to grab the message and encrypt it before sending it to the Gateway on the Secure SMTP port (smtps, 465) : check the Service-level configuration setting down at the bottom of /etc/stunnel/??.services.conf (where ?? is different for each of our servers).

SASL

That leaves just one small gap in our the implementation of our security policy: authentication. Spammers hunt the Internet for open relays - email systems that will re-transmit their spam to arbitrary addresses. If you don't restrict your email system, it will be easily discovered and soon used to send out large volumes of commercial or other offensive email. You will receive many complaints, and ultimately your address will find its way onto blacklists so your legitimate users no longer receive their mail.

MTAs are supposed to be neutral, moving mail messages as quickly as possible without worrying about the content, source, or destination. To make this work in an era of spam and malicious attachments, the standards specify that MTAs may require authentication in a basic form. Server-to-Server authentication is the most obvious general mechanism for restricting access to an email relay, exactly as in the case of other restricted network services.

That being said, server-to-server authentication is not a core concern for our TinyNet.

Both postfix and openldap rely on the RFC 4422 "Simple Authentication and Security Layer" (SASL) for server authentication. An excellent reference for understanding how it works is "Surviving Cyrus SASL", from http://postfix.state-of-mind.de/patrick.koetter/surviving_cyrus_sasl.pdf.

The complete (but not so easy to apply) set of instructions is at http://www.postfix.org/SASL_README.html
Two other good references are:
https://www.cyrusimap.org/docs/cyrus-sasl/2.1.23/components.php
https://www.cyrusimap.org/docs/cyrus-sasl/2.1.23/sysadmin.php

Dovecot has its own SASL implementation that can be used with postfix (but not openldap) - see
https://doc.dovecot.org/configuration_manual/howto/postfix_and_dovecot_sasl/

---

---