Take the 2-minute tour ×

I'm trying to configure a fetchmail. Before I deal with the syntax of fetchmailrc ( I discovered that the level of bugginess of a problem is synergistic with the number of different aspects of the problem that I do not understand, so one new thing at a time ), I decided to pass all the options via commandline.

I got tired of entering the password for each test so I wanted to pass it in the script. I couldn't find something like --pass as a commandline option for fetchmail so I thought maybe echo the password to fetchmail ala:

echo "dohadeer"| fetchmail  --all -p pop3 -k pop.gmail.com --ssl -d0   --user FakeName@gmail.com

I dismissed it and googled "fetchmail password commandline" and got several hits which claimed the above technique worked! But when I tried it I get the error:

fetchmail: can't find a password for FakeName@gmail.com@pop.gmail.com.

I can figure out workarounds for the original problem, but I can't figure out why this approach doesn't work. Obviously there is something I don't understand about Linux and want to figure out.

share|improve this question

4 Answers 4

up vote 3 down vote accepted

The reason for the given error message is that fetchmail has its standard input not attached to a terminal, but a pipe.

man fetchmail | less -Ip 'user authentication step failed'

# from: 
# http://opensource.apple.com/source/fetchmail/fetchmail-33/fetchmail/fetchmail.c

if (!isatty(0))   // <-- tests if stdin is a terminal (added)
      GT_("fetchmail: can't find a password for %s@%s.\n"),
         ctl->remotename, ctl->server.pollname);
         } else {

You may, however, try the following script hack to let fetchmailrun in a pseudo terminal.

(sleep 0.3; echo "dohadeer") | 
( script -q /dev/null fetchmail --all -p pop3 -k pop.gmail.com --ssl -d0 --user FakeName@gmail.com )
share|improve this answer
Thank you for answering the question. The hack is a nice plus, unfotunately I could not get it to work. I would like to investigate it further though, but not much time this week. Maybe next week. –  HandyGandy Nov 15 '11 at 18:51

Intentional. Anything on the command line can be seen by anyone else on the system by executing a simple ps command, so most software that takes a password will not accept the password piped from the command line.

There are some tricks you can do with wish and expect but you're looking for less complexity, not more...

share|improve this answer
Though I'm pressed that you realise that tcl and expect, would be counterproductive, this answer sums up to "by deisgn" which is only slightly less stupid then "a miracle mappens". Furthermore it ignores the fact that you can pipe the whole fetchmailrc ala: echo "contents of fetchmailrc" | fetchmail -f - ... which makes the entire contents of fetchmailrc visible by ps. –  HandyGandy Nov 11 '11 at 15:27
... I'm really not sure how and why you feel that "this is by design" is a stupid answer when it's correct. Just because it's not what you want to hear doesn't mean it's not true. –  Shadur Nov 11 '11 at 23:06
@HandyGandy This answer is correct: it is a design choice. The reason for that design choice is not stupid. If you run fetchmail --pass swordfish, on many unices, every other user can see your password. But if you run echo pass swordfish | fetchmail, other users cannot see your password, because it is not passed on the command line of any process (the echo command is a built-in on just about every shell out there, so its argument are not part of a process's command line). –  Gilles Nov 11 '11 at 23:48
Sorry Giles. You have completely misread what is going on. Reread my sample command ( which looks very much like yours ) and the comment in the answer " accept the password piped from the command line". Which does not say that that fetchmail does not accept the password on the commandline, but that it does not accept a password piped ( presumably by echo ). –  HandyGandy Nov 15 '11 at 5:34
@Giles: The main problem I have with this answer though, is that it does not address the question. In case you are not aware, the version of the fetchmail command in my question prompts for a password immediately after being executed. Why shouldn't it accept the password piped? As for the "by design part" , ( which begs the question ) it is hard to believe that this is actually a designed feature, since echoing the entire fetchmailrc which includes the password does work. –  HandyGandy Nov 15 '11 at 5:42

You can use the .netrc file to specifiy passwords; this is explained in the manual http://www.fetchmail.info/fetchmail-man.html#14. Example:

machine hermes.example.org
login joe
password topsecret
share|improve this answer
I did not ask for a workaround. I asked for an explanation of this behaviour. –  HandyGandy Nov 11 '11 at 15:01
And when you were given one you downvoted the answer because you thought it was "stupid". –  Shadur Nov 12 '11 at 0:07
@Shadur: Say what? –  HandyGandy Nov 15 '11 at 5:45

Security features are often not user-friendly at all, and I think there are some good reasons for that. Just take passwords as an example: you are supposed to choose a password that is difficult to guess, but that usually means that the password is also difficult to remember.

The password for your e-mail account is the only thing that stops someone else from reading your e-mails, so it makes sense that fetchmail will try to keep you from submitting your password in the clear. On the other hand, it is not very practical to have a scriptable program like fetchmail when you have to submit your password every time it runs. That's why fetchmail allows putting the password into a config file (This file should be only readable by yourself; I'm not sure fetchmail will check that, but it should).

That you were able to provide the whole fetchmailrc on the command line is basically a security bug, and was probably not intended.

You could also see it from this point of view: When reading the fetchmailrc or netrc file, fetchmail knows where the data comes from (from the file, ignoring the -f - hack/bug), so it can check whether the password has been secured (by checking that the file is only readable by the user). If it reads it from the tty, it does not know where it came from, so it can't check anything.

share|improve this answer

Your Answer


