Securing a Postfix Smtp Server

An open relay is basically an smtp server that requires no authentication and/or allows connections from outside ip addresses, so anyone can send emails from anywhere to anywhere. The settings in question specific to this issue in my configuration were the following:

Basically that is an open relay. Here’s why.

One of my first mistakes when configuring Postfix was misspelling some smtpd parameters using smtp_ instead of smtpd_ to prefix them. As it turns out, if you do this, Postfix ignores your attempted configuration without a peep. This one went on for a long time before I noticed that two of my smtpd_ fields were missing the d. As soon as I put those in there, everything started working as it should, albeit still insecure, but at least it was following the specifications of my config file.

This one took me a while. The smtpd_sasl_path is a path to the socket file for your SASL server. In my case, this is Dovecot.

As it turns out, Postfix defaults to running in chroot mode which makes its root directory /var/spool/postfix/. This was my first mistake. I was specifying

and it was not starting up because it couldn’t find the socket file. This was because it was looking for the file at /var/spool/postfix/var/spool/postfix/private/auth-client a path which clearly does not exist. The solution to this is to simply specify a relative path.

I decided that I would get smart though and shave off some text from the field value by configuring Dovecot to place the socket file at /var/spool/postfix/auth-client rather than at /var/spool/postfix/private/auth-client (speaking in absolute terms despite running in chroot mode). This returned the following error

As it turns out, postfix won’t operate with the SASL socket file path outside of the private directory. So with that, I placed my auth-client file back in the private directory and Postfix started up fine.

Even if you do have authentication required, you still need to specify which users can send email with what addresses. This was a bit of a surprise to me initially because I was under the impression that a password is associated with an email address, not an email address(s) associated with a username and password. To keep users from being able to send email as addresses that are not theirs (specifically randomly generated addresses in my case), you need to create a mapping file that maps usernames to the addresses they are authorized to send mail as. In my case, this is a one to one relationship (one address per username). Before my example I’d like to note that the filename is not required to be the one I use (though my filename is the one used in the Postfix setup documentation).

Okay. Let’s create the map file. To do this, open up and edit /etc/postfix/controlled_envelope_senders (this file likely doesn’t exist yet)

Once you’ve got that open, you simply need to put the maps in there.

Now that we’ve done that, we need to turn it into a binary. Run the following command and it will generate a <filename>.db binary map file in the same directory as the original file.

Presto! Now the user jimminey can send email as jcricket@example0.com. However, so can everyone else…​still.

Now that we have our controlled envelope senders file, we need to reference it in our postfix main.cf and set postfix up to restrict access to the maps specified in that file. Crack er open in your favorite editor and put the following line in somewhere after smtpd_sasl_auth_enable

So what we’ve just done is tell Postfix where our map file is (smtpd_sender_login_maps). After that, we tell Postfix to reject any users that have been authenticated but are trying to send with an address they aren’t authorized to send with in our map file (smtpd_recipient_restrictions). Please note that reject_sender_login_mismatch comes at the beginning of the smtpd_recipient_strictions field. This is key. It is so key in fact, that I missed it (I only miss the key stuff of course thanks Murphy). This was the forth exploit attempt that got me.

This one is the final bit that let the spammers in (so far at least).

The smtpd_recipient_restrictions are restrictions that you can place on the users and their emails based on various things. In my case, I had the following restrictions string

Postfix applies these restrictions in the order in which they are specified. As they put it <blockquote>Restrictions are applied in the order as specified; the first restriction that matches wins.</blockquote> As soon as one restriction matches, then the ones that follow don’t get applied. This was very problematic because in my case permit_mynetworks is first. So that I can log in from my cell phone which has an IP address that changes, I set

which allows any IP address to connect to my SMTP server. Since Postfix takes the first match and goes no further and any IP address is in 0.0.0.0/0, anyone can send mail through my SMTP server. This = bad.

What you should do is start your restrictions with the the most strict restrictions followed by the less strict. In my case, that looks like

In the event someone tries to send an email, first they must login. If they don’t log in, they are rejected due to reject_sender_login_mismatch (we can’t do a match if we don’t have a sender username). Secondly, once logged in, the user must be authorized to use the address they are trying to send as as specified in the smtpd_sender_login_maps line. Finally, once the user has been authenticated and they have permissions to use the address they are trying to send as, their email is not rejected. It follows that they are then filtered through permit_sasl_authenticated. This basically runs a check to see if they are authenticated (which we know they already are because of the previous filter) and since they are, they are permitted and Postfix stops looking for more matches because it’s found one that permits the user to perform their requested action.

As chef Elzar says, "Bam!"