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.xxxx.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 XXXX > 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 > <all the real users> > > 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
