Bug#925282: fetchmail: the message [This account is currently not available] is ambigious
Am 22.03.19 um 12:55 schrieb Graeme Vetterlein: > Package: fetchmail > Version: 6.3.26-3 > Severity: minor > Tags: patch > > Dear Maintainer, > > > I've just hit an "issue" WRT fetchmail, which I now relaise I hit about 10 > years ago and didn't report > (shame on me) the "fix" is a simple text edit so I hope you'll consider it. > > I was getting the message: > > reading message b...@mail..net:1 of 26 (16491 octets) #<...many > stars elided...>*This account is currently not available. > > The way I was invoking it (as part of debugging, originally a cronjob[mail]) > > >> sudo -u mail /usr/bin/fetchmail -f fetchmail-testrc -v -d0 > Where fetchmail-testrc, said: > > poll mail.XXX.net tracepolls with protocol POP3 user box1 password > options fetchall mda "/usr/bin/maildrop /etc/maildroprc.manual" > > Where /etc/maildroprc.manual had a complex config which split the mail into > multiple users and invoked sendmail. > > So the code we have running is: >fetchmail >maildrop >sendmail (exim4) > > All these have suid/sgid. > > The users involved are: > mail > Debian-exim > fetchmail > courier > > > So I'm getting a message "This account is currently not available" . It might > be > coming from any of the above programs, the user might be any of the above > users. > I've just spent another 2 days working on this (presumably longer 10 years > ago) > before resolving it using "diff(1)" of my old system. > > But the error was: > > passwd> mail:x:8:8:mail:/var/mail:/usr/sbin/nologin > > The fix was: > > # usermod -s /bin/bash mail > > So, my proposal :-) This would have been vastly quicker to find and fix had > the message read: > > Instead of: > "This account is currently not available" > > The text: > "fetchmail: The account "mail" is currently not available" > > or better (if it's true) > "fetchmail: The account "mail" does not have a valid shell (e.g. > bash)" > > (my guess is you don't directly issue this message) Graeme, The guess is correct, this is not fetchmail speaking, "This account is currently not available" is /usr/sbin/nologin. My maildrop binary does not contain this text either if I grep the binary or the output of "strings /usr/bin/maildrop". I can reproduce a similar situation (by using /usr/sbin/nologin for the MDA), but my log then also contains "fetchmail: MDA returned nonzero status 1", however IF something in your /etc/maildroprc.manual causes the exit status to be lost, then that may go missing. I have not used Exim for more than ten years now and if your mailfilter is complex... I don't know how those pieces interact, and maildrop also has multiple modes of operation (delivery and standard modes and whatnot). Graeme, can you debug this a bit more and see what really triggers the issue and reassign this bug to the right software? Or should we just close this bug? Thanks in advance. Best regards, Matthias
Bug#925282: fetchmail: the message [This account is currently not available] is ambigious
Package: fetchmail Version: 6.3.26-3 Severity: minor Tags: patch Dear Maintainer, I've just hit an "issue" WRT fetchmail, which I now relaise I hit about 10 years ago and didn't report (shame on me) the "fix" is a simple text edit so I hope you'll consider it. I was getting the message: reading message b...@mail..net:1 of 26 (16491 octets) #<...many stars elided...>*This account is currently not available. The way I was invoking it (as part of debugging, originally a cronjob[mail]) > sudo -u mail /usr/bin/fetchmail -f fetchmail-testrc -v -d0 Where fetchmail-testrc, said: poll mail.XXX.net tracepolls with protocol POP3 user box1 password options fetchall mda "/usr/bin/maildrop /etc/maildroprc.manual" Where /etc/maildroprc.manual had a complex config which split the mail into multiple users and invoked sendmail. So the code we have running is: fetchmail maildrop sendmail (exim4) All these have suid/sgid. The users involved are: mail Debian-exim fetchmail courier So I'm getting a message "This account is currently not available" . It might be coming from any of the above programs, the user might be any of the above users. I've just spent another 2 days working on this (presumably longer 10 years ago) before resolving it using "diff(1)" of my old system. But the error was: passwd> mail:x:8:8:mail:/var/mail:/usr/sbin/nologin The fix was: # usermod -s /bin/bash mail So, my proposal :-) This would have been vastly quicker to find and fix had the message read: Instead of: "This account is currently not available" The text: "fetchmail: The account "mail" is currently not available" or better (if it's true) "fetchmail: The account "mail" does not have a valid shell (e.g. bash)" (my guess is you don't directly issue this message) -- System Information: Debian Release: 9.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages fetchmail depends on: ii adduser 3.115 ii debianutils 4.8.1.1 ii libc6 2.24-11+deb9u4 ii libcomerr21.43.4-2 ii libgssapi-krb5-2 1.15-1+deb9u1 ii libk5crypto3 1.15-1+deb9u1 ii libkrb5-3 1.15-1+deb9u1 ii libssl1.1 1.1.0j-1~deb9u1 ii lsb-base 9.20161125 Versions of packages fetchmail recommends: ii ca-certificates 20161130+nmu1+deb9u1 Versions of packages fetchmail suggests: ii exim4-daemon-light [mail-transport-agent] 4.89-2+deb9u3 pn fetchmailconf pn resolvconf -- Configuration Files: /etc/default/fetchmail [Errno 13] Permission denied: '/etc/default/fetchmail' -- no debconf information
