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 box1@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])

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)

This BR does not contain a patch.

Am 22.03.19 um 12:55 schrieb Graeme Vetterlein:

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