2

After doing a major Ubuntu dist upgrade from 10.04 to 12.04, my virtual-user postfix / dovecot installation only offers "PLAIN" SMTP Authentication mechanism.

It used to offer PLAIN + LOGIN mechanisms, and I have tried everything under the sun to get the the LOGIN one back again, but it just won't do it.

Without the "LOGIN" version, a lot of MS-based clients (windows live, outlook express) can no longer send mail using SMTP Auth. I've had to put their IP addresses in to my 'mynetworks' list.

I even tried setting up a from-scratch postfix+dovecot+virtual users smtp server with 12.04.1, thinking that it had to be something to do with the upgrade, but can't get anything more than AUTH PLAIN to be offered on the new system either.

Has anyone successfully set up a working postfix + dovecot + virtual users mail server on 12.04 that properly does SMTP Auth?

My current dovecot config: http://pastie.org/5651874

and current postfix config: http://pastie.org/5651882

.

FYI here are the excerpts of configurations I've tried:

(A):

/etc/dovecot/conf.d/10-auth.conf:

auth_mechanisms = plain login

/etc/dovecot/conf.d/10-master.conf:

service auth {
  unix_listener auth-userdb {
  }
  inet_listener {
    port = 12345
  }
}

/etc/postfix/main.cf

smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = inet:127.0.0.1:12345

Results in

... warning: SASL: Connect to inet:127.0.0.1:12345 failed: Connection refused
... fatal: no SASL authentication mechanisms

from my logs.

.

.

And (B):

/etc/dovecot/conf.d/10-auth.conf:

auth_mechanisms = plain login

/etc/dovecot/conf.d/10-master.conf:

service auth {
  unix_listener auth-userdb {
  }
  unix_listener /var/spool/postfix/private/auth {
    mode = 0666
    user = postfix
    group = postfix
  }
}

/etc/postfix/main.cf

smtpd_sasl_auth_enable = yes
smtpd_sasl_exceptions_networks = $mynetworks
smtpd_sasl_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth

Results in only the PLAIN mechanism being offered.

.

The documentation that adaptr referenced in his answer doesn't have any example of the UNIX socket style config for Dovecot 2, so I'm hoping that someone with more experience can guide me here.

3
  • 1
    As you would be told on both the Postfix and Dovecot mailing lists: post the configuration that is really used, not the one you think is used, no matter how sure you are. We need the output of postconf -n and doveconf -n. Otherwise we can only guess what might be wrong.
    – daff
    Jan 8 '13 at 23:25
  • Thanks for the tip Daff. I've updated the question to include links to both of those. Jan 9 '13 at 0:28
  • The 10.04 LTS -> 12.04 LTS upgrade is indeed broken, at least when it comes to the mail system.
    – mbx
    Aug 2 '13 at 21:23
3

Well, from what I see in your posted configuration you never set Dovecot's auth_mechanisms = plain login, thus the default of auth_mechanisms = plain is used. Try updating that setting and restarting Dovecot, afterwards re-check the output of doveconf -n.

Your auth socket settings seem correct to me, Postfix should be able to do SASL authentication against Dovecot.

2
  • I noticed the lack of that specification as i was looking through the results of doveconf -n ... but the auth_mechanisms = plain login is indeed in my /etc/dovecot/conf.d/10-auth.conf. So what would keep the settings in that file from being picked up? Jan 9 '13 at 6:20
  • 1
    Aaaannnd it turns out that's the magic question after all. My /etc/dovecot/dovecot.conf was missing the !include conf.d/*.conf line from the bottom of it, thus never having a chance to read the auth_mechanisms I specified. Thank you gentlemen for all your help and support. Jan 9 '13 at 6:44
3

As documented, dovecot must advertise the appropriate mechanisms.

2
  • I've been through that documentation... If I try TCP, I get "warning: SASL: Connect to inet:127.0.0.1:12345 failed: Connection refused fatal: no SASL authentication mechanisms" and if I try the unix socket version, it doens't give me any errors, but i still only get "Plain" mechanism offered. Jan 8 '13 at 20:43
  • I edited my question to include both types of configurations that I've tried. Jan 8 '13 at 21:07
-2

I was having this same problem on CentOS 6 and the cause of my problem was different:

Having the setting:

smtpd_tls_security_level = encrypt

in main.cf stripped

250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN

from EHLO output during a telnet session. Putting it in master.cf restored the output and intended behavior:

submission inet n - n - - smtpd
-o smtpd_tls_security_level=encrypt

I felt it was worth sharing this solution since at least three tutorials I found online suggested that it was okay to include this setting in main.cf.

2
  • That's because smtpd_tls_security_level = encrypt implies smtpd_tls_auth_only = yes which configures Postfix to not offer insecure login mechanisms without a secure transport. If you used something like openssl s_client instead of telnet and negotiated a TLS session you should then see PLAIN and LOGIN mechanisms offered. As it is, if anyone can sniff your port 25 traffic they can see your passwords when there's no TLS.
    – bodgit
    Jul 24 '16 at 23:48
  • Right, that makes sense. I figured I would post anyway to generate some further discussion, and in case a fellow Postfix newbie was jumping over the same hurdles I was. The Postfix documentation is thorough, but not very friendly at times. Jul 31 '16 at 20:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.