Using username@domain login for Postfix (SMTP)

Greetings! I am using Virtualmin 4.08 GPL on a system running CentOS 6.5. I had to set up a mail server with Dovecot (IMAP) and Postfix. I wanted to use the "user@domain" type of login into the SMTP server,but it seemed Postfix was having some issues with that (you have stated it yourselves). I see that the workaround you have provided is to create another unix account which is an alias to the user@domain,but with a dash instead of the @ symbol. However this does not fully fix the problem,because you still have to enter the "username-domain" in your SMTP settings in the MUA. But I found a solution I want to share with you,which I have tested on two different servers (so far).

First,in /etc/postfix/ you need to add these lines

smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

what this does is basically use dovecot for the sasl authentication. Note that if you turn on "Use SASL SMTP authentication" in your postfix settings in virtualmin,this will not work (because it will use another sasl)

and after that,in the /etc/dovecot/dovecot.conf file we add

auth default {

mechanisms = plain login
passdb pam {
userdb passwd {
socket listen {
client {
path = /var/spool/postfix/private/auth
mode = 0660
user = postfix
group = postfix

And that's it. I found this solution in this old thread but it seems to still be relevant. I can now use "username@domain" to connect to the SMTP server. Since I am not the only one having issues with this,could you consider adding it as a feature or a patch in your next release?



Howdy -- thanks for your thoughts regarding username formats, and your suggestion of using Dovecot for the authentication.

Let's back up for a moment though :-)

Can you describe what problem exactly you're having with Virtualmin, and using the user@domain.tld format?

That method should be completely transparent, and there should be no cases where a user needs to use the user-domain.tld alias. The only person who might wish to know about that alias is the admin, just so they know why there's an extra account listed in the password file.

Other than that, it should be possible to use the user@domain.tld name in all circumstances, from a user's point of view.

Where the user-domain.tld comes in is within some of the configuration files, notably /etc/postfix/virtual, where that's used for email delivery.

Hello,well as I said the problem in this case is that Postfix will not accept the user@domain login method when connecting to the SMTP server weather there is an alias or not. In this case there is,and yes I can see them listed in /etc/postfix/virtual

Hmm, that format actually should work for email authentication with no problem.

The user@domain format is fairly common to use, I use that on my own personal servers, and am able to authenticate using that as the username.

What error(s) do you see in the email logs (/var/log/maillog) when that happens?

Also, what port is it that you're connecting to when that problem occurs?

I know the user@domain format is fairly common,that's what's weird about the whole Postfix thing. I am currently using Mozilla Thunderbird as a MUA to test the whole thing and please believe me,it's not an issue with Thunderbird. So,the output from /var/log/maillog when I'm trying to connect to the SMTP server is:

Jul 4 15:45:27 ico dovecot: imap-login: Disconnected (auth failed, 9 attempts): user=, method=PLAIN, rip=, lip=
Jul 4 15:45:28 ico dovecot: imap-login: Disconnected (auth failed, 9 attempts): user=, method=PLAIN, rip=, lip=
Jul 4 15:45:28 ico postfix/smtpd[15729]: connect from unknown[]
Jul 4 15:45:30 ico postfix/smtpd[15729]: warning: SASL authentication failure: Password verification failed
Jul 4 15:45:30 ico postfix/smtpd[15729]: warning: unknown[]: SASL PLAIN authentication failed: authentication failure
Jul 4 15:45:32 ico postfix/smtpd[15729]: warning: unknown[]: SASL LOGIN authentication failed: authentication failure
Jul 4 15:45:32 ico postfix/smtpd[15729]: lost connection after AUTH from unknown[]
Jul 4 15:45:32 ico postfix/smtpd[15729]: disconnect from unknown[]
Jul 4 15:45:36 ico dovecot: imap(ico): Disconnected: Logged out bytes=106/440
Jul 4 15:45:36 ico dovecot: imap(ico): Disconnected: Logged out bytes=157/930

I have not typed the wrong password if that's what you are thinking.

Which port is it that you're connecting to?

Also, what is the output of this command:

ps auxw | grep saslauth

I'm using port 25. The output is

root 607 0.0 0.1 69064 824 ? Ss Jun24 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 2
root 608 0.0 0.1 69064 824 ? S Jun24 0:00 /usr/sbin/saslauthd -m /var/run/saslauthd -a pam -n 2
root 24216 0.0 0.1 103248 848 pts/1 S+ 19:14 0:00 grep saslauth

Aha, I think that might be the problem.

The saslauthd service needs to be running with the "-r" parameter. That's normally configured by default when using the user@domain.tld format, but it looks like it's not in this case for some reason.

Try editing the /etc/sysconfig/saslauthd file, and add "-r" to the FLAGS= line, then restart saslauthd.

Hello,I tried your suggestion and it worked! Thank you very much for that,but may I ask why doesn't this flag get added in the /etc/sysconfig/saslauthd file when I select the user@domain login format from virtualmin?

I hope you don't think this whole thing is solved,because if the -r flag was added when selecting username@domain login form virtualmin in the first place,there wouldn't be any problem whatsoever. Also there wouldn't be a need for using dovecot for the sasl authentication etc etc. I stated I have tried this on two different servers running Centos 6.5,and I have to add the flag in both manually. Could you consider fixing this,because as I can see THIS is the real issue here.

We've been having difficulty reproducing the problem you're seeing. Virtualmin adds the -r parameter to the "FLAGS" line automatically during installation, and that appears to be working properly in our testing.

How did you perform your Virtualmin installation? Did you use the script?

Yes I used the install script from your website. If it matters,both servers are using the minimal CentOS image.

ive got the same issue as the op. same error in mail.log. however, my ps auxw | grep saslauth output differs, showing a couple more instances, but all of them WITH the -r. im on port 465 btw. everything works long as i dont include @domain in the username.