Также Вы могли использовать программу Дающего. Используя его Вы могли передать файлы по LAN 2 щелчками или "drag'n'dropping" файлом получателю. Получатели (которые также должны работать giver
) обнаружены через Zeroconf, таким образом, Вы не должны знать даже их IP. Вот видео о том, как Дающий работает.
Причина данного сообщения об ошибке состоит в том, что fetchmail имеет свой стандартный вход, не подключенный к терминалу, но каналу.
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)
{
fprintf(stderr,
GT_("fetchmail: can't find a password for %s@%s.\n"),
ctl->remotename, ctl->server.pollname);
return(PS_AUTHFAIL);
} else {
...
Можно, однако, попробовать следующее script
взломайте для разрешения fetchmail
выполненный в псевдотерминале.
(sleep 0.3; echo "dohadeer") |
( script -q /dev/null fetchmail --all -p pop3 -k pop.gmail.com --ssl -d0 --user FakeName@gmail.com )
Намеренный. Что-либо на командной строке видно кому-либо еще в системе путем выполнения простого ps
команда, таким образом, большая часть программного обеспечения, которое берет пароль, не примет пароль, переданный по каналу из командной строки.
Существуют некоторые приемы, с которыми можно сделать wish
и expect
но Вы ищете меньше сложности, не больше...
fetchmail --pass swordfish
, на многих нельдах любой пользователь видит Ваш пароль. Но если Вы работаете echo pass swordfish | fetchmail
, другие пользователи не видят Вашего пароля, потому что он не передается командной строке никакого процесса ( echo
команда является встроенным на примерно каждой оболочке там, таким образом, ее аргументом не является часть командной строки процесса).
– Gilles 'SO- stop being evil'
12.11.2011, 01:48
Можно использовать .netrc
файл к specifiy паролям; это объяснено в ручном http://www.fetchmail.info/fetchmail-man.html#14. Пример:
machine hermes.example.org
login joe
password topsecret
Средства защиты часто не удобны для пользователя вообще, и я думаю, что существуют некоторые серьезные основания для этого. Просто возьмите пароли в качестве примера: Вы, как предполагается, выбираете пароль, который трудно предположить, но это обычно означает, что пароль также трудно помнить.
Пароль для Вашего почтового ящика является единственной вещью, которая мешает кому-то еще читать Ваши электронные письма, таким образом, это имеет смысл, что fetchmail попытается помешать Вам отправлять свой пароль в ясном. С другой стороны, это не очень практично, чтобы иметь scriptable программу как fetchmail, когда необходимо отправить пароль каждый раз, когда это работает. Вот почему fetchmail позволяет помещать пароль в файл конфигурации (Этот файл должен быть только читаемым собой; я не уверен, что fetchmail проверит, что, но он должен).
То, что Вы смогли обеспечить, целый fetchmailrc на командной строке является в основном ошибкой безопасности и не был, вероятно, предназначен.
Вы могли также видеть его с этой точки зрения: При чтении fetchmailrc или netrc файла, fetchmail знает, куда данные прибывают из (из файла, игнорируя -f -
взлом/ошибка), таким образом, это может проверить, был ли пароль защищен (путем проверки, что файл только читаем пользователем). Если это читает его из tty, это не знает, куда это прибыло из, таким образом, это ничего не может проверить.
Я знаю, что этот вопрос древний, но если кто-то еще придет искать ответ, надеюсь, это поможет. Вот что у меня есть для работы:
echo "опрос mailServer pass mailPassword" | fetchmail -f--u mailUser
На самом деле я собрал это по кусочкам из ОП и комментария ОП, опубликованного в одном из ответов. Единственное, что, похоже, упустил ОП, это то, что отправка конфигурации на стандартный ввод по-прежнему требует соблюдения правил для конфигурации. Таким образом, почтовый сервер должен быть первым элементом конфигурации, а перед паролем должно стоять слово «pass». Все остальное может быть либо в блоке, переданном на стандартный ввод, либо в аргументах.