Sending / Relaying
Your mail server is almost ready for use. But one puzzle piece is missing. Your users can receive emails but they cannot send them yet. This part of the guide is a bit longer than others because forwarding emails has security implications.
Let’s begin with the difference of how users send emails versus how mail servers send emails.
- A mail server fetches the MX record for the destination domain of the recipient’s email address from DNS. That tells it which mail server to talk to. Then it opens an SMTP connection (TCP port 25) and sends the email. A mail server will not relay an email meant for someone else. It will only accept emails for its own users.
- An end user with a mail client such as Thunderbird or Roundcube cannot do that. Mail clients do not include any functionality for fetching MX records. In addition, the user is usually on a dynamic IP address that other mail servers will not trust and will likely reject. Instead, end users are expected to send their emails through their provider’s (=your) mail server: they authenticate with their login credentials and then send the message. This process is called relaying, because your mail server acts as an intermediary between the user and other mail servers on the internet. For security reasons, authentication is required before the user is allowed to send emails. Users are also expected to use the TCP port 587 which is called the submission port. More on that later.
Postfix must only accept an email from a user, if…
- The user uses the submission port (and not the standard SMTP port)
- The user authenticates with the username (in our setup: the email address) and the password
- The connection is encrypted so that the password can be safely transmitted
- The sender address of the email matches the user’s account
SMTP versus Submission
Section titled “SMTP versus Submission”Let’s compare those services and ports side-by-side:
| Service name | SMTP | Submission | SubmissionS (S=secure) |
|---|---|---|---|
| TCP Port | 25 | 587 | 465 |
| Meant for | Other mail servers | Our users | Our users |
| Used by | Mail transport agent (MTA) | Mail user agent (MUA) | Mail user agent (MUA) |
| Transport encryption | Off. STARTTLS optional. | Off. STARTTLS mandatory. | TLS all the time |
| Authentication | Optional 1 | Mandatory | Mandatory |
| Accepted sender | Anyone | Our own users | Our own users |
| Accepted receivers | Our own users | Anyone | Anyone |
| Your home ISP | may block this port | will allow this port | will allow this port |
I hope this helps clarify the distinction. Human users must use the submission service on either port 587 or 465. The key difference is that connections on port 587 start unencrypted, and the email client must issue the STARTTLS command to enable encryption. In contrast, port 465 requires the email client to use TLS encryption right from the first byte of communication.
Configure the submission[s] services
Section titled “Configure the submission[s] services”All Postfix services are declared in the /etc/postfix/master.cf file. Most of them are used by Postfix internally,
like pickup, cleanup, rewrite or bounce. But submission is not configured by default. Let’s fix that.
postconf -M submission/inet="submission inet n - y - - smtpd"postconf -P "submission/inet/syslog_name=postfix/submission"postconf -P "submission/inet/smtpd_tls_security_level=encrypt"postconf -P "submission/inet/smtpd_sasl_auth_enable=yes"postconf -P "submission/inet/smtpd_sasl_type=dovecot"postconf -P "submission/inet/smtpd_sasl_path=private/dovecot-auth"postconf -P "submission/inet/smtpd_recipient_restrictions=permit_sasl_authenticated,reject"postconf -P "submission/inet/smtpd_sender_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,reject"
postfix reloadThese commands added a submission service to the /etc/postfix/master.cf file. You could have achieved the same thing
by editing that file and adding the following section, but I wanted to make it simpler for you to just copy/paste the
commands into your shell.
submission inet n - y - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_sasl_type=dovecot -o smtpd_sasl_path=private/dovecot-auth -o smtpd_recipient_restrictions=permit_sasl_authenticated,rejectSome notes on that:
- Lines with options (
-o) need to be indented so that Postfix understands that they belong to the same service. - The word submission refers to the definition of the service in the
/etc/servicesfile. So it translates to TCP port 587. - The smtpd in the last column of the first row tells Postfix that connections should be handled as incoming SMTP connections.
- syslog_name is adding
postfix/submissionto log files so that you can distinguish it from other connections. - smtpd_tls_security_level enabled and enforces the use of STARTTLS. The connection starts without encryption but
the remote party is required to send the
STARTTLScommand to switch to an encrypted connection. - smtpd_sasl_auth_enable enables authentication on this port. SASL is short for Simple Authentication and Security Layer. That way only our own users can use this service.
- smtpd_sasl_type tells Postfix to use Dovecot’s service to authentication a uaser.
- smtpd_sasl_path tells Postfix that it should talk to Dovecot through the socket file
/var/spool/postfix/private/dovecot-auth. Earlier in this guide you told Dovecot to create that socket at that location. - smtpd_recipient_restrictions define that only authenticated connections are permitted. Without a username and a password your connection will be rejected. The recipient keyword tells us that this restricts who the recipient can be.
- smtpd_sender_restrictions restricts who the sender may be. I will explain that later.
While you are at it, create the submissions (with an “s” at the end) service as well:
postconf -M submissions/inet="submissions inet n - y - - smtpd"postconf -P "submissions/inet/syslog_name=postfix/submissions"postconf -P "submissions/inet/smtpd_tls_wrappermode=yes"postconf -P "submissions/inet/smtpd_sasl_auth_enable=yes"postconf -P "submissions/inet/smtpd_sasl_type=dovecot"postconf -P "submissions/inet/smtpd_sasl_path=private/dovecot-auth"postconf -P "submissions/inet/smtpd_recipient_restrictions=permit_sasl_authenticated,reject"postconf -P "submissions/inet/smtpd_sender_restrictions=reject_sender_login_mismatch,permit_sasl_authenticated,reject"postfix reloadThe only difference to the submission (without the “s” at the end) is the smtpd_tls_wrappermode that switches on TLS
encryption right from the start of a connection.
Set up encryption
Section titled “Set up encryption”Whenever possible we should encrypt our traffic. For our users’ passwords we make it mandatory. But even for server-to-server connections we should encourage it. Do not confuse it with end-to-end encryption of emails. That required using PGP or S/MIME. What we are dealing here is transport encryption. It encrypts the communication between a peer server and your mail server. What the peer server does with our email is beyond our control.
postconf smtp_tls_security_level=encryptpostconf smtpd_tls_security_level=encryptpostconf smtp_tls_mandatory_protocols=">=TLSv1.2"postconf smtpd_tls_mandatory_protocols=">=TLSv1.2"postconf smtp_tls_mandatory_ciphers=highpostconf smtpd_tls_mandatory_ciphers=highpostconf smtpd_tls_cert_file=/etc/letsencrypt/live/mail.example.org/fullchain.pempostconf smtpd_tls_key_file=/etc/letsencrypt/live/mail.example.org/privkey.pemWhat it means:
- smtp_tls_security_level:
Enforce encrypted outgoing SMTP connections. - smtpd_tls_security_level:
Enforce encrypted incoming SMTP connections. - smtp_tls_mandatory_protocols / smtpd_tls_mandatory_protocols:
Only allow recommended versions of TLS. Version 1.2 has been introduced 2008. Version 1.3 is from 2018. - smtp_tls_mandatory_ciphers / smtpd_tls_mandatory_ciphers:
The list of encryption algorithms that you allow for communnication. Default is medium. - smtpd_tls_cert_file and smtpd_tls_key_file:
Where to find the private key and certificate for encryption.
Please note that configuration in main.cf applies to all Postfix services. So the above configuration enabled
encryption for both server-to-server and human-to-server (submission) services. The smtpd_sasl_auth_enable will only
be set for the submission service to enable authentication there.1
Protecting against forged sender addresses
Section titled “Protecting against forged sender addresses”Before we can actually test the setup, there is another security issue we need to address. While Postfix is configured
to relay emails only after a successful login with a valid username and password, it does not prevent an authenticated
user from impersonating another sender. For example, someone could log in as john@example.org but send an email
appearing to come from brunhilde@example.net.
We should fix that. For that purpose Postfix provides a setting called smtpd_sender_login_maps. From the “maps” part you can deduce that it expects a mapping again:
- Question: who you claim to be (email’s sender address)
- Answer: who you logged in as (user name after authentiation)
If you think of it, the mapping is simple. The question must match the answer. If john@example.org wants to be the
sender, he must also authenticate as john@example.org.
As we use the email address also as a user name we simply need a mapping where the email address is listed on both sides. Let’s create it:
# Create a mapping configuration from the user to themselfcat > /etc/postfix/mariadb-email2email.cf << EOFuser = mailserverpassword = MAILSERVER-PASSWORD-HEREhosts = 127.0.0.1dbname = mailserverquery = SELECT email FROM virtual_users WHERE email='%s'EOF
# Fix permissionschown root:postfix /etc/postfix/mariadb-email2email.cfchmod u=rw,g=r,o= /etc/postfix/mariadb-email2email.cf
# Tell Postfix to use this mappingpostconf smtpd_sender_login_maps=mysql:/etc/postfix/mariadb-email2email.cfWhat you accomplished:
- Create the mapping file
- Fix the permissions of it so that only Postfix can read it (there is a password in it)
- Make Postfix use that mapping for its
smtpd_sender_login_mapssetting - Add
smtpd_sender_restrictions=reject_sender_login_mismatchto thesubmissionandsubmissionsservices
You can now try to send email as a different user than you are logged in. Let’s us swaks again to send a spoofed email:
swaks --server localhost:587 \ --from brunhilde@example.org \ --to list@example.com \ --tls \ --auth-user john@example.org \ --auth-password summersunThe server should rightfully reject that wrong sender:
~> MAIL FROM:john@example.com<~ 250 2.1.0 Ok~> RCPT TO:john@example.org<~ * 553 5.7.1 john@example.com: Sender address rejected: not owned by user john@example.orgNow let’s send a proper email from John:
swaks --server localhost:587 \ --from john@example.org \ --to list@example.com \ --tls \ --auth-user john@example.org \ --auth-password summersunThat will work:
<~ 250 2.0.0 Ok: queued as AFFF12292ATest it
Section titled “Test it”No encryption, no authentication
Section titled “No encryption, no authentication”So far you have set up the submission service(s), enabled encryption and connected Postfix to Dovecot for
authentication. Let’s try it. Our first test email will be sent without encryption and authentication:
swaks --server localhost:587 \ --from john@example.org \ --to lisa@example.comPostfix should tell you that it will not accept an email without encryption:
<** 530 5.7.0 Must issue a STARTTLS command firstWith encryption, no authentication
Section titled “With encryption, no authentication”Our second attempt will enable (STARTTLS) encryption – but still no authentication:
swaks --server localhost:587 \ --from john@example.org \ --to lisa@example.com \ -tlsPostfix will still reject the email because we refused to authenticate:
~> MAIL FROM:<john@example.org><~ 250 2.1.0 Ok ~> RCPT TO:<lisa@example.com><~* 553 5.7.1 <john@example.org>: Sender address rejected: not logged inWith encryption and authentication
Section titled “With encryption and authentication”swaks --server localhost:587 \ --from john@example.org \ --to lisa@example.com \ -tls \ --auth-user john@example.org \ --auth-password summersunAlso give the submissions service a try:
swaks --server localhost:465 \ --from john@example.org \ --to lisa@example.com \ --tls-on-connect \ --auth-user john@example.org \ --auth-password summersunDid you notice the difference? The second time we used port 465 and instead of the -tls option (which uses
STARTTLS to switch to encryption) we use --tls-on-connect that uses TLS right from from the start.
Put simply, a mail server will accept an email if…
- it is responsible for handling mail for the recipient’s domain (the domain is listed as a virtual domain), or
- the sender has authenticated successfully with a valid username and password.
I have created two illustrations to explain it.
Gory details of authentication
Section titled “Gory details of authentication”telnet localhost submissionThe server will let you in:
Trying 127.0.0.1…Connected to localhost.Escape character is '^]'.220 webmail ESMTP Postfix (Debian)Say hello:
ehlo example.comPostfix will present a list of features that are available for you:
250-mailtest250-PIPELINING250-SIZE 10240000250-VRFY250-ETRN250-STARTTLS250-ENHANCEDSTATUSCODES250-8BITMIME250-DSN250-SMTPUTF8250 CHUNKINGLet me briefly explain what these lines mean:
- PIPELINING
This is a feature to speed up SMTP communication. Usually the remote system has to wait for a response to every command it sends. Pipelining allows the remote server to send several commands in a batch without waiting for a response. Postfix will just store these commands and execute them one by one. If you told Postfix to forbid pipelining it would disconnect the remote server when it tries to send bulks of commands without waiting for the proper reply. It is mainly a feature against rogue senders. - SIZE 10240000
The remote server is allowed to send emails up to 10 MB large. This has long been a common maximum size for emails. However nowadays 40 MB or even more are more common sizes because emails have grown larger. Some mail servers even allow 100 MB. - VRFY
Allows remote servers to verify a given name or email address. For example the remote server could send “VRFY john” and your server might respond250 Jo You can skip it for now.hn Doe <john@example.org>. It can be used to verify that a certain recipient email address is deliverable - ETRN
A command that a remote system can send to flush the Postfix queue of mails for a certain domain. It can be used if the remote system had technical problems and failed to receive email for a while. Then it could send an ETRN command to make your server start sending outstanding emails for that domain. It is rarely used. - STARTTLS
This tells the remote system that it might start switching from this unencrypted to an encrypted connection by sending the “STARTTLS” command. It will then start negotiating a TLS-encrypted connection. You could compare it to an HTTP connection that suddenly switches over to an encrypted HTTPS connection. The advantage is that you can start talking SMTP on TCP port 25 and don’t have to open up a second TCP port like 465 which is the “SSMTP” (secure SMTP) port and only accepts encrypted connections. - ENHANCEDSTATUSCODES
This enables more three-digit return codes for various conditions. See the RFC2034 if you are curious. - 8BITMIME
In ancient times SMTP only processed 7-bit characters. You couldn’t transfer special characters like “Ä” or “ß” without special encoding. 8BITMIME allows a transmission of emails using 8-bit characters. Still many emails are specially encoded using ISO8859-1 or UTF-8. - DSN
It enables DSNs (delivery status notofications) that allows the sender to control the messages that Postfix creates when an email could not be delivered as intended. - SMTPUTF8
In addition to 8BITMIME you can use UTF8 encoded characters in header fields. - CHUNKING
This feature (described in RFC 3030) makes sending of large emails more efficient.
However one important line is missing here that would allow us to send our username and password:
250-AUTH PLAIN LOGINWe told Postfix to only allow authentication when the connection is encrypted. So we are not offered authentication over this plain text connection. That’s what we want.
Are you still connected? Okay, good. So we need an encrypted connection using TLS. Using the STARTTLS feature we can switch over from unencrypted to encrypted without having to reconnect. Enter…
STARTTLSAnd the server replies:
220 2.0.0 Ready to start TLSHowever now it’s getting weird because you would have to speak TLS encryption which is not a language that humans speak. So let’s quit this using the “QUIT” command and do that differently:
QUITWe can use OpenSSL to help us with the decryption. Run:
openssl s_client -connect localhost:submission -starttls smtpYou will see a lot of output. OpenSSL has connected to TCP port 25 and issued a STARTTLS command to switch to an encrypted connection. So whatever you type now will get encrypted. Enter:
EHLO example.comAnd Postfix will send a list of capabilities that will look like this:
250-PIPELINING250-SIZE 10240000250-VRFY250-ETRN250-AUTH PLAIN LOGIN250-ENHANCEDSTATUSCODES250-8BITMIME250 DSNAnd now that we are using an encrypted connection Postfix offers us to authenticate. So let us send the authentication string with a Base64-encoded password:
AUTH PLAIN AGpvaG5AZXhhbXBsZS5vcmcAc3VtbWVyc3VuUnless you have changed John’s password to something else than “summersun” the server should accept that authentication:
235 2.7.0 Authentication successfulExcellent. You are logged in through SMTP. You could now send an email to be forwarded to another mail server. I just wanted to show that authentication works if you use an encrypted connection.
Disconnect from Postfix:
QUITAuthentication works. Well done.
Wait a minute. What was that crazy cryptic string? There was no username and password in it. Was it encrypted?
No, that was no encryption. It was merely an encoded version of the username and password. Why that? Well usually in SMTP you can only transfer ASCII characters. But the password may contain special characters which are not covered by ASCII. So in the PLAIN method that information is Base64 encoded.
What is actually converted to Base64…
NULL-BYTE + USERNAME + NULL-BYTE + PASSWORDSo for John’s case you can easily create the Base64 string using:
printf '\0john@example.org\0summersun' | base64As a result you will get the exact same string you used above with “AUTH PLAIN”.
Footnotes
Section titled “Footnotes”-
In previous guides I recommended to set
smtpd_sasl_auth_enable=yesglobally in themain.cf. That would indeed enable authentication on port 25. For a clearer separation I now rather suggest to leave it out (default isno) and just enable authentication on thesubmissionservice in themaster.cffile. A possible scenario that required this setting to beonwould be if your server were a relay (smarthost) for other servers using authentication.. ↩ ↩2