Postfix omits realm (@domain) when checking for smtpd pam+mysql authentication

Question

I've trying to configure Postfix so users can send email through SMTP having a username and password. And I'm trying to store credential within a MySQL database. I've taken the path of saslauthd and pam and I'm stuck in the midway.

Enabling the pam debug feature I can see that when I try to send an email using Thunderbird the query executed to retrieve the password is:

pam_mysql - SELECT password FROM mailbox WHERE username = 'mehran'

It's in the case that username holds the value of [email protected]. But when I try:

# testsaslauthd -u [email protected] -p 123 -s smtp
0: OK "Success."

And the log reads:

pam_mysql - SELECT password FROM mailbox WHERE username = '[email protected]'

Showing that it's Postfix who's omitting the @domain off the username before handing it to saslauthd (or at least I believe so). I've searched up and down Postfix's configuration but I don't see what affects this!?

Answer 1

I found the problem, so here it is in case it would help anyone:

There's a configuration file for saslauthd, mine is located in /etc/sysconfig/saslauthd:

# Directory in which to place saslauthd's listening socket, pid file, and so
# on.  This directory must already exist.
SOCKETDIR=/var/run/saslauthd

# Mechanism to use when checking passwords.  Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled with the ablity to use.
MECH=pam

# Options sent to the saslauthd. If the MECH is other than "pam" uncomment the next line.
# DAEMONOPTS=--user saslauth
# OPTIONS="-c -r -m /var/spool/postfix/var/run/saslauthd"
OPTIONS="-c -m /var/run/saslauthd"

# Additional flags to pass to saslauthd on the command line.  See saslauthd(8)
# for the list of accepted flags.
FLAGS=

The OPTIONS variable is supposed to contain the options passed to saslauthd. It's missing -r which does what exactly I was looking for. According to its documentation:

-r Combine the realm with the login (with an ’@’ sign in between). e.g. login: "foo" realm: "bar" will get passed as login: "foo@bar". Note that the realm will still be passed, which may lead to unexpected behavior.

But my problem was not solved just by this change! It turned out that due to some bug in the /etc/init.d/saslauthd script, even though the configuration file mentioned above is loaded, but it is not applied! The $OPTIONS was never used!!!

Here's the original start section of /etc/init.d/saslauthd script:

start() {
    [ -x $path ] || exit 5
        echo -n $"Starting $prog: "
        daemon $DAEMONOPTS $path -m $SOCKETDIR -a $MECH $FLAGS
        RETVAL=$?
        echo
    [ $RETVAL -eq 0 ] && touch $lockfile
        return $RETVAL
}

And this is how I amended it:

start() {
    [ -x $path ] || exit 5
        echo -n $"Starting $prog: "
        daemon $DAEMONOPTS $path $OPTIONS -a $MECH $FLAGS
        RETVAL=$?
        echo
    [ $RETVAL -eq 0 ] && touch $lockfile
        return $RETVAL
}

All done! Now the query contains the complete email address to check for the password.

Answer 2

Your query contains the wrong/incomplete parameter for the query.

This query will append the domain to the local part of the login:

SELECT password FROM mailbox WHERE username = '%u@%r'

Correct the query in your SASL configuration for postfix, e.g. /etc/postfix/sasl/smtpd.conf