The most recent zypper session updated Courier-IMAP from 4.18.2 to 5.0.8 which, apparently, is a fairly radical change. After the update, nobody is able to access their Maildir mailboxes. T-bird, for example, pops up a password entry dialog upon starting (apparently passwords stored in the user’ wallets are not being accepted. Going ahead and manually entering your password results in a popup box showing “Retry|Enter new password|Cancel” options. Issuing “authtest your-email-acctname-here” on the server results in “Authentication FAILED: Operation not permitted”. Telnetting to the server at port 143 and trying to login gets you:
$ telnet 192.168.13.3 143
Trying 192.168.13.3...
Connected to 192.168.13.3.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=PLAIN IDLE ACL ACL2=UNION STARTTLS ENABLE UTF8=ACCEPT] Courier-IMAP ready. Copyright 1998-2018 Double Precision, Inc. See COPYING for distribution information.
0 login <your-email_acctname-here>
0 NO Error in IMAP command received by server.
Since the update, it also appears that Postfix is no longer forwarding mail to Courier via maildrop. So not only can nobody see their old mail, we not even receiving new mail.
Ideas as to what the update did that has broken everything IMAP-related?
TIA…
Hi
I would think it might be the recent change moving items from /etc to /usr/etc. If you run rpmchkconfig and see the output for merging rpmnew (use diff) files with the old configs.
Diffing the files pointed to by “rpmconfigcheck” shows quite a few changes to the Postfix “.cf” files (main, master) but I can’t see anything that isn’t something I’ve deliberately changed (for filtering and things like that). BTW, I didn’t mention before but outbound mail works just fine.
I don’t see any “.rpmnew” files anywhere related to Courier.
I might have solved the maildrop problem… or nearly solved it. I do see messages in the logs stating that mail was delivered to maildrop but nothing new appears in “~username/Maildrop/cur”. Mail is being deposited into “~/Maildir/new”, though, which seems to indicate some sort of Courier problem, right? So… I’m looking for any details on the flow of mail files through the Courier directory structure to try and determine why they’re getting stuck in “new”.
As for the authentication failures between T-bird to Courier authlib…
There are some files that look like configuration backups – “*.pam-config-backup” – under “/etc/pam.d”. The newer versions of these files all seem to have records related to “gnome keyring”. For example:
common-auth
password requisite pam_cracklib.so
password optional pam_gnome_keyring.so use_authtok
password required pam_unix.so use_authtok nullok shadow try_first_pass
common-auth.pam-config-backup
password requisite pam_cracklib.so
password required pam_unix.so use_authtok nullok try_first_pass
Could the (allegedly optional) Gnome keyring be at fault? To test this, I made a backup copy of “/etc/pam.d/imap” and commented out all the “include” directives in that file. Then appended each of the “.pam-config-backup” files in order to it. Then rebooted. No joy. T-bird still fails to connect. Running “authtest acctname acctpw” still fails as does telnetting to port 143. All of which I would assume exonerates T-bird from being broken. So I’ve moved back to the version of “/etc/pam.d/imap” that refers to the Gnome keyring.
Any other ideas?
I think the T-bird->Courier authorization breakage seems to make the most sense to address first. But any suggestions are welcomed.
It is not about Courier, it is about changes in /etc/nsswitch.conf.
If you mean the additional of “usrfiles” to many of the entries like “services”, those are all there:
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Legal entries are:
#
# compat Use compatibility setup
# nisplus Use NIS+ (NIS version 3)
# nis Use NIS (NIS version 2), also called YP
# dns Use DNS (Domain Name Service)
# files Use the local files
# [NOTFOUND=return] Stop searching if not found so far
#
# For more information, please read the nsswitch.conf.5 manual page.
#
passwd: compat
group: compat
shadow: compat
hosts: files dns
networks: files dns
services: files usrfiles
protocols: files usrfiles
rpc: files usrfiles
ethers: files usrfiles
netmasks: files
netgroup: files nis
publickey: files
bootparams: files
automount: files nis
aliases: files usrfiles
If the above is not correct, please let me know what is wrong with that file’s contents. It is the “nsswitch.rmpnew” file that was deposited on the system by zypper. (I find it odd that “usrfiles” would be so critical that not having it would break so many things yet the file that was pushed out does not even mention it as a legal entry.)
If it is correct, can we please move onto to figuring out why Courier/T-bird no longer play nice together? If it’s something related to the new nsswitch, it’d be nice to understand just what in that file changed that could be adversely affecting someone from accessing mail.
The why is that the “authdaemonrc” file that was pushed out along with the rest of Courier-IMAP 5.x had no authentication modules enabled. None. Zero. Nada. Changing that file to contain:
...
# The authentication modules that are linked into authdaemond. The
# default list is installed. You may selectively disable modules simply
# by removing them from the following list. The available modules you
# can use are: authuserdb authpam authpgsql authldap authmysql authsqlite authcustom authpipe
#
# DEFAULT SETTING from /etc/authlib/authdaemonrc.dist:
#
#authmodulelist="authuserdb authpam authpgsql authldap authmysql authsqlite authcustom authpipe"
#
**authmodulelist="authuserdb authpam authpgsql authldap authmysql authsqlite authcustom authpipe"**
...
No authentication was even being done until that record (in bold) was added. The text stating “The default list is installed.” doesn’t mean they’re enabled. I’m a bit curious why that setting wouldn’t be included in the update.
Now to undo all the debugging I’d enabled in various places…
The best debugging method for this problem turned out to be stopping the courier-authlib service and running authdaemond by hand. Trying to get the debug output into the system logs was not working. (See the “Debugging authentication problems” at the courier-mta.org site.)
Calling this one solved.