@maxp1:

It works fine on port 25. Is this a problem with SASL or Postfix? Have I missed something in setting up the extra port?

Are there any differences between your Postfix master.cf entry for port 25 versus 2525 in terms of restrictions or configuration options?

Having duplicate AUTH lines in your EHLO response seems a little strange, but perhaps that's just a cut 'n paste issue?

Do you see more information about the failure in /var/log/mail.log? Postfix ought to have put a line or two in there that led to the generic failure over the protocol.

– David

Jun 22 15:20:23 li52-167 postfix/smtpd[22639]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory

Jun 22 15:20:23 li52-167 postfix/smtpd[22639]: warning: SASL authentication failure: Password verification failed

Jun 22 15:20:23 li52-167 postfix/smtpd[22639]: warning: 4by6.com[72.14.186.167]: SASL plain authentication failed: generic failure

I noted the duplicate AUTH lines. Seems strange but it's working for port 25.

I'm looking over the master.cf, maybe there's something I misunderstood there. Relevant section??

smtp inet n - n - - smtpd -o smtpdsaslauth_enable=yes

config for alternate port

2525 inet n - n - - smtpd -o smtpdsaslauth_enable=yes

Hmm. The error definitely seems to say that it can't talk to saslauthd, but I'm having trouble thinking of any misconfiguration that you could have outside of master.cf (such as Postfix's main.cf, or smtpd.conf or the saslauthd config, or improper ownership of the saslauthd communications socket) that wouldn't impact both ports at the same time.

Are there any continuation lines for those two entries in master.cf? Perhaps its failing in both cases but only one of the two ports is configured to actually care?

You're absolutely sure that back to back tests of port 25 and 2525 during a single Postfix execution work for the former but not the latter? Weird.

– David

Now I've broken it completely, even restoring to original config. Very annoying.

It was working on port 25. I could login using telnet and use clients on a network without port 25 blocked. Grrr…

Here's the whole master.cf file. Other than adding the port I haven't touched it.

#

Postfix master process configuration file. For details on the format

of the file, see the master(5) manual page (command: "man 5 master").

#

==========================================================================

service type private unpriv chroot wakeup maxproc command + args

(yes) (yes) (yes) (never) (100)

==========================================================================

smtp inet n - n - - smtpd -o smtpdsaslauth_enable=yes

2525 inet n - n - - smtpd -o smtpdsaslauth_enable=yes

submission inet n - - - - smtpd

-o smtpdenforcetls=yes

-o smtpdsaslauth_enable=yes

-o smtpdclientrestrictions=permitsaslauthenticated,reject

smtps inet n - - - - smtpd

-o smtpdtlswrappermode=yes

-o smtpdsaslauth_enable=yes

-o smtpdclientrestrictions=permitsaslauthenticated,reject

628 inet n - - - - qmqpd

pickup fifo n - - 60 1 pickup

cleanup unix n - - - 0 cleanup

qmgr fifo n - n 300 1 qmgr

qmgr fifo n - - 300 1 oqmgr

tlsmgr unix - - - 1000? 1 tlsmgr

rewrite unix - - - - - trivial-rewrite

bounce unix - - - - 0 bounce

defer unix - - - - 0 bounce

trace unix - - - - 0 bounce

verify unix - - - - 1 verify

flush unix n - - 1000? 0 flush

proxymap unix - - n - - proxymap

smtp unix - - - - - smtp

When relaying mail as backup MX, disable fallback_relay to avoid MX loops

relay unix - - - - - smtp

-o fallback_relay=

-o smtphelotimeout=5 -o smtpconnecttimeout=5

showq unix n - - - - showq

error unix - - - - - error

discard unix - - - - - discard

local unix - n n - - local

virtual unix - n n - - virtual

lmtp unix - - - - - lmtp

anvil unix - - - - 1 anvil

scache unix - - - - 1 scache

#

====================================================================

Interfaces to non-Postfix software. Be sure to examine the manual

pages of the non-Postfix software to find out what options it wants.

#

Many of the following services use the Postfix pipe(8) delivery

agent. See the pipe(8) man page for information about ${recipient}

and other message envelope options.

====================================================================

#

maildrop. See the Postfix MAILDROP_README file for details.

Also specify in main.cf: maildropdestinationrecipient_limit=1

#

maildrop unix - n n - - pipe

flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}

#

See the Postfix UUCP_README file for configuration details.

#

uucp unix - n n - - pipe

flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)

#

Other external delivery methods.

#

ifmail unix - n n - - pipe

flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)

bsmtp unix - n n - - pipe

flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient

scalemail-backend unix - n n - 2 pipe

flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}

mailman unix - n n - - pipe

flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py

${nexthop} ${user}

Ok, if it's broken in both cases, first thing I'd check is to be sure that Postfix and saslauthd are using the same path to the administrative socket.

For saslauthd, it can be set with the -m option on startup (on my Ubuntu system that's set in /etc/default/saslauthd). Postfix will default to /var/run/saslauthd without an explicit saslauthdpath in smtpd.conf. (Note that saslauthdpath includes the trailing /mux while the -m option to saslauthd doesn't)

Postfix normally runs chroot'd to /var/spool/postfix, which means that saslauthd should be configured to use /var/spool/postfix/var/run/saslauthd - however it looks like you have the chroot option turned off in master.cf so I expect they can both be configured with the same path in your case.

The second thing I'd check is that Postfix is running as a user who has access to the /mux file, either due to appropriate ownership or permissions.

If either the path doesn't match or permissions aren't correct, you'll get the error you're seeing. You can double check just where saslauthd is listening with something like "netstat -anp | saslauthd"

Oh, and I guess it couldn't hurt to just double check that saslauthd is running. It's pid should be in /saslauthd.pid

– David

I had to take a break from this for a few days but when I returned it was working just fine. Didn't do anything, it magically went from a broken state to an unbroken state.

Frustrating…