Today I was implementing smtp-auth across our mail-cluster for clients whose ISPs block port 25. I’d like to blog my experience here so as to save others encountering the anomalies I did.

Firstly, I already run postfix on the recommended MUA/MTA submission port (587), then make entries for trusted static IPs in postfix’s $mynetworks variable. However, the time has come to push smtp-auth via username & password, and to remove the ever-growing $mynetworks entry.

Tech Philosophy

So, why do I run postfix on port 587? What is special about this port? RFC 2476 states. . .

1. Abstract

SMTP was defined as a message *transfer* protocol, that is, a means to route (if needed) and deliver finished (complete) messages. Message Transfer Agents (MTAs) are not supposed to alter the message text, except to add ‘Received’, ‘Return-Path’, and other header fields as required by [SMTP-MTA].

However, SMTP is now also widely used as a message *submission* protocol, that is, a means for message user agents (MUAs) to introduce new messages into the MTA routing network. The process which accepts message submissions from MUAs is termed a Message Submission Agent (MSA).

3.1. Submission
Port 587 is reserved for email message submission as specified this document. Messages received on this port are defined to submissions. The protocol used is ESMTP [SMTP-MTA, ESMTP], with additional restrictions as specified here.

Essentially, the RFC informs us that if you wish to perform SMTP submissions (ie, direct interaction between an MUA and an MTA in submitting e-mail) you should perform it via port 587. GMail, for instance, defaults to SMTP-AUTH via port 587

Implementation

Ok, technical philosophy out of the way, let’s move onto quickly and easily setting up your MTA correctly. My MTA of choice, as I’ve written about quite a lot on this blog, is Postfix.

According to the Postfix FAQ you can instruct Postfix to run on a port that ! == 25.

This is performed by editing master.cf and appending:

# service type  private unpriv  chroot  wakeup  maxproc command + args
#                  (yes)   (yes)   (yes)   (never) (100)
# ==========================================================
  587       inet     n      -       n         -       -       smtpd

So far, this will allow you to submit a message to the MTA as long as your IP is contained within $mynetworks. Well, this was my first problem - I wanted to move away from this way of doing things. Whenever I tried to perform an smtp-auth, utilising saslauthd, I saw this in my syslog:

postfix/smtpd[15281]: warning: SASL authentication failure:
cannot connect to saslauthd server: No such file or directory
postfix/smtpd[15281]: warning: SASL authentication failure:Password verification failed
postfix/smtpd[15281]: warning: foo.bar (x.x.x.x): SASL PLAIN authentication failed: generic failure

This just didn’t make any sense - port 25 accepted smtp-auth with no problems. Just what was different? I had to perform some research…

After much searching, I found the answer! It’s frustratingly simple. By default, debian runs postfix in a chroot, this is for increased security. However, due to the issues raised here with regards to Postfix Before-Queue Content Filter…

The before-filter Postfix SMTP server forwards the MAIL FROM, RCPT TO and DATA commands that it has approved, but it does not forward other commands such as TLS or SASL commands. It can therefore not be transparent.

The answer to this? Simply enter back into the chroot. I still am unsure why the postfix faq recommends that you break-out of the chroot to accept mail on an alternative port - could someone perhaps enlighten me?

So, I changed our master.cf to reflect these changes…

# service type  private unpriv  chroot  wakeup  maxproc command + args
#                  (yes)   (yes)   (yes)   (never) (100)
# ==========================================================
  587       inet     n      -       -         -       -       smtpd

…I now have a fully clustered, smtp-auth (via sasl) postfix server running on the appropriate RFC designated ports.

Result!