Hide Forgot
After installing this update, OSX's Mail.app program now refuses to talk via IMAP to the dovecot server. Using IMAPS on port 993 works, however not without SSL on port 143. the log in /var/log/maillog shows: Feb 2 02:02:48 zeus dovecot: imap-login: Aborted login: rip=203.56.246.84, lip=203.56.246.81 Feb 2 02:03:19 zeus last message repeated 10 times Feb 2 02:03:48 zeus dovecot: imap-login: Aborted login: rip=203.56.246.84, lip=203.56.246.81 interestingly enough, Squirrelmail can still use localhost:143 ok as it's IMAP mail source. I can also telnet to the server and get a banner. # telnet zeus.crc.id.au 143 Trying 203.56.246.81... Connected to zeus.crc.id.au (203.56.246.81). Escape character is '^]'. * OK Dovecot ready. I don't believe this is a config issue between earlier versoins - as I wasn't using a verion 0.99 config to start with. I tried the following: # grep -v '^ *#' /etc/dovecot.conf|grep -v ^$|less protocols = imap imaps pop3 pop3s listen = * ssl_listen = * ssl_cert_file = /etc/pki/dovecot/certs/dovecot.pem ssl_key_file = /etc/pki/dovecot/private/dovecot.pem mbox_read_locks = fcntl mbox_write_locks = fcntl protocol imap { } protocol pop3 { } auth default { mechanisms = plain passdb pam { } userdb passwd { } user = root } It seems to be something between the versions that makes some mail clients not like the IMAP login banner and stops the client from authing. When running the Connection Doctor from within Mail, it states "Trying to log into this IMAP account failed. Please make sure the username and password are correct". During this test, the maillog just shows: Feb 2 02:30:46 zeus dovecot: imap-login: Aborted login: rip=203.56.246.84, lip=203.56.246.81 I know the username and password are correct - as all I need to change is the Use SSL option and I can then login to the mailbox in question.
from using tethereal: 1 0.000000 203.56.246.84 -> 203.56.246.81 TCP 50106 > 143 [SYN] Seq=0 Ack=0 Win=65535 Len=0 MSS=1460 WS=0 TSV=1980878128 TSER=0 2 0.000052 203.56.246.81 -> 203.56.246.84 TCP 143 > 50106 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=160939182 TSER=1980878128 WS=2 3 0.000264 203.56.246.84 -> 203.56.246.81 TCP 50106 > 143 [ACK] Seq=1 Ack=1 Win=65535 Len=0 TSV=1980878128 TSER=160939182 4 0.001038 203.56.246.81 -> 203.56.246.84 IMAP Response: * OK Dovecot ready. 5 0.004089 203.56.246.84 -> 203.56.246.81 TCP 50106 > 143 [ACK] Seq=1 Ack=22 Win=65535 Len=0 TSV=1980878128 TSER=160939182 6 0.017055 203.56.246.84 -> 203.56.246.81 IMAP Request: 1 LOGIN username password 7 0.017075 203.56.246.81 -> 203.56.246.84 TCP 143 > 50106 [ACK] Seq=22 Ack=28 Win=5792 Len=0 TSV=160939186 TSER=1980878128 8 0.017339 203.56.246.81 -> 203.56.246.84 IMAP Response: * BAD [ALERT] Plaintext authentication is disabled, but your client sent password in plaintext anyway. If anyone was listening, the password was exposed. 9 0.019199 203.56.246.84 -> 203.56.246.81 IMAP Request: 2 LOGOUT 10 0.019662 203.56.246.81 -> 203.56.246.84 IMAP Response: * BYE Logging out 11 0.019889 203.56.246.84 -> 203.56.246.81 TCP 50106 > 143 [ACK] Seq=38 Ack=262 Win=65535 Len=0 TSV=1980878128 TSER=160939186 12 0.051026 203.56.246.84 -> 203.56.246.81 TCP 50106 > 143 [FIN, ACK] Seq=38 Ack=262 Win=65535 Len=0 TSV=1980878128 TSER=160939186 13 0.051068 203.56.246.81 -> 203.56.246.84 TCP 143 > 50106 [ACK] Seq=262 Ack=39 Win=5792 Len=0 TSV=160939194 TSER=1980878128 The config file hasn't changed from previous versions of Dovecot. Has the default values inside the rpm changed?
# Disable LOGIN command and all other plaintext authentications unless # SSL/TLS is used (LOGINDISABLED capability). Note that 127.*.*.* and # IPv6 ::1 addresses are considered secure, this setting has no effect if # you connect from those addresses. disable_plaintext_auth = no The above config seemed to fix this error, however it was not required before and was commented out. Looks like the default for this config option has changed in the RPM. The reason squirrelmail was still working it that it uses 127.0.0.1 as it's IMAP server - hence being trusted by default. Although this is probably not a bug as such (it may be resulting from a previous bug?), it may well be either closed, or documented somewhere.
I have flipped the default back to plaintext auth enabled for next version. I will have to think about this more though. Either way, we'll have to document this.
So the decision is to leave plaintext enabled, so i consider this bug resolved.