Results 1 to 6 of 6

Thread: Tumbleweed 20200201 update Courier-IMAP problem

  1. #1
    Join Date
    Feb 2013
    Location
    N.E. Illinois
    Posts
    35

    Default Tumbleweed 20200201 update Courier-IMAP problem

    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:

    Code:
    $ 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...

  2. #2
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    27,817
    Blog Entries
    15

    Default Re: Tumbleweed 20200201 update Courier-IMAP problem

    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.
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  3. #3
    Join Date
    Feb 2013
    Location
    N.E. Illinois
    Posts
    35

    Default Re: Tumbleweed 20200201 update Courier-IMAP problem

    Quote Originally Posted by malcolmlewis View Post
    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.

  4. #4
    Join Date
    Sep 2012
    Posts
    5,318

    Default Re: Tumbleweed 20200201 update Courier-IMAP problem

    Quote Originally Posted by rnturner View Post
    I don't see any ".rpmnew" files anywhere related to Courier.
    It is not about Courier, it is about changes in /etc/nsswitch.conf.

  5. #5
    Join Date
    Feb 2013
    Location
    N.E. Illinois
    Posts
    35

    Default Re: Tumbleweed 20200201 update Courier-IMAP problem

    Quote Originally Posted by arvidjaar View Post
    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:

    Code:
    #
    # /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.

  6. #6
    Join Date
    Feb 2013
    Location
    N.E. Illinois
    Posts
    35

    Default Re: Tumbleweed 20200201 update Courier-IMAP problem

    Quote Originally Posted by rnturner View Post
    ... why Courier/T-bird no longer play nice together?
    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:
    Code:
    ...
    # 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •