Перед тем, как сообщать об ошибке, прочтите советы разделе G3, как включать диагностическую информацию, которая позволит как можно быстрее исправить ошибку.
Если у вас есть вопрос или ответ, который вы считатете необходимым осветить в этом FAQ, пишите администратору списка рыссылки, Эрику Ремонду, по адресу esr@thyrsus.com.
Fetchmail - это решение задачи доставки почты с удаленных систем на Unix-машины, очень полезное при периодическимх соединениях, например, PPP или SLIP, с удаленным почтовым сервером. Fetchmail может собирать почту, используя любые вариации протоколов POP или IMAP, а затем направлять ее локальному SMTP-агенту, разрешая применение всех обычных механизмов пересылки, фильтрации, раскрытия псевдонимов к локальной почте.
Fetchmail - это не игрушка и не пример программирования, а мощное средство промышленного применения, способное прозрачно обрабатывать почту как для одиночного пользователя, так и для целого домена. Fetchmail прост в настройке, скромен к ресурсам, очень мощный, богат возможностями и хорошо документирован.
Fetchmail распространяется как open-source Открытость исходных текстов является самым сильным обеспечением качества. Тщательное анализирование кода огромным сообществом пользователей на разных платформах показало, что fetchmail отличается высокой надежностью и защищенностью, насколько это позволяют низлежащие протоколы.
Fetchmail распространяется под лицензией GNU.
Последний FAQ в формате HTML, а также последние исходники fetchmail, находятся на домашней странице fetchmail: http://www.tuxedo.org/~esr/fetchmail. Они также находятся на сервере Sunsite.
Текстовая версия этого FAQ включена в дистрибутив fetchmail. Поскольку она включается туда только во время подготовки дистрибутива, она не всегда самая последняя.
Да, если вы предоставите мне достаточно диагностической информации. Отсылайте найденные ошибки в список рассылки fetchmail-friends@ccil.org. Сообщая об ошибке, укажите следующее:
Если у вас есть доступ по FTP к вашему почтовому серверу и вы считаете, что ошибка вызывается некоторым сообщением, включите копию этого сообщения, вызвавшего ошибку.
Часто я отвечаю тем, что предлагаю установить более свежую версию fetchmail, а затем посмотреть на результат. Поэтому вы сэкономите время, если заранее протестируете самую последнюю версию fetchmail до того, как отправите извещение об ошибке.
Если вы используете POP3, проверьте - не поддерживает ли ваш почтовый сервер IMAP4, используя функцию автоопределения утилиты fetchmailconf. Если у вас IMAP4, и fetchmailconf не говорит, что он дыряв, немедленно переходите на IMAP4. POP3 - это слабый, плохо спроектированный протокол с хроническими проблемами, и последние его версии после RFC1725 скорее только хуже, чем лучше. Переход на IMAP4 снимет многие ваши проблемы, и если ваш провайдер не поддерживает IMAP4, лучше отошлите ошибку ему, чтобы он поставил поддержку IMAP.
Полезно также добавить содержимое вашего файла .fetchmailrc, но это не обязательно, если ошибка не связана с его синтаксисом. Если вы решили послать .fetchmailrc, не забудьте сначала замаскировать пароли!
Если fetchmail работает и принимает почту, но заголовки выглядят искаженными (например, некоторые отсутствуют или пустые строки), то сначала прочтите в этом FAQ раздел X. Обратите особое внимание на диагностику искажения почты. В цепочке прохождения почты задействовано много программ помимо fetchmail.
Расшифровка неудачной сессии с помощью опций -v -v (да, именно две штуки) очень полезна для отладки.
Если вы обновили версию fetchmail и что-то сломалось, включите расшифровку -v -v обоих версий - старой и новой. Часто проблема быстро решается поиском расхождений в транзакциях протоколов.
Если ошибка вызывает 'core dump' или зависание, очень полезна трассировка через gdb (прикрепите gdb к работающему, но не зависшему процессу, указав ID процесса во втором аргументе). Вам следует переконфигурировать fetchmail так:
CFLAGS=-g LDFLAGS=" " ./configureи собрать новую версию, которую может трассировать отладчик.
Очень неплохо приложить почтовый файл, который вызывает ошибку при приеме.
Любую ошибку, которую я могу воспроизвести, я обычно исправляю очень быстро, обычно в течении 48 часов. Исправление ошибки, которую я не могу воспроизвести, занимает больше времени. Поэтому если вы хотите скорейшего решения вашей проблемы, не только достаточно, но и необходимо, чтобы вы дали мне способ ее воспроизвести.
Лучше всего отфильтровывать спам с помощью procmail или maildrop на стороне сервера и (если вы администратор сервера) настройкой sendmail. Политика лучше настраивается опцией mda и скриптами вокруг fetchmail.
Я не собираюсь делать этого. fetchmail занимается транспортом, а не политикой.
Причины, по которым fetchmail не имеет часто требуемых функций (например, шифрования паролей или параллельных приемов почты) смотрите в документе design notes.
Fetchmail - это зрелый проект, он не находится в стадии разработки. Он более не является моим основным проектом, и я с большой неохотой вношу в него изменения, которые могут затронуть его стабильность или привлечь большой объем кода.
Есть список рассылки "fetchmail-friends", для тех, кто обсуждают нововведения в fetchmail и помогают в его разработке. Вы можете подписаться на него на fetchmail-friends@lists.ccil.org. Есть еще список только для объявлений, fetchmail-announce@lists.ccil.org.
Разработка fetchmail была еще и социологическим экспериментом с целью выяснить правоту моей теории о критических функциях модели разработки Linux.
Эксперимент был успешным. Я написал статью об этом под заголовком The Cathedral and the Bazaar , которую представил на Linux Kongress '97 в Баварии. Она также была представлена на Linux Expo в Атланте, Linux Pro'97 в Варшаве, на первой конференции по Perl, на UniForum '98, а также на презентациях на Usenix '98. Ребята из Netscape сказали, что она помогла им решиться открыть исходные тексты Netscape Communicator.
Короткий ответ: IMAP 2000 на Unix.
Длинный ответ:
Fetchmail будет работать с любым сервером POP, IMAP, ETRN, или ODMR, удовлетворяющим соответствующим RFC (и даже с откровенно дырявыми, как Microsoft Exchange и Novell GroupWise). Это не означает, что он будет работать одинаково хорошо. POP2 и POP3, не поддерживающие LAST, ограничивают возможности fetchmail.
Большинство современных Unix (особенно Linux и *BSD) поставляются с заранее настроенным сервисом POP3. Вместе с тем все больше и больше используется IMAP.
Если у вас есть выбор, установите сервер IMAP4rev1; он обладает наилучшими возможностями слежения за сообщениями со статусом 'seen'. Он также лучше восстанавливает прерванные соединения, чем POP3, и обладает большей производительностью. Новый сервер IMAP 2000 весьма приятная штука, поддерживает CRAM-MD5, так что вам не надо будет беспокоиться о посылке пароля открытым текстом. Старые версии для этой же цели используют GSSAPI.
Не попадитесь на удочку пропаганды NT/Exchange. M$ Exchange чрезвычайно "дырявая" система (см. S2), а NT не может поддерживать большой загруженный почтовый сервер. Даже Microsoft прекрасно это знает; ее собственный сервис Hotmail работает на Solaris!
Fetchmail будет работать со всеми популярными программами транспорта почты . Ему все равно, какой почтовый агент вы используете, а пользовательскому почтовому агенту все равно, каким способом почта доставляется в ваш системный почтовый ящик. Поэтому вы можете использовать любой из популярных почтовых агентов - elm, pine, mh, или mutt - все они прекрасно работают с fetchmail.
Не могу не удержаться, чтобы отдельно не упомянуть mutt. Моя собственная почтовая система основана на sendmail плюс fetchmail плюс mutt. Интерфейс mutt лишь немного отличается от своего прдка pine, зато великолепно справляется с MIME и PGP.
В зависимости от вашего сервера, ответ может варьировать от "тривиально" до "невозможно".
Большинство пользователей используют fetchmail по телефонным каналам, которые тяжело перехватить. Тем, кто способен это сделать, гораздо проще получить доступ к вашему почтовому ящику на сервере. Поэтому если модемы провайдера приводят вас сразу к почтовому серверу, вам не о чем беспокоиться.
В общем случае, вам не нужно специально защищать fetchmail, если вы доверяете защите почтового сервера провайдера, откуда забираете почту. Ваша уязвимость будет скорее связана с уязвимостью вашей локальной сети (например, некто может перехватить траффик Ethernet между модемной стойкой и вашей машиной).
Учитывая это, вы должны спросить себя - снимет ли шифрование только пароля эту проблему. Если вы подозреваете, что ваш траффик между вами и почтовым сервером может быть перехвачен, то лучше использовать шифрование всего потока, чтобы ничего нельзя было прочитать. Одним из преимуществ fetchmail перед обычной доставкой по SMTP является возможность применения ssh (см. K3).
Учтите, что ssh не является полной защитой, т.к. ваша почта может быть перехвачена между POP-сервером и отправителем. В таком случае используйте GPG (Gnu Privacy Guard) или PGP (Pretty Good Privacy).
Если нет возможности использовать ssh/sshd, шифрование пароля по крайней мере предотвратит удаление вашей почты зловредными хакерами.
Вы можете выяснить, какими возможностями шифрования обладает ваш почтовый
сервер, посмотрев на строку приветствия (в IMAP команда CAPABILITY).
Запустите fetchmail -v или зайдите с помощью telnet на порт
почтового сервера (110 для POP3, 143 для IMAP).
Если почтовый сервер использует IMAP 2000, у вас есть встроенная поддержка CRAM-MD5. Fetchmail обнаруживает это, и вы можете этот раздел дальше не читать.
Для POP3 скорее всего доступен APOP. Эта функция поддерживается многими
серверами. Если вы увидите в строке приветствия что-то вроде интернет-
адреса в угловых скобках и число слева, это приветствие APOP.
Вы можете зарегистрировать секрет на сервере (используя программу
popauth. Укажите пароль в
.fetchmailrc; он будет использован для шифрования текущего вызова, и
зашифрованная форма будет отправлена на сервер для проверки.
Кроме того, у вас может быть доступен Kerberos. Это может потребовать у вас наличия некоторых магических файлов в вашем домашнем каталоге на клиентской машине, но в любом случае, это позволяет не указывать ваш пароль.
Fetchmail поддерживает разные схемы Kerberos. Одна из них - разновидность POP3, называемая KPOP; обратитесь к документации по вашему серверу (ключом является наличие в приглашении строки "krb-IV"). Другая - свойства IMAP и POP3, описанные в RFC1731 и RFC1734. Вы можете увидеть AUTH=KERBEROS_V4 в ответ на команду CAPABILITY.
Если вы принимаете почту с CompuServe через POP3, то можете использовать утентификацию RPA (она сходна с APOP). См. S3. Если вы принимаете почту с сервера Microsoft Exchange по протоколу IMAP, то можете использовать NTLM.
Ваш POP3-сервер может поддерживать OTP (RFC1938) - одноразовые пароли. Для проверки этого ищите "otp-" в строке приветствия. Если fetchmail собран с поддержкой OTP (как это сделать - смотрите в файле INSTALL), то это обнаруживается fetchmail'ом. При использовании OTP вы указываете пароль, но он не передается в открытом виде.
Вы можете взять патчи OTP для POP3 и IMAP OTP у Craig Metz с http://www.inner.net/pub/.
Наконец, вы можете использовать SSL для полного шифрования траффика, если это поддерживает почтовый сервер.
Да. Чтобы не смущать некторые MTA (например, exim), fetchmail всегда указывает в RCPT TO полное доменное имя, включая адрес машины (hostname). Обычно это делается добавлением "@localhost", но если вы используете Kerberos или ETRN, он добавит "@" и полное доменное имя машины (FQDN).
Добавление FQDN может создать проблему, когда fetchmail работает в режиме демона и переживает изменение динамического адреса IP.
Поскольку новый адрес IP (найденный в RCPT TO во время интерпретации) не совпадает с первоначальным, это может заставить ваш MTA думать о попытке релея и отказать. Кроме того, fetchmail может пытаться соединиться с несуществующим адресом. И в самом плохом случае - послать вашу почту на чужую машину!
Используйте опцию smtpaddress, чтобы добавляемое имя
машины принудительно соответствовало адресу 127.0.0.1 в файле
/etc/hosts. (Обычно используется `localhost'
но вы можете указать и адрес IP).
Только одна опция fetchmail непосредственно взаимодействует с вашим
IP-адресом,`interface'.
Эта опция может быть использована для настройки шлюза и ограничения
диапазона адресов IP, которые может использовать fetchmail.
Такое ограничение полезно по сооражениям безопасности.
Я рекомендую воздержаться от настройки опции interface при
начальном конфигурировании fetchmail - она не необходима для работы.
Сначала убедитесь, что все работает,а потом добавьте опцию
interface.
В случае с динамическим IP вы не можете использовать ETRN. Вам необходимо иметь собственное зарегистрированное доменное имя и легальный постоянный IP, ассоциированный с этим доменом. Сервер надо настроить на прием почты для вашего домена и помещения ее в очередь для пересылки на вашу машину. ETRN просто указывает серверу выбрать всю очередь для вашего домена. В этом случае fetchmail на самом деле не принимает почту, а задействут для этого дела локальный sendmail.
On-Demand Mail Relay (ODMR) можно использовать с динамическим IP; собственно, для этого он и создавался. К сожалению, серверы ODMR мало распространены.
Если вы используете конфигурацию с динамическим IP, может возникнуть другая проблема (не связанная с fetchmail): сервера получателей могут отвергнуть вашу почту, поскольку имя машины не является настоящим (т.е. не удается определитьв DNS адрес). В таком случае вам надо использовать "маскарад" в sendmail. Поможет установка
DMsmarthost.hereв файле
sendmail.cf, или можно настроить
MASQUERADE_AS(smarthost.here)в конфигурации m4. (В обоих случаях замените
smarthost.here на настоящее имя вашей почтовой машины.)
Подробности смотрите в sendmail
FAQ.
Нет. Вы можете использовать fetchmail вместе с SOCKS.
Рецепт использования fetchmail с firewall смотрите в K1
Пользователь справшивает: как отослать почту на POP3-сервер? Нужно ли мне для этого еще какая-нибудь утилита или это может сделать fetchmail?
Fetchmail работает только для приема почты. Для отправки используется sendmail или другой установленный на машине клиента MTA.
Обычно sendmail запускается периодически (на большинстве системах каждые 15 минут) для отправки почты, находящейся в очереди. Если вы используете pppd для автоматической дозвонки до провайдера, когда ядро требует открыть TCP/IP-соединение, обеспечьте отправку почты.
Теоретически может возникнуть проблема с 32-битным счетчиком time_t, который обнулится в 2038, но я сомневаюсь. Вряд ли в то время вы будете работать на машине разрядностью менее 64 бит.
Нет. Fetchmail - это транспртный агент, выполняющий роль шлюза между серверами POP3/IMAP и SMTP. Disconnected IMAP подразумевает наличие интерактивного клиента. Это совсем другая проблема.
Fetchmail отправляет тело сообщение построчно; большая часть памяти расходуется на хранение заголовков сообщений, она освобождается, когда начинается отправка тела сообщения. Таким образом, он довольно экономно использует память.
После запуска fetchmail в режиме демона при каждом цикле приема проверяет состояние файла концигурации. Если он изменен, он считывается. В остальное время fetchmail вообще не обращается к диску.
Производительность fetchmail в основном зависит от состояния POP-сервера и качества канала TCP/IP до сервера.
Попробуйте gmake
Бессметрные слова Алана Кокса: "Возьмите lex от Solaris и засуньте его в задницу продавцу Sun, а затем скачайте и установите flex и используйте его. И все будут счастливы."
(Говорят, та же проблема в HP-UX v10.20 и IRIX)
mxget.o(.text+0x35): undefined referenceto `__res_search' mxget.o(.text+0x99): undefined reference to`__dn_skipname' mxget.o(.text+0x11c): undefined reference to`__dn_expand' mxget.o(.text+0x187): undefined reference to`__dn_expand' make: *** [fetchmail] Error 1то добавьте опцию "-lresolv" в строку LOADLIBS файла Makefile после того, как установили пакет `bind' .
Если вы получаете ошибки, связанные с dcgettext, вроде этих:
rcfile_y.o: In function `yyparse': rcfile_y.o(.text+0x3aa): undefined reference to `dcgettext__' rcfile_y.o(.text+0x4f2): undefined reference to `dcgettext__' rcfile_y.o(.text+0x5ee): undefined reference to `dcgettext__' rcfile_y.o: In function `yyerror': rcfile_y.o(.text+0xc7c): undefined reference to `dcgettext__' rcfile_y.o(.text+0xcc8): undefined reference to `dcgettext__' rcfile_y.o(.text+0xdf9): more undefined references to `dcgettext__' followспереконфигурируйте командой configure --with-included-gettext. Это связано с ошибкой GNU-библиотек интернационализации.
Если вы используете ETRN, измените опцию smtphost на fetchdomains.
Специальный случай `via localhost' для ssh уже не используется. Вместо этого используйте %h в plugin.
В 5.6.8 ключевое слово preauth изменено снова на auth. preauth продолжает поддерживаться.
dns включена (по умолчанию), вы должны обеспечить,
чтобы номера машин были полными доменными именами. Для избежания перегрузки DNS,
fetchmail больше не определяет канонические имена клиенской машины при запуске.
via', я решил, что взаимодействие
между опциями `via',`aka' и `localdomains'
выходит из-под контроля. Их поведение стало очень сложным и запутанным,
даже я не уверен, что все понимаю. Пользователи были неприятно удивлены.
Вместо того, чтобы добавить новые опции или выбросить код, я переосмыслил его.
Редизайн упростил код и сделал опции более ортогональными, но это может
не работать в сложных доменных ящиках.
Конфигурация для multidrop зависит от имени сразу после опции
`poll' или `skip', которая все еще
интерпретируется как DNS-имя с целью сравнения адресов, даже при наличии
`via'.
remote' изменен на `folder'.
username'
interface', `monitor' и
`batchlimit' .
Они использованы как глобальные опции в синтаксисе с `set',
как опции batchlimit и logfile. Теперь это опции сервера, как
`protocol'.
Если у вас было что-то вроде
set interface = "sl0/10.0.2.15"
в вашем .fetchmailrc, удалите эту строку и добавьте
`interface sl0/10.0.2.15' в раздел опций сервера объявления значений по умолчанию.
налогично для опций `monitor' или `batchlimit'
Обновите fetchmail до версии 5.0.6 или более поздней, или используйте двойные кавычки.
Да, я понимаю, что порядок следования трудно понять. К сожалению, он необходим для правильной работы опции 'defaults'.
На своей машине я единственный пользователь и запускаю fetchmail под бюджетом root из cron следующим образом:
fetchmail -u "itz" -p POP3 -s bolero.rahul.net
Все это работало без .fetchmailrc в домашнем каталоге root.
Но начиная с версии 2.0 он стал принимать всю почту на root, пока я не
создал в каталоге ~root файл содержащий:
skip bolero.rahul.net proto POP3
user itz is itz
Он не хочет работать без параметра "user itz".
Видимо, fetchmail считает получателем того пользователя, под чьим бюджетом запущен fetchmail, если нет локальных псевдонимов, а соответствие по умолчанию (itz -> itz) не учитвается. А должно бы.
Ответ:
Нет, не должно. Я думал над этим, и заключение мне не понравилось, но это неизбежно. Проблема состоит в том, что fetchmail в общем случае не знает, что локальный пользователь 'itz' на самом деле существует.
"Как?", скажете вы, "Неужели нельзя посмотреть в файле passwd?"
Во-первых, это не всегда возможно. А если сервер SMTP находится на другой машине? Вы проиграли.
Во вторых: С чего вы взяли, что машина itz и SMTP-сервер itz одно и то же? Это совершенно не обязательно, и fetchmail не должен делать таких предположений, пока локальный itz не предоставит доказательства своего существования.
Автоматический запуск и останов fetchmail несколько труднее реализовать, если вы имеете несколько активных сеансов. В каталоге contrib дистрибутива fetchmail находятся несколько скриптов, которые вы можете включить в ваши файлы .bash_login и .bash_logout Спасибо James Laferriere <babydr@nwrain.net>
Некоторые запускают и останавливают fetchmail используя скрипты ppp-up и ppp-down.
Во-первых, вам может вообще не понадобиться опция --interface. Ели ваша машина использует SLIP или PPP для связи с провайдером, то организуется достаточно безопасное соединение с сетью провайдера, минимизирующее риск перехвата информации. В этом случае указание опции --interface бесполезно.
Эта опция полезна, если у вас есть несколько провайдеров. В этом случае обычно только один из них используется для почты.
Чтобы определить устройство:
interface "ppp0/205.164.136.0/255.255.255.0"
Для указания диапазона из двух последних байтов,
(65536 адресов) укажите:
interface "ppp0/205.164.0.0/255.255.0.0"
sendmail может осуществлять фильтрацию спама на основании базы данных правил фильтрации. Источник базы находится в /etc/mail/access, а сама база - в /etc/mail/access.db.
Таблица использует адреса email, доменные имена и номера сетей как ключи поиска. Например,
spammer@aol.com REJECT cyberspammer.com REJECT 192.168.212 REJECT
будет отвергать почту от spammer@aol.com, от любого пользователя cyberspammer.com (или любой машины в домене cyberspammer.com), и от любой машины в сети 192.168.212.*. (Подробнее смотрите документацию по sendmail)
Для активирования базы выполните в каталоге /etc/mail команду:makemap hash deny <deny
Для проверки пошлите сообщение на свой адрес с одной из таких машин и попробуйте принять их с помощью fetchmail, указав опцию -v. Вы можете наблюдать транзакции SMTP; при проверке адреса FROM sendmail увидит, что это сообщение от спаммера, и fetchmail удалит его.
Ни в коем случае не помещайте адрес вашей почтовой машины или любой машины, откуда вы принимаете почту fetchmail'ом - вы потеряете всю почту!
poll mainsite.example.com proto pop3 user .... poll secondary.example.com proto pop3 interval 6 user ...
Выберите файл (например, /etc/fetchmailrc), и запускайте с опцией -f, указывающей на него. Это должно решить проблему.
smtphost или smtpname.
FEATURE(always_add_domain), то можно оставить опцию
rewrite выключенной.
Если sendmail сообщает ``sendmail does not relay'', убедитесь, что
в sendmail.cf есть объявление Cwlocalhost, чтобы
sendmail узнавал `localhost' как имя своей машины.
Если вы отправляете почту на другую машину, убедитесь, что IP-адреса перечислены в ip_allow (обычно в /etc/mail/)
Если вы заметили, что ваш sendmail не любит адреса типа
`FETCHMAIL-DAEMON@localhost' (используемые при возвращении почты отправителю
), вы можете установить опцию sendmail
FEATURE(accept_unqualified_senders).
sendmail на Digital Unix не работает с
fetchmail: выдаются сообщения "553 Local configuration
error, hostname not recognized as local". Проблема состоит в том, что
fetchmail пересылает почту к sendmail с указанием адреса клиентской машины
в поле MAIL FROM. Эти версии sendmail считают это зацикливанием почты
и отвергают ее. Вы можете обойти это ограничение, включив
опцию --invisible.
Если вы хотите поддержку multidrop и имеете доступ к редактированию файла sendmail.cf, добавьте следующее правило:
H?l?Delivered-To: $hЭто заставит почтовый сервер писать правильный адрес конверта в каждом сообщении до того, как fetchmail увидит его. Тогда режим multidrop будет корректно работать даже в том случае, если заголовки Received не будут содержать адреса конверта. Однако, получатели все равно не различаются, и единственное преимущество в том, что почта не отвергается, если поступает почта с несколькими адресами в заголовке Bcc. Для решения этой проблемы вы можете попробовать следующий трюк, хотя он все еще экспериментальный:
H?J?Delivered-To: $u
Mmdrop, P=/usr/bin/procmail, F=lsDFMqSPfhnu9J,
S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrToSMTP,
T=DNS/RFC822/X-Unix,
A=procmail -Y -a $u -d $h
Для обоих трюков вы должны объявить `envelope "Delivered-To:"'
на стороне fetchmail, поместить виртуальный домен (например, `domain.com')
в файл access с правилом RELAY, и добавить строку в файл mailertable: `domain.com local:local-pop-user'
для первого трюка или `domain.com mdrop:local-pop-user' для второго
трюка.
Вы увидите, что если почта уже имеет заголовок Delivered-To, sendmail не добавит еще одного.
Попробуйте также рецепт Мартина Леваарта в каталоге contrib дистрибутива.
forcecr; qmail не любит строки, заканчивающиеся
только LF.
Если указывать имена локальных машин, то возможна надежная сборка почты для всего домена.
Одной из основных особенностей qmail заключается в заголовке сообщения `Delivered-To:'. Когда qmail помещает сообщение в локальный почтовый ящик, он помещает имя пользователя и имя машины из конверта в эту строку. Это служит для предотвращения зацикливания почты.
Для настройки qmail на накопление почты для отключенного узла, провайдер обычно помещает его имя в файл `virtualhosts', чтобы добавить префикс ко всем адресам этого сайта. Таким образом, почта, посылаемая на 'username@userhost.userdom.dom.com' будет иметь строку 'Delivered-To:' в виде:
Delivered-To: mbox-userstr-username@userhost.userdom.dom.com
Для одной машины это будет проще:
Delivered-To: mbox-userstr-username@userhost.dom.com
Провайдер может настроить префикс 'mbox-userstr-' на все что угодно,
обычно это имя машины пользователя.
Для использования этой строки вам следует:
| ../bin/qmail-inject -a -f"$SENDER" "${LOCAL#mbox-userstr-}@$HOST"
Peter Wilson добавляет:
``Мой провайдер использует в качестве префикса "alias-unzzippedcom-". Это означает, что я должен создать файл с именем ".qmail-unzzippedcom-default". Дело в том, что qmail подразумевает, что все сообщения, посылаемые пользователю user-xyz обрабатываются файлом ~user/.qmail-xyz (или ~user/.qmail-default).''
Luca Olivetti добавляет:
Есои вы не используете qmail локально или не хотите настраивать механизм
псевдонимов, вы можете использовать опцию
`qvirtual "mbox-userstr-"' в конфигурационном файле
fetchmail для удаления префикса из имени пользователя.
Если вы включили (on) опцию rewrite:
RFC1123 требует, чтобы адреса в MAIL FROM и RCPT TO были полностью квалифицированными (т.е. имели полные доменные имена). Но exim не хочет по умолчнию принимать 'localhost' в качестве FQDN. Это можно исправить.
В exim.conf добавьте в объявление local_domains параметр `localhost' Напрмер, для машины thyrsus.com это будет выглядеть так:
local_domains = thyrsus.com:localhost
Если опция rewrite отключена (off):
MAIL FROM представляет потенциальную проблему, если исходящий поток от fetchmail на MTA не передает канонизированные адреса From и Return-Path. В этом случае сообщения, сгенерированные sendmail'ом на вашей машине, возвращаются, например, если адрес отправителя MAILER-DAEMON.
Правильный способ исправить эту проблему состоит во включении опции rewrite
и предоставить fetchmail делать канонизацию адресов.
Если же по каким-то причинам rewrite должен быть выключен,
попробуйте подправить конфигурационный файл exim, добавив строку:
sender_unqualified_hosts = localhost
в основной раздел файла конфигурации exim. Учтите, в этом случае
сообщения будут содержать неверные имена доменов, добавленные к адресу
возврата.
Smail 3.2 совместим с sendmail и работает без проблем.
Нам сообщают, что при обработке нескольких сообщений в одном сеансе fetchmail, smail иногда доставляет их в порядке, отличном от даты поступления. Это не проблема fetchmail, а "особенность" smail.
Старые версии smail нуждаются в опции -smtp_hello_verify
в файле настройки smail. Это переопределяет проверку адреса в HELO.
Также можно указать
-smtp_hello_broken_allow=127.0.0.1
чтобы smail принимал строку
"localhost", которую fetchmail добавляет к адресу получателя.
MMDF довольно сложно настроить, но состыковать fetchmail с MMDF несложно. Почитайте статью MMDF recipe, описывающую метод замены UUCP на fetchmail в MMDF.
Lotus Notes SMTP gateway пытается сам определить, нужно ли преобразовывать \n в \r\n, но не всегда получается. Используйте `forcecr'.
courier не любит адреса в RCPT, выглядящие как
someone@localhost. Для избежания этого используйте опции
smtphost или smtpaddress.
Возможно, дело не в fetchmail, а в сетевом коде qmail. Другая программа, fetchpop (другой POP-клиент Linux) тоже выдает такую же ошибку, а Netscape под Win95 - нет. Эта проблема решается обновлением до qpopper 3.0b1.
Хорошо известно, что поддержка POP3 в Exchange 2000 очень плохая и непригодна для использования. Одним из симптомов является то, что сообщения без заврешающего NL, приклеивают точку, означающую конец сообщения, к последнему символу сообщения, без завершающего символа новой строки. Это приводят к зависанию fetchmail и других стандартных почтовых серверов. Тем не менее, с IMAP все в порядке.
Старые версии Exchange пригодны наполовину.
Fetchmail, использующий IMAP, поддерживает аутентификацию NTLM. Для этого вы должны сконфигурировать fetchmail с опцией --enable-NTLM и перекомпилировать. Имя пользователя указывайте в виде `user@domain': часть слева от @ означает имя пользователя, а часть справа - имя домена NTLM.
M$ Exchange нарушает стандарты POP3 и IMAP. Его команда LIST не выдает реальные размеры почты в почтовых ящиках, а размер сжатых версий в базе данных Exchange.
Несмотря на это, fetchmail работает с M$ Exchange путем компромиссов. Во первых, некорректно работает --limit (т.к. работает с сжатым размером, а не с реальным). Во вторых, агенту ESMTP может быть передан слишком малый аргумент SIZE.
Это можно поправить, внеся изменения в регистр:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MsExchangeIs\Parameters System\Pop3 CompatibilityЭто битовая маска, управляющая отклонениями от стандартов протоколов. Биты определены следующим образом:
KEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MsExchangeIs\Parameters System\Pop3 Performance
Другая замеченная проблема с серверами Exchange состоит в том, что на запрос LOGIN они могут отвечать "NO Ambiguous Alias". Grant Edwards пишет:
Это означает, что сервер Exchange настолько глуп, что не может определить, какой почтовый ящик вам принадлежит. Вместо того, чтобы вести соответствие между именем пользователя и его почтовым ящиком, он использует недописанную, черт знает какую эвристику для определения почтового ящика. В вашем случае сервер решил, что ваше имя принадлежит нескольким ящикам.У вас два выхода:
- Попросить администратора настроить сервер так, чтобы имя пользователя и имя ящика совпадали.
- Попросить администратора объявить псевдоним, указывающий на ваш почтовый ящик.
Но лучше всего использовать тактическое ядерное оружие, чтобы стереть лица Земли разработчиков из Редмонда, и выбрать любой CD с Linux, NetBSD, FreeBSD, или Solaris.
fetchmail -V;
если вы заметили после ID версии строку "+RPA", то все в порядке,
в противном случае вам надо пересобрать fetchmail из исходников
(см. файл INSTALL)
В качестве пароля передавайте ваш пароль в CompuServe строчными буквами. Добавьте `@compuserve.com' к идентификатору пользователя так, чтобы он выглядел как `user <UserID>@compuserve.com', где <UserID> может быть либо числовым идентификатором пользователя, либо вашим ником e-mail. fetchmail автоматически проверит csi.com в строке приветствия POP. Если найдено, и имя пользователя заканчиватся на `@compuserve.com', fetchmail запросит сервер, поддерживает ли он RPA. В случае положительного ответа вместо посылки пароля открытым текстом будет использована транзакция RPA.
Внимание: включение отладки (-v -v) заставит показать ваш пароль на экране в формате Unicode!
Две строки в .fetchmailrc показывают отличие между RPA и не-RPA:
# Эта версия использует RPA
poll csi.com via "pop.site1.csi.com" with proto POP3 and options no dns
user "CSERVE_USER@compuserve.com" there with password "CSERVE_PASSWORD"
is LOCAL_USER here options fetchall stripcr
# Эта версия не использует RPA
poll non-rpa.csi.com via "pop.site1.csi.com" with proto POP3 and options no dns
user "CSERVE_USER" there with password "CSERVE_POP3_PASSWORD"
is LOCAL_USER here options fetchall stripcr
Например, для приема почты ля пользователя <philh@vision25.demon.co.uk>, используйте:
set postmaster "philh"
poll pop3.demon.co.uk with protocol POP3:
user "philh@vision25" is philh
Received: from punt-1.mail.demon.net by mailstore for fred@xyz.demon.co.uk
id 899963657:10:27896:0; Thu, 09 Jul 98 05:54:17 GMT
Для включения режима
multi-drop вам нужно указать fetchmail, что 'mailstore' это имя
машины, принимающей вашу почту, и дать ему возможность определить
имя машины в адресе email. В следующем примере подразумевается, что
ваша машины xyz.demon.co.uk, и вы купили пересылку всей почты домена
my-company.co.uk (в этом случае ваш MTA должен быть сконфигурирован
на прием почты пользователю user@my-company.co.uk).
poll pop3.demon.co.uk proto pop3 aka mailstore no dns:
localdomains xyz.demon.co.uk my-company.co.uk
user xyz is * fetchall
Команда `fetchall' обеспечивает прием всей почты. Если вы хотите оставить
ее на сервере, используйте
`uidl' и `keep'; в Demon не реализована устаревшая команда
`top'.
Если вы используете UIDL, убедитесь, что "user@host" не будет конфликтовать
с кодом UIDL в fetchmail; используйте user+host.
Demon может сам удалять почту с сервера, которая старее 30 дней ; см. их Страницу POP3.
SDPS включает нестандартное расширение для приема конверта сообщения (*ENV), которое поддерживает fetchmail, если его скомпилировать с опцией --enable-SDPS option. В этом случае в первой строке ответа fetchmail -V будет строка "+SDPS".
Если вы прикомпилировали SDPS, fetchmail в режиме POP3 автоматически это обнаружит во время диалога с Demon Internet, и будет использовать *ENV для получения адреса конверта To.
Автодетект работает путем проверки имени машины в приглашении POP3 ; если вы соединяетесь с Demon Internet через прокси, это может не работать. Для принудительного включения SDPS укажите в качества аргумента опции protocol значение "sdps".
fetchall', иначе почта останется на сервере.
Скорее всего, это связано с ошибкой сервера.
Серверы usa.net servers (по крайней мере версии 2.2, июнь 1998)
неправильно обрабатывают команду TOP. Независимо от аргумента, они всегда
возвращают первые 10 строк сообщения. fetchmail обычно использует TOP для
определения ранее прочитанных сообщений, но опция
`fetchall' вместо этого заставляет принудительно давать команду
RETR.
Кроме того, говорят, USA.NET добавляет много циклов (hops) к вашему сообщению. Вам может потребоваться увеличить значение параметра MaxHopCount в файле sendmail.cf чтобы избежать отказа в пересылке почты.
(Замечание: серверы usa.net содержат много хронических ошибок. Мы рекомендуем подобрать другого провайдера.)
Как и в случае с M$ Exchange, единственный способ избавиться от проблем - перейти на более надежный POP или IMAP сервер. Менеджеры OpenMail уверяют, что ошибки исправлены в версии 6.0
Однако, у нас есть сведения (декабрь 2001), что неверно работает команда TOP, возвращающая только одну строку независимо от аргумента.
mda "sed -e '1s/^\t/Received: /' | formail | /usr/bin/procmail -d <user>"Замените \t ровно одним символом табуляции. Вы также должны использовать опцию "fetchall", т.к. серверы Geocities иногда думают, что прочтены только первые 45 сообщений.
Лечение: Выберите другого провайдера. Рекламные окна на Geocities уже достали, вы должны байкотировать их.
Это тактика удержания клиентов; в качестве адекватного ответа мы рекомендуем байкотировать MSN.
Начиная с версии 5.0.8, мы включили поддержку аутентификации NTLM. Это может позволить fetchmail работать с MSN; в противном случае сообщите нам, чтобы мы исправили этот FAQ.
fetchall, чтобы гарантированно принять почту в следующем сеансе.
fetchall.
Кроме того, TOP иногда не может вытянуть все сообщение, даже если указано достаточно большое число строк. Разработчикам MailMax известно об этой ошибке, но по состоянию на 4 мая 2000 она еще не была исправлена. Если вы вынуждены использовать этот сервер, укажите опцию fetchall, чтобы принудительно выдать команду RETR.
Fetchmail может обойти эту проблему, но мы настоятельно рекомендуем голосовать своими долларами за какой-нибудь другой не такой глупый сервер.
9 января 2001 мне прислали письмо из InfiniteMail, в котором говорится, что в новой версии InterChange 3.61.08 эта ошибка исправлена.
Alan Schmitt добавил аналогичную опциюr --with-socks5, которая может лучше работать с последними версиями библиотеки SOCKS.
Для использования fetchmail с сетевой безопасностью (networking security, т.е. IPsec), вам необходима система, поддерживающая IPsec, API, описанный в "Network Security API for Sockets" (draft-metz-net-security-api-01.txt), и набор inet6-apps. Это означает, что вам необходима система BSD/OS или NetBSD с дистрибутивом NRL IPv6+IPsec. Поддержка IPSec в Linux выйдет ближайшие месяцы.
Дистрибутив NRL IPv6+IPsec можно взять отсюда: http://web.mit.edu/network/isakmp
Пакет inet6-apps можно взять отсюда: http://ftp.ps.pl/pub/linux/IPv6/inet6-apps/.
Более подробная информация о IPv6 можно найти на страницах:
Используйте опцию plugin. Пример для: plugin "ssh %h /usr/sbin/imapd"
Эта опция указывает fetchmail вместо открытия соединения через порт 143 и выполнения стандартной аутентификации IMAP, запустить ssh, затем imapd. Это обеспечивает более защищенную аутентификацию через ssh (а также шифрование всего траффика). Большинство демонов IMAP обнаруживают, что они были вызваны из командной строки, и считают, что соединение уже было ранее авторизовано.
Демоны POP3 не такие умные. Они не знают, что аутентификация уже прошла, и все рано требуют пароль. Он передается через шифрованный канал SSH, так что никаких проблем.
Ни UW-IMAP, ни fetchmail не поддерживают по умолчанию GSS, поскольку она требует библиотек с дистрибутива Kerberos V (доступного по FTP с athena-dist.mit.edu). Если они у вас есть, добавьте опцию
--with-gssapi=[/path/to/krb5/root]при собрке. Например, если все библиотеки Kerberos V установлены в каталоге /usr/krb5, то запустите
configure --with-gssapi=/usr/krb5
Настройка аутентификации Kerberos V аходится вне темы этого FAQ (вы можете прочитать статью How to Kerberize your site).
Далее все становится просто. Установите опцию protocol как imap-gss в файле .fetchmailrc, не указывайте никаких паролей, поскольку imap-gss их не треубет. Вы можете, если хотите, указать имя пользователя, но только в том случае, если ваше имя отличается от имени в Kerberos.
Учтите, что в реализации SSL_peek в пакете OpenSSL версий 0.9.5 и более ранних, содержится ошибка, вызывающая зависание fetchmail. Если это случается, установите версию 0.9.6 или более позднюю.
Fetchmail, собранный с поддержкой SSL, поддерживает опции ssl,
sslkey и sslcert, которые управляют
шифрованием SSL. Для их использования вам необходим почтовый сервер, поддерживающий SSL.
Если сеанс OpenSSL умирает с сообщением "PRNG not seeded", обновите версию вашей операционной системы. Это означает, что библиотека OpenSSL на вашей машине не может найти источник случайных битов, посылаемых в генератор случайных чисел; обычно они берутся из /dev/urandom, и это сообщение означает, что ваша ОС не имеет такого устройства
. Для инициализации генератора случайных чисел из клавиатурного ввода может использоваться интерактивная программа. Но поскольку fetchmail проектировался прежде всего для работы в фоновом режиме, эта опция не доступна.
Прежде всего проверьте, можете ли вы соединиться telnet'ом на порт 25 вашей SMTP-машины (обычно `localhost', если вы не переопределили ее опцией smtp в файле .fetchmailrc или в командной строке), и посмотрите на приветственное сообщение. Если SMTP-сервер не отвечает, сначала настройте его.
В Red Hat Linux 6.9, SMTP по умолчанию запрещен. Для исправления этого укажите, set "DAEMON=yes" в файле /etc/sysconfig/sendmail file, затем перезапустите sendmail командой "/sbin/service sendmail restart".
Если сервер работает и проходит тест с telnet, причина может быть вызвана кратковременной перегрузкой SMTP из-за нехватки ресурсов - например, переполнена таблица процессов или какая-нибудь другая проблема не дает процессу сервера открепиться. Если адрес сервера отличен от `localhost', ошибка также может быть вызвана сбоем DNS.
Попробуйте запустить fetchmail -v еще раз; если все нормально, то у вас была какая-то подобная кратковременная ошибка. Вы можете проигнорировать эту ошибку, в следующем сеансе fetchmail примет вашу почту.
Если сервер SMTP проверен, но сбои хронические, у вас серьезная проблема. Один из способов ее решения состоит в использовании опции --mda. Однако, у вас могут быть проблемы с DNS или маршрутизацией TCP. Вы должны точно определить, что происходит перед тем, как что-то предпринимать.
У меня есть одно сообщение (от toby@eskimo.com), что иногда
можно решить эту проблему, объявив smtp с IP-адресом,
отличным от localhost, на который указывет ваша таблица маршрутизации.
Говорят также, что эта ошибка может быть вызвана, если /etc/hosts ассоциирует вашу клиентскую машину более чем с одним IP.
Возможно, что ваш DNS настроен так, что вообще не смотрит в
/etc/hosts. Если вы используете libc5,
посмотрите /etc/resolv.conf; он должен содержать:
order hosts,bind
чтобы файл /etc/hosts просматривался первым.
При использовании GNU libc6, проверьте /etc/nsswitch.conf.
Убедитесь, что в нем указано
hosts: files dns
Если имя вашей машины не указано в /etc/hosts, вы можете сделать telnet на порт 25 и даже отправить письмо адресату используя rcpt to: user@host-not-in-/etc/hosts, но fetchmail не может взаимодействовать с sendmail, не важно какой адрес smtpaddress вы указали.
Некоторые пользователи Linux и fetchmail 2.1 сообщают, что решили эту проблему, удалив ссылку -lresolv из компоновки. Кажется, в некоторых старых дистрибутивах Linux, библиотеки libc и bind работают лучше.
Начиная с 2.2, скрипт конфигурации подстыковывает библиотеку bind только в случае ее реальной необходимоси.
Попробуйте послать письмо самому себе и получить его,добавив опции
`-k -m cat'. Это вызовет вывод всего принимаемого на
стандартный вывод (включая строку Received, добавляемую fetchmail'ом).
Если дамп не соответствует тому, что вы видите в почтовом ящике при настройке MDA, ваш MDA искажает сообщения. Если он не совпадает с тем, что вы послали, это означает сбой в работе fetchmail или сервера.
flex. Эта проблема возникает при наличии
архаичного lex.
Обход: исправьте синтаксис файла .fetchmailrc.
Решение: установите последнюю версию flex от Free Software Foundation.
Обход: линкуйте с GNU malloc вместо библиотечного malloc.
Код malloc() в этой версии сбоит, если несколько функцй free() обращаются к одному и тому же указателю. Это связано с библиотекой С, а не с кодом fetchmail.
Если это случается, то это свидетельствует о проблеме переносимости кода daemon.c, который открепляет процесс fetchmail и переводит его в фоновый режим. Скорее всего это связано с функцией dup() в библиотеке glibc.
В качестве решения проблемы вы можете запускать fetchmail с ключом -N, добавив амперсанд в конце строки:
(fetchmail --nodetach <other params> &)Дополнительная пара скобок имеет важное значение - это обеспечивает открепление процесса от начального интерпретатора. Это важно, если вы интерактивно запустили fetchmail, а потом выходите из оболочки.
/sbin/ifconfig. Если оно больше 600,
измените его в файле /etc/ppp/options. Вот подходящие значения:
mtu 552 mru 552
Другая причина состоит в том, что вы принимаете почту с виртуального почтового сервера, который подключен к разным настоящим серверам, и в каждом цикле приема вы получаете разные адреса IP. Для избежания этого укажите в poll IP-адрес одного из серверов.
На моих машинах с Linux включены временные метки TCP (наверное, сейчас это сделано по умолчанию). Это занимает дополнительные 12 байт сегмента. Когда стартует соединение tcp, другой конец договаривается о MSS 1460, а затем фрагментирует 1460 на сегменты по 1448 и 12 байт, поскольку он не поддерживает временные метки.Затем, по каким-то причинам, после запроса он долго ждет (обычно 2 минуты) перед посылкой следующего (фрагментированного) пакета. Выключение временных меток восстанавливает нормальное функционирование. Для этого выполните команду:
echo 0 > /proc/sys/net/ipv4/tcp_timestamps
Я все еще не понимаю, почему это происходит. По крайней мере, теперь у меня хорошая производительность и отсутствие блокировки очереди.
mda, а ваш MDA
застрял при обработке сообщения. Наилучшее решение проблемы - убрать опцию
mda и передавать почту на порт 25 вашего SMTP-сервера.
Симптом: 'fetchmail -v' нормально получает почту, но зависает сразу после посылки команды MAIL FROM
SMTP> MAIL FROM:
Зависание связано с тем, что sendmail проверяет адрес отправителя в DNS. Эта проблема связана не с fetchmail, а с конфиграцией sendmail. Вы должны включить опции 'nodns' и 'nocanonify' при настройке sendmail.
Вот мое решение для RedHat 7.2:
FEATURE(nodns) FEATURE(nocanonify)
# m4 sendmail-mine.cf > /etc/sendmail.cf
За подробностями обратитесь к файлу /usr/share/sendmail-cf/README.
Симптом: 'fetchmail -v' получает несколько первых сообщений, а потом зависает, сообщая:
fetchmail: SMTP< 550 5.0.0 Access denied fetchmail: SMTP> RSET fetchmail: SMTP< 250 2.0.0 Reset state .......fetchmail: flushed fetchmail: POP3> DELE 1 fetchmail: POP3< +OK marked deleted
Проверьте, не запускаете ли вы соединение с sendmail через TCP wrappers.
Добавление строки 'sendmail : ALL' в файл /etc/hosts.allow может решить эту проблему.
Или вы пытаетесь запустить fetchmail в режиме multidrop под бюджетом root без файла .fetchmailrc. Это не будет работать; смотрите вопрос C1.
Или вы не можете соединиться с SMTP-сервером. Запустите fetchmail -v и посмотрите R1.
Многие POP-серверы в случае прерывания связи восстанавливают всю почтовую очередь где-то через 10 минут. Другие восстанавливают немедленно. Если у вас прервалась связь, скрестите пальцы и попробуйте еще раз минут через десять.
Некоторые серверы (типа Microsoft NTMail) восстанавливают очередь, включая
удаленые вами сообщения. В этом случае попробуйте опцию
--fetchlimit. При этом будет большее количество TCP-соединений,
но изменения в почтовом ящике будут чаще схраняться.
Qualcomm qpopper, используемый во многих системах BSD Unix, лучше себя ведет при разрыве соединения. В этом случае в ответ на QUIT он выполняет все DELE (хотя это нарушение стандартов POP3, но хорошая идея для плохих линий). Затем он восстанавливает в очереди все сообщения, которые загружались во время разрыва. Это может потребовать некоторое время на выполнение столь деликатной операции (fetchmail ждет некотрое время перед повтором для избежания ошибки `lock busy').
Однако, в IMAP2bis есть проблема, при которой собщения отмечаются как прочтенные сразу после завершения их отправки. Если по каким-то причинам сообщение не доставлено локально (разрыв связи, переполнение диска и т.д.), эти "прочтенные" сообщения останутся на сервере навечно.
Обход: добавьте опцию `fetchall'
Решение: установите сервер IMAP4.
Эти ошибки связаны с проблемами в настройке DNS либо на сервере, либо на клиенте.
Самый простой способ обхода этой проблемы - добавить опцию `via'
(если нужно) и объявить в "aka" все псевдонимы вашего почтового сервера,
а затем указать `no dns'. Это заставит не обращаться к DNS
(хотя может оказаться незабранная почта, если вы пропустите какой-нибудь
псевдоним почтового сервера).
Конечно, лучше подкорректировать ваш DNS. Эти ошибки DNS могут проявляться совершенно разными способами, например, делая вашу машину недоступной для остальной части сети.
Иногда эти ошибки свидетельствуют о проблемах разборки адресов в заголовках, описанных в M7.
В общем, это не вполне хорошая идея. Лучше оставить почту в почтовом ящике на сервере, и использовать режимы ETRN или ODMR для периодического переключения SMTP (конечно, это означает, что вам следует запрашивать почту чаще времени устаревания на сервере). Если вы не можете это настроить, попробуйте UUCP.
Если никакая из этих альтернатив не подходит, используйте режим
multidrop (хотя у вас возникнут проблемы с почтой от программ
списков рассылок). Если хотите попробовать,
делайте это с указанием опции
`localdomains'.
В общем случае, при испольовании localdomains вы должны учитывать следующее:
1. Вы настроили ваш .fetchmailrc на режим multidrop.
Многие указывают список `localdomains' , но забывают, что
fetchmail перед началом разборки почты
хочет видеть не только одно имя (или `*')
в списке `here'.
2. Вы должны указать `no envelope'.
Обычно multidrop пытается определить адрес конверта из сообщения до обработки строк To/Cc/Bcc (чтобы избежать потерю почты в случае, когда программа ведения списка рассылки не указывает в To: адрес получателя).
Поскольку в один ящик стекаются все сообщения для всего домена,
адрес конверта будет один и тот же, что делает его непригодным для
дальнейшей маршрутизации почты. Вы можете установить опцию
`no envelope', чтобы fetchmail не обращал внимания на адрес конверта.
Также загляните в ответ T1 .
Если вы используете sendmail, вы можете проверить раскрытие списка командой
sendmail -bv.
Один из пользователей Linux (другой, чем в R1!) сообщил, что решил эту проблему удалением опции -lresolv из линкера и пересборкой fetchmail.
Используйте опцию `aka' для предварительного
объявления всех возможных имен DNS вашего почтового сервера.
Если вы уверены, что все перечислили в "aka", можете добавить опцию
`no dns' для полного отключения поиска имен в DNS.
Иногда паузы неизбежны. Некоторые серверы SMTP могут обращаться к DNS при проверке адресов в заголовках From.
Чтобы sendmail выполнял управляющие команды из файла псевдонимов majordomo, надо дать sendmail'у знать, что вся почта, которая ему поступает, предназначена локальному пользователю. Настройка виртуальных доменов вызывает доставку в почтовый ящик, объявленный по умолчанию, а не через majordomo.
Michael <michael@bizsystems.com> дал нам рецепт на этот случай:
poll your.pop3.server proto pop3:
no envelope no dns
localdomains virtual.localdomain1.com virtual.localdomain2.com ...
user yourISPusername is root * here,
password yourISPpassword fetchall
Кроме того, подправьте ваш sendmail.cf следующим образом:
############################################# # virtual info, local hack for ruleset 98 # ############################################# # domains to treat as direct mapped local domain CVvirtual.localdomain1.com virtual.localdomain2.com ... --------------------------- in ruleset 98 add ------------------------- # handle virtual users R$+ <@ $=V . > $: $1 < @ $j . > R< @ > $+ < @ $=V . > $: $1 < @ $j . > R< @ > $+ $: $1 R< error : $- $+ > $* $#error $@ $1 $: $2 R< $+ > $+ < @ $+ > $: $>97 $1
Этот набор правил обрезает имена доменов из адресов приходящей почты. Вам необходим sendmail 8.8 или более поздний. Michael говоит:
Я использую эту схему с двумя виртуальными доменами и умолчательным user+domain у провайдера, обслуживаю около 30 бюджетов и majordomo на моем POP3-сервере, использую sendmail 8.83
Возможно, fetchmail не может определить адрес конверта в заголовках "Received:" . Тому могут быть две причины.
Во первых, fetchmail может смотреть в неправильных заголовках Received.
Обычно он ищет только в первом, но некотороые серверы добавляют строки,
которые необходимо пропустить.
Для этого используйте опцию
`envelope' с числом пропускаемых заголовков, например
`envelope 1 Received' или `envelope 2
Received'.
При разборке строк Received, выглядящих как
Received: from send103.yahoomail.com (send103.yahoomail.com [205.180.60.92])
by iserv.ttns.net (8.8.5/8.8.5) with SMTP id RAA10088
for <ksturgeon@fbceg.org>; Wed, 9 Sep 1998 17:01:59 -0700
fetchmal проверяет в DNS, является ли `iserv.ttns.net' псевднимом
вашего почтового сервера, перед тем как счиатать
`ksturgeon@fbceg.org' адресом конверта. Это проверка может оказаться неудачной,
если ваш DNS неправильно настроен, или вы используете опцию `no dns'.
Это последствия multidrop. Что происходит, если N пользователей подписаны на один и тот же список рассылки? Программа рассылки отсылает N копий, не зная, что они попадут в один и тот же ящик. Поскольку они локально адресуются всем N пользователям, fetchmail направит каждому N копий.
Fetchmail пытается избежать дублирования смежных сообщений. Однако, эта логика основана на идентичности идентификаторов сообщений (message-ID), во всех копиях.
Я мог бы избежать этой проблемы, сохраняя список всех принятых идентификаторов. Проблема состоит в том, что это потребует O(N**2) операций и сильно замедлит прием больших пакетов почты.
Скорее всего, что POP/IMAP-сервер вставляет заголовок, не описанный в RFC822 (например, X-POP3-Rcpt:), а какой-то агент на пути прохождения почты (часто старая версия программы deliver), не может распознать его как заголовок.
Это не проблема fetchmail. Прежде всего установите последнюю версию
программы deliver. Если это не помогает, попытайтесь представить,
какая еще программа на пути прохождения почты может это сделать.
Если не можете - попробуйте другой MDA (например, procmail) и укажите его
в опции `mda'.
Прежде всего прочитайте X1. Это аналогичная проблема, связанная со старыми версиями программ доставки почты.
Книга O'Reilly про sendmail не предупреждает, что IDA sendmail некорректно обрабатывает X-заголовки. Если это ваша проблема, замените IDA sendmail, потому что он дырявый и не соответствует RFC822.
Если вы уверены, что сообщения в почтовом ящике на сервере целые, то это означает проблему с сервером POP/IMAP,вашим локальным SMTP-сервером, или доставочным агентом. fetchmail не может разрезать сообщения.
Неоторые POP-серверы игнорируют заголовки Content-Length и разбивают сообщения по строке From. Это обнаружено в BSD popper версии 2.1 (вкодящую в дистрибутив Solaris 2.5).
Sendmail и другие серверы SMTP вообще не разбивают сообщения. Скорее, это связано с локальным агентом доставки или программой чтения почты.
Если вы не можете заменить упирающуюся программу, загляните в ваш файл sendmail.cf file. Там вы увидите что-то вроде этого:
Mlocal, P=/usr/bin/procmail, F=lsDFMShP, S=10, R=20/40, A=procmail -Y -d $uЭта строка описывает ваш агент локальной доставки. Попробуйте вставить букву 'E' в строку флагов (F=...). Это заставить sendmail преобразовывать все опасные строки, начинающиеся с "From", в ">From".
Прежде всего выясните, какая программа это делает. Нам надоело получать почту об ошибках в fetchmail, когда на самом деле они связаны с другими программами.
Существуют пять основных компонентов, стоящих на пути прохождения почты:
mda.
Чаще всего с fetchmail все в порядке, но использование его обнаруживают ошибку, сделанную предыдущей программой. Вам нужно точно выяснить, на каком этапе испортилось сообщение.
Прежде всего пошлите самому себе сообщение и примите его, указав в .fetchmailrc:
mda "cat >MBOX" keep fetchall
Тогда все, чтобудет принимать fetchmail, отобразится на экране,
кроме (а) дополнительной строки Received, добавляемой fetchmail,
(б) изменения адресов опцией rewrite и (в)
конечных изменений, делаемых опциями
forcecr и stripcr.
MBOX будет содержать весь вывод fetchmail.
Чаще всего проблема связана с низлежашей программой. Если MBOX не искажен, значит проблема не связана с fetchmail. Прочитайте остальные разделы FAQ.
Если MBOX выглядет искаженным, вам следует сравнить его содержимое
с тем, что есть на почтовом сервере. Поэтому вам надо указать опцию
keep, чтобы оставить копию сообщения на сервере.
Если почтовый ящик искажен, значит это сделала предыдущая программа .
К сожалению, тут вы мало что можете сделать, кроме как обратиться к
администратору сервера.
Менее вероятно, что на сервере все в порядке. В этом случае проблема либо с сервером POP/IMAP, либо с fetchmail. Чтобы определить виноватого, зайдите telnet'ом на сервер и эмулируйте сеанс fetchmail. Это не очень сложно, POP3 и IMAP - это простые текстовые протоколы. Обращайте внимание на детали. Как модель для сеанса, вы можете запустить fetchmail -v, но помните, что "*" в командах LOGIN или PASS - это ваш пароль.
Итак, вы видите то же, что видит fetchmail. Если вы видите искаженное сообщение, то это ошибка сервера. Обратитесь к его администратору. Мы хотим знать о таких серверах и предупреждать пользователей, поэтому отправьте нам протокол сеанса, включив строку приветствия сервера.
Если же сообщение выглядит неискаженным, поздравляю. Вы нашли ошибку в fetchmail, которая очень редка в наши дни. Сообщите нам о ней и мы ее исправим. Приложите протокол сеанса вместе с другими материалами, изложенными в разделе Как сообщить об ошибке.
Это может случаться при использовании версий fetchmail с 4.4.1 по 4.4.8. Они использовали команду TOP вместо RETR, чтобы избежать метки сообщений как прочтенных (для последующего приема).
Версии с 4.4.2 по 4.4.7 плохо взаимодействовали с Eudora qpopper версий 2.3 и более поздних. Проверка TOP сбоила из-за переполнения аргумента команды TOP.
Решение: Обновите версию fetchmail.
Обход: установите опцию fetchall.
Это делает не fetchmail; он никогда не удаляет строки из заголовка или тела сообщения. Это может делать ваш POP-сервер или почтовый агент отправителя (или оба).
Известно, что серверы Mail Max POP3 и InterChange Imail IMAP иногда отбрасывают прикрепления при отсылке сообщения. Это случается также с Microsoft Exchange и Outlook. Сервера на базе Windows- и NT словно специально сделаны для искажения прикреплений. Если у вас есть один из таких, замените его на Unix-машину.
Сообщают, что Lotus Notes иногда коверкает прикрепления MIME. В частности, он преобразует application/pdf в application/octet-stream.
Сервис IMAP на Lotus Domino имеет известую ошибку при генерации заголовков Content-type (замечено в Lotus Domino 5.0.2b). Это незаметно, когда Netscape Messenger и другие агенты используют FETCH BODY[] для приема всего сообщения. Когда fetchmail использует FETCH RFC822.HEADER и FETCH RFC822.TEXT для получения одного заголовка, Domino генерирует другие теги Boundary для каждой части, т.е. один тэг объявляется в заголовке Content-type, а другой используется для разделения MIME-частей в теле. Это не работает. Говорят, это исправлено в Domino release 6.
Еще один богатый источник проблем - это Microsoft Exchange и Microsoft Outlook. Если вы видите нечитаемые прикрепления с Content-Type "application/x-tnef", то у вас как раз эта проблема. Вам может помочь утилита TNEF.
Rob Funk объясняет: К сожалению, существует много пользовательских почтовых программ, которые пишут некорректные сообщения MIME. Одним из таких является Sun MailTool, который формирует прикрепления, которые выглядят как MIME, но сбивают с толку другие программы.
Одним из решением проблем, связанных с неправильно сформированными MIME-прикреплениями, является программа emil ; почитайте руководство по ней руководство Она полезна для преобразования кодировок (charset), кодирования прикреплений.
Хорошо использовать emil из procmail. Вам следует обратить внимание на признаки проблемных сообщений и передать их через канал (pipe) через emil для исправления. emil не всегда справляется с задачей, в этом случае сообщение остается нетронутым.
Вот правило, которое можно вставить в .procmailrc:
:0HB
* 1^1 ^Content-Type: \/X-sun[^;]*
* 1^1 ^Content-Type: \/application/mac-binhex[^;]*
* 1^1 ^Content-Transfer-Encoding: \/x-binhex[^;]*
* 1^1 ^Content-Transfer-Encoding: \/x-uuencode[^;]*
{
LOG="Converting $MATCH
"
:0fw
| emil -A B -T Q -B BA -C iso-8859-1 -H Q -F MIME \
| gawk '{gsub(/\r\n?/,"\n");print $0}'
}
"1^1" в условии - это способ указать, что если одно из четырех указанных выражений найдено в сообщении, общий результат считается истиной, и сообщение передается emil. Эти четыре выражения проверяют прикрепления Sun, binhex или uuencode. Строка "LOG=" вызывает запись в лог-файл. Следующая за ней строка из одной двойной кавычки обеспечивает добавление сивола новой строки к строке, записываемой в лог-файл. Вызов gawk используется для исправления преобразования концов строк.
Вызов emil подразумевает, что в сообщении найдено:
Это не проблема fetchmail; он вообще ничего не знает о почтовых прикреплениях и не обрабатывает их каким-то особым образом.
Чаще всего это случается из-за ошибок в способности траспортной оболочки TCP/IP обрабатывать очень большие пакеты TCP/IP. Вы можете проверить эту теорию, попробовав загрузить проблемное сообщение по FTP или через web-почту.
Эта ошибка может быть связана также с оболочкой сборки пакетов TCP/IP, при неверно настроенном MTU discovery на почтовом сервере. Или, если используется модем, его могут смутить наличие в сообщении строки "+++".
Черт бы побрал эту вонючую кучу дерьма под названием Microsoft Exchange. Из-за проблемы, описанной в S2, поддержка IMAP в fetchmail не может на 100% соответствовать протоколу IMAP. В большинстве случаев это не имеет значения, но если вы комбинируете его с SMTP-сервером со странным поведением, вы получите ")" в конце письма.
Одним из таких серверов являетсяe Interchange mail server, используемый, например, в mailandnews.com. Вот что происходит:
1. Кто-то посылает вам письмо. Последняя строка сообщения содержит тест. На уровне SMTP сообщение заканчивается, например, так: "blahblah\r\n.\r\n"
2. Сервер SMTP видит завершающую строку "\r\n.\r\n" и распознает ее как конец сообщения. Однако, вместо того чтобы как обычно отбросить ".\r\n" и оставить одну пару "\r\n" в теле сообщения, Interchange отбрасывает весь кусок "\r\n.\r\n", осталяя тело сообщения без символа завершения строки. RFC821 не запрещает этого, хотя должен бы.
3. Fetchmail или другой клиент IMAP запрашивает сообщение. IMAP возвращает его, но заключает в скобки, в соответствие со стандартом протокола. Также присутствует размер сообщения в байтах. Поскольку сообщение не заканчивается символом завершения строки, клиент IMAP видит: ....blahblah)... где ')' идет от IMAP.
4. Fetchmail работает только с целыми строками и не может доверять размеру письма, поскольку Microsoft Exchange его неверно сообщает.
5. В результате fetchmail получает окончательное 'blahblah)' и помещает его в конец сообщения, передаваемого дальше. Если вы включите отладку, то заметите сообщение actual != expected.
Избавиться от этого нелья.
Это особенность, а не ошибка. Это нормальная практика для системных демонов, позволяющая выключить журнализацию удалением лог-файла. Чтобы создать файл, перед запусом fetchmail выполните touch с именем лог-файла.
Fetchmail использует для окончательной доставки локальный sendmail, а Netscape и другие клиенты - нет; объявление о поступлении новых сообщений выполняется демоном, которому sendmail дает сигнал. Это скорее всего ``biff''. Дайте команду
biff nдля выключения уведомления. Если это не сработает, попробуйте команду
chmod -x `tty`Если и это не работает, закомментируйте все ссылки на ``comsat'' в файле /etc/inetd.conf и перезапустите inetd.
В Slackware Linux последняя строка файла /etc/profile выглядит как
biff yИзмените ее на
biff n
Нет, но версии начиная с 5.2.2 обнаруживают факт модификации файла и перезапускаются, перечитывая его заново.
Потому что вы используете POP3, отличный от Qualcomm qpopper, или IMAP с большим интервалом expunge.
В соответствии со стандартами POP3, реальные удаления присходят только после команды QUIT. Fetchmail ничего не может с этим поделать. Вот возможные пути решения:
Перейти на qpopper (бесплатный сервер POP3 от Qualcomm, разработчика Eudora). qpopper нарушает стандарты POP3 выполнением expunge (полное удаление сообщений, помеченных на удаление) при разрыве связи, а также после QUIT.
Перейти на IMAP.
Потому что запись в лог-файл основана на адресе из MAIL FROM, а некоторые SMTP-серверы очень к этому чувствительны.
Некоторые SMTP-серверы сбоят, если вы попытаетесь указать в команде MAIL FROM адрес с именем машины, отличающимся от адреса инициатора соединения. Это не ошибка, а особенность. Это предотвращает отправку почты с фиктивных адресов.
Поскольку инициатором доставки является localhost, это заставит SMTP-серверы возмущаться на каждый адрес в MAIL FROM, содержащий символ @.
Sendmail выполняет проверку адреса в DNS всякий раз, когда получает команду HELO.
Причиной этой проблемы является неверная настройка или сбои в DNS.
Проверьте файлы /etc/resolv.conf и
/etc/hosts. Убедитесь, что имя машины и полное доменное
имя машины присутствуют в /etc/hosts. Также стоит включить
туда же и адрес удаленного почтового сервера.
Вы можете отключить проверку в DNS, переконфигурировав sendmail
с опцией FEATURE(nodns).
Также может помочь правильная настрока DNS для кеширования запросов, это ускорит и другие сервисы. Может помочь и переход на более быстрые MTA, например, qmail или exim.
Потому что получает в том порядке, в котором выдает сервер.
Теоретически возможно при использовании IMAP сортировать сообщения по дате, но это будет нарушеием основ философии проектирования fetchmail: (a) как простого и прозрачного транспорта, и (б) скорее скрытием, чем подчеркиванием разницы между удаленными протоколами.
В любом случае, пользовательские почтовые агенты могут сами сортировать почту.
Это может быть вызвано совокупностью разных причин. Если вы настроили в pppd дозвон по требованию (demand dialing), а pppd имеет установленные опции idle и lcp-echo-interval, то значение lcp-echo-interval должно быть больше, чем idle. В противном случае счетчик пакетов, от которого зависит fetchmail, будет постоянно увеличиваться, вызывая включение fetchmail с его собственной частотой, не давая pppd достичь своего интервала неактивности.
Проверьте, не включены ли опции keep и fetchall. Если да, то выключите keep.
Одна из причин связана со свойсвом UIDL протокола POP3, когда ваши сообщения снова становятся видимыми после разрыва связи. Я пытался это исправить и потратил массу времени на кодирование, но это фундаментальная проблема; очень сложно вести список UIDL на стороне клиента. Того, кто включил UIDL в RFC1725 и убрал команду LAST, следует отдать на съедение скорпионам. Правильным ответом будет (а) жить дальше и терпеть временные неудобства или (б) перейти на IMAP4, или (в) самому исправить код и выслать мне патч. Кроме (в) я ничего не хочу слышать.
Это может случиться и с другими почтовыми клиентами, использующих простую схему исключительной локировки (это делают большинство серверов POP3). fetchmail может принимать сообщения, но поскольку почтовый ящик заблокирован другой копией fetchmail, вы не сможете ни пометить сообщения как прочтенные, ни удалить их. Решение: (a) подождать заврешения работы клиента, или (б) завершить его.
James Stevens <James.Stevens@kyzo.com> пишет:
У нас есть Linux, звонящий в инернет и забирающий почту
с POP3 сервера на базе WindowsNT.
Fetchmail корректно принимает и удаляет почту. Однако, наше
телефонное соединение нестабильно и часто разрывается в середине
сеанса приема.
Интересно, если корректно не завершить TCP-соединение с POP3
(кажется, командой "QUIT"), NT восстанавливает все удаленные сообщения!
Это означает, что если первое письмо было очень большим,
мы можем бесконечно его принимать.
Наше решение состоит в том, чтобы заставить fetchmail
принимать небольшое количество сообщений за один сеанс (5-10),
чтобы обеспечить корректное закрытие соединения.