Справочное руководство по Fetchmail.

fetchmail - прием почты с серверов POP, IMAP, ETRN, или ODMR

СОДЕРЖАНИЕ

Краткий обзор

Описание

Операции

Общие опции

Опции приема

Опции протоколов и запросов

Опции доставки

Опции управления ограничениями

Опции аутентификации

Прочие опции

Аутентификация и шифрование

Режим демона

Административные опции

Сбои при приеме почты

Фильтрация спама

Обработка ошибок SMTP/ESMTP

Управляющий файл

Синтаксис

Poll vs. Skip

Сводка по ключам и опциям

Ключи, не соответствующие опциям

Прочие управляющие опции

Соответствие RFCc 822

Примеры настройки

Использование с доменными (multidrop) ящиками

Адреса в конвертах и заголовках

Хорошие способы использоания доменных ящиков

Плохие способы использования доменных ящиков

Ускорение проверки доменных ящиков

Коды возврата

Файлы Сигналы

Известные ошибки

КРАТКИЙ ОБЗОР

fetchmail [опция...] [сервер...]

fetchmailconf

ОПИСАНИЕ

fetchmail - это утилита приема и пересылки почты; она забирает почту с удаленных почтовых серверов и передает ее локальной системе доставки почты на машине клиента. После этого вы можете читать почту обычными почтовыми агентами, например, mutt, elm или Mail. Утилита fetchmail может быть запущена в режиме демона для регулярной проверки и приема почты с одного или нескольких серверов.

fetchmail может забирать почту с серверов, поддерживающих любой протокол приема почты: POP2, POP3, IMAP2bis, IMAP4, IMAPrev1. Он также поддерживает расширения ESMTP ETRN и ODMR.

Хотя fetchmail проектировался для использования на периодических сеансах TCP/IP (например, соединения по протоколам SLIP или PPP), он может использоваться для доставки почты в защищенных системах, где запрещены соединения по SMTP с sendmail.

Каждое сообщение, принятое fetchmail, затем обычно пересылается по SMTP на порт 25 локальной машины, на которой он запущен (localhost), как будто это сообщение было принято по обычному каналу TCP/IP. Затем почта доставляется локально системным транспортным агентом (MDA - Mail Delivery Agent, обычно это sendmail, но можно использовать smail, mmdf, exim, qmail). Все механизмы управления доставкой (например, файлы .forward), обрабатываются системным MDA, и после этого срабатвают агенты локальной доставки почты.

Если порт 25 не доступен, а fetchmail знает о надежном локальном MDA, то этот MDA и будет использован для локальной доставки. Вот время сборки fetchmail обычно ищет исполняемые файлы. procmail и sendmail

Если у вас есть программа fetchmailconf, она может помочь в настройке и редактировании конфигурационного файла fetchmailrc. Она работает под X и требует установленных Python и Tk. Если вы настраиваете fetchmail для одного пользователя, выберите режим Novice. Режим Expert предоставляет полный контроль в настройке fetchmail, включая управление доменными (maildrop) ящиками. В любом случае, кнопка Autoprobe определит наилучший протокол, который поддерживает ваш почтовый сервер и предупредит о потенциальных проблемах.

ОПЕРАЦИИ

Поведение fetchmail управляется опциями командной строки и кофигурационным файлом, ~/.fetchmailrc, синтаксис которого будет рассмотрен ниже (именно этот файл редактирует программа fetchmailconf). Опции командной строки имеют более высокий приоритет над опциями в ~/.fetchmailrc.

При запуске fetchmail запрашивается каждый сервер, указанный в командной строке. Если сервера в командной строке не указаны, их имена берутся из файла ~/.fetchmailrc.

Для облегчения использования fetchmail в скриптах и потоках, он возвращает код завершения.

Большинство опций имеют соответствующее ключевое слово, используемое в файле fetchmailrc.

Здесь не охвачены некоторые специфические опции; они перенесены в разделы "Аутентификация" и "Режим демона".

Опции протоколов и запроса

Опции доставки

Опции управления ограничениями

Опции аутентификации

Прочие опции

АУТЕНТИФИКАЦИЯ ПОЛЬЗОВАТЕЛЕЙ И ШИФРОВАНИЕ

Во всех режимах, кроме ETRN, необходима аутентификация клиента. Обычная аутентификация пользователя в fetchmail сходна с механизмом, используемом в ftp. Проверка правильности идентификатора пользователя и пароля зависит от применяемой на почтовом сервере системы безопасности.

Если почтовый сервер является Unix-машиной, на которой вы имеете свою учетную запись, fetchmail будет использовать ваши обычные имя и пароль. Если вы используете одно и то же имя и на сервере, и на клиенте, вам можно не указывать идентификатор пользователя в опции -u -- по умолчанию используется ваше имя на клиентской машине. Если же на сервере используется другое, укажите его в опции -u. Например, если ваше учетное имя ’jsmith’ на машине с именем ’mailgrunt’, вы можете запсутить fetchmail следующим образом:

По умолчанию fetchmail интерактивно запрашивает ваш пароль перед установлением соединения. Это самый безопасный способ использования fetchmail; он обеспечивает, что ваш пароль не будет скомпрометирован. Однако, вы можете указать свой пароль в файле ~/.fetchmailrc. Это полезно при запуске fetchmail в режиме демона или в скриптах.

Если вы не указали пароль, и fetchmail не обнаружил его в вашем файле ~/.fetchmailrc, то будет предпринята попытка выудить пароль из файла ~/.netrc в вашем домашнем каталоге, и только потом будет сделан интерактивный запрос. Первым делом Fetchmail смотрит на соответствие имени в опции poll; если не найдено, проверяется имя в via. Синтаксис файла ~/.netrc описан в документации по ftp.

На почтовых серверах, не содержащих обычных бюджетов пользователей, ваш идентификатор и пароль обычно присваиваются администратором сервера при открытии почтового ящика. Если вы не знаете свой идентификатор и пароль для доступа к почтовому ящику, обратитесь к своему администратору.

Ранние версии POP3 (RFC1081, RFC1225) использовали грубую форму аутентификции с использованием на стороне сервера файла rhosts. В варианте RPOP на сервер через специальный порт подается эквивалент пароля, а серверу вместо команды PASS посылается команда RPOP, чтобы тот предпринял соответствующую проверку. RPOP поддерживается в fetchmail (укажите опцию ‘protocol RPOP’), но настоятельно не рекомендуется использовать, поскольку с помощью спуфинга такой пароль легко перехватить.

RFC1460 проедлагает утентификацию APOP. В этом варианте POP3 вы регистрируете пароль APOP на сервере (для этого есть специальная программа popauth), и помещаете свой пароль в файл ~/.fetchmailrc. При каждой регистрации fetchmail на сервере, он посылает зашифрованный хеш вашего пароля и времени сервера, который затем проверяется в базе данных.

Если fetchmail собран с поддержкой Kerberos, и вы указываете аутентификацию Kerberos (опцией --auth или опцией authenticate kerberos_v4 в файле .fetchmailrc ), fetchmail при каждом приеме почты пытается получить у почтового сервера билет Kerberos. Если в параметрах poll или via указано значение ‘hesiod’, то fetchmail попытается использовать Hesiod для поиска сервера.

При использовании POP3 или IMAP с аутентификацией GSSAPI, fetchmail проверит, поддерживает ли почтовый сервер функции GSSAPI (описанные в RFC1731 и RFC1734), и в случае положительного результат будет их использовать. В настоящее время это проверено только для Kerberos V, поэтому одидается, что у вс уже есть нужный билет Kerberos. Вы можете передать имя пользователя, отличающееся от стандартного, через опцию --user или через ключевое слово user в .fetchmailrc.

Если демон IMAP во время аутентификаиции возвращает ответ PREAUTH, fetchmail распознает это и пропускает стандартный этап аутентификации. Это может быть полезно при запсуске imapd вместе с ssh. В этом случае вы можете объявить значение аутенификации ‘ssh’, это предупредит запрос у вас пароля при запуске fetchmail.

Если вы используете POP3, а сервер посылает одноразовый пароль в соответствии с RFC1938, fetchmail будет использовать ваш пароль как фразу для генерации ответа. Это предотвращает пересылку паролей в открытом виде.

Поддерживается также аутентификация Compuserve’s RPA (сходная с APOP). Если вы включили в fetchmail ее поддержку, то вместо посылки незашифрованного пароля производится аутентификация RPA, если в имени узла обнаруживается "@compuserve.com".

Если вы используете IMAP, то поддерживается также Microsoft’s NTLM (применяется в Microsoft Exchange). Если вы включили в fetchmail ее поддержку, fetchmail пробует провести аутентификацию NTLM (вместо посылки открытого пароля) всякий раз, когда сервер на запрос его возможностей отвечает AUTH=NTLM. Опция user указываетс в виде ‘user@domain’: левая часть до @ (user) - это имя польователя, а правая часть (domain)- имя домена NTLM.

При использовании IPSec, можно указать опцию -T (--netsec) для передачи защищенного запроса, используемого при инициализации исходящего соедиения IP. Значение этой опции - строка, передаваемая параметром в функцию net_security_strtorequest() библиотеки inet6_apps.

Доступ к функциям шифрации осуществляется указанием опции --ssl или ключевого слова "ssl" в файле .fetchmailrc. При включенном SSL все запросы посылаются после установления SSL-соединения. Некоторые сервисы,например, POP3 и IMAP, используют номера портов отличные, чем SSL. Номера защищенных портов выбираются автоматически.

При установлении соединения с сервером SSL, сервер предъявляет клиенту для проверки сертификат. Сертификат проверяется на предмет соответствия имени сервера в сертификате настоящему имени сервера, а также проверяетя срок действия сетрификата. Если любое из этих правил не подтверждается, выводится предупреждение, но соединение продолжается. Сертификат сервера не обязательно должен быть подписан специальной Службой Сертификации, это может быть "самоподписанный" сертификат.

Некоторые SSL-серверы могут затребовать сертификат клиента. В этом случае можно указать размещение сертификата и личного ключа. Сертификат клиента направляется на сервер для проверки. Если сертификат отсутствует или неверен, соединение может быть прекращено. Некоторые серверы также требуют, чтобы сертификаты были подписаны известной Службой Сертификации.

И, наконец, последнее слово об использовании SSL: хотя описанный метод с использованием самопальных сертификатов и защищает от пассивных наблюдателей, он не спасает от активных атак. Конечно, этот гораздо лучше пересылки открытых паролей, но вы должны всегда учитывать атаку "промежуточного звена" (например, такими утилитами, как dsniff http://www.monkey.org/~dugsong/dsniff/). Если вы беспокоитесь о безопасности вашего почтового ящика, используйте туннелирование ssh (ниже есть примеры).

РЕЖИМ ДЕМОНА

Опции --daemon <interval> или -d <interval> запускают fetchmail в режиме демона. В качестве interval укажите числовой аргумент - это интервал приема почты в секундах.

В режиме демона fetchmail переводит себя в фоновый режим и работает бесконечно, запрашивая указанный узел, а затем засыпая на указанный период времени.

Напрмер, при зарпуксе

fetchmail будет опрашивать все почтовые сервера, пересисленные в вашем файле ~/.fetchmailrc (кроме содержащих ключевое слово skip), каждые 15 минут.

Можно также указать интервал выборки в файле ~/.fetchmailrc, задав опцию ‘set daemon <interval>’, где <interval> - это целое число секунд. В этом случае fetchmail всегда будет стартовать в режиме демона, если вы не переопределите это в командной строке опцией --daemon 0 или -d0.

В режиме демона возможен только один процесс на каждого пользователя, для обеспечения этого fetchmail создает файлы локировки.

Обычно вызов fetchmail с опцией daemon в фоновом режиме посылает сигнал демону, вызывая немедленный запрос почтового сервера. Для этого служит сигнал SIGHUP, если fetchmail запущен от root, или SIGUSR1 в противном случае. При этом также очищаются все флаги "заклинивания", установленные ранее при неудачной аутентификации или многличсленных таймаутах.

Опция --quit прекращает работу демона. Она используется только в командной строке.

Эта опция может быть использована совместно с другими опциями; она останавливает работу работающего демона до того, как сработают остальные опции командной строки в комбинации с настройками конфигурационного файла.

Опция -L <filename> или --logfile <filename> (ключ: set logfile) позволяет направить информационные сообщения в указанный лог-файл, имя которого указывается в качестве аргумента filename. Лог-файл открывается на добавление, поэтому предыдущие сообщения не удаляются. Эта опция используется в основном для отладки.

Опция --syslog (ключ: set syslog) задает направление всех информационных сообщений и сообщений об ошибках в демон syslog. Сообщения записываются с идентификатором fetchmail, уровнем LOG_MAIL, и приоритетом LOG_ERR, LOG_ALERT или LOG_INFO. Эта опция предназначена для записи состояния и сообщений об ошибках во время приема почты с сервера. Сообщения об ошибках командной строки или во время проверки .fetchmailrc все равно выдаются на stderr или в указанный файл журнала.

Опция --nosyslog отключает использование syslog, подраземевая, что это было включено в ~/.fetchmailrc или в командной строке через -L или --logfile <file>

Опция -N или --nodetach предотвращает перевод процесса в фоновый режим и открепление от управляющего терминала. Обычно используется при отладке. Учтите, что в этом случае опция logfile игнорируется.

При приеме почты в режиме демона с сервера POP2 или IPAP2bis, временные ошибки (например, сбой DNS или отказ sendmail доставить почту) могут принудительно включить опцию fetchall при следующем сеансе приема почты. Это означает, что если сообщение принято (и помечено на сервере как прочтенное), но локально не доставлено, в следующем сеансе приема почты оно будет приянто повторно (IMAP не удаляет сообщения с сервера, пока они не будут доставлены, так что там такой проблемы не возникает).

Если вы изменили или тронули файл ~/.fetchmailrc во время работы демона, это обнаруживается при следующем сеансе приема почты; тогда fetchmail заново считывает настройки и перезапускает себя (используя exec())

АДИМИНИСТРАТИВНЫЕ ОПЦИИ

Опция --postmaster <name> (ключ: set postmaster) задает имя пользователя, которому будет направлена почта в случае, когда не удалось определить локального получателя. Обычно это пользователь, запустивший fetchmail. Если это root, то принимается значение ‘postmaster’. Пустая строка вызывает уничтожение подобной почты.

Опция --nobounce предотвращает обычную отправку сообщений об ошибках отправителю письма. Если nobounce включено (on), то сообщение посылается пользователю postmaster.

Опция --invisible (ключ: set invisible) пытается сделать fetchmail невидимым. Обычно fetchmail выступает в роли обычного траспортного агента (MTA) - он моздает заголовок Received и указывает MTA, доставляющего почту, что она пришла от fetchmail. Если invisible включено (on), соответствующий заголовок Received не создается, и fetchmail пытается заставить агента доставки думать, что почта пришла непосредственно с почтового сервера.

Опция --showdots (ключ: set showdots) заставляет fetchmail рисовать точки (инидикатор прогресса), даже если текущий терминал не является stdout (например, лог-файл). Начиная с версии 5.3.0 точки выводятся только на stdout.

Указав опцию --tracepolls, вы можете заставить fetchmail добавить информацию в заголовок Received в виде "polling {label} account {user}", где {label} - это метка учетной записи из указанного конфигурационного файла, обычно ~/.fetchmailrc, {user} - имя пользователя, используемое для регистрации на почтовом сервере. Этот заголовк может быть полезен для сортировки почты по разным почтовым ящикам (например, в случае, когда вы получаете письмо с сервера, ведущего список рассылки, и подписаны на этот список рассылки). По умолчанию такого заголовка не добавляется. В файле .fetchmailrc ключевое слово ‘tracepolls’.

СБОИ ПРИ ПРИЕМЕ ПОЧТЫ

Протоколы, используемые fetchmail при общении с почтовыми серверами, очень надежны. Обычно при пересылке на порт 25 сообщения не удаляются (и даже не метятся на удаление) на сервере до тех пор, пока агент SMTP не даст fetchmail'у подтверждения о том, что сообщение принято к доставке или отвергнуто по причине спама.

Тем не менее, при пересылке на MDA всегда вероятны сбои. Некоторые MDA достаточно надежны и возвращают ненулевой код возврата в случае ошибки, даже по причине нехватки ресурсов. К таким принадлежат procmail, sendmail, exim. Эти программы возвращают надежное подтверждение и могут использоваться без риска потери почты. Небезопасные MDA могут возвращать 0 даже при сбое в доставке. В таком случае вы потеряете почту.

В обычном режиме fetchmail пытается принять только новые сообщения, оставить нетронутыми (и не удаляя) сообщения, которые вы прочитали непосредственно на сервере (или принятые в предыдущем сеансе fetchmail с опцией --keep). Однако, вы можете обнаружить, что прочтенные сообщения принимаютя и удаляются, даже если вы не указали опцию --all. Вот возможные причины этого.

Одной из них является использование протокола POP2. В этом протоколе не поддерживаются состояния сообщений ‘new’ или ‘old’, поэтому fetchmail считает все сообщения всякий раз новыми. Но это маловероятно, т.к. POP2 устарел и редко используется.

POP3 и RFC1725. В этой версии протокола POP3 нет команды LAST, но некоторые серверы POP3 следуют этому (это можно проверить, запустив "fetchmail -v"). fetchmail пытается компенсировать это использованием UID, сохраняя идентификаторы сообщений, просмотренных в каждом сеансе, в файле .fetchids. Но при этом не ведется список сообщений для остальных клиентов, а аткже сообщений, прочитанных мейлером непосредственно на сервере и не удаленных. Наилучшее решение этой проблемы - использовать протокол IMAP.

Еще одна потенциальная проблема в использовании POP3 заключается в том, что серверы могут вставлять сообщения в середину почтового ящика (ходят слухи, что некоторые реализации mail в VMS страдают этим недостатком). fetchmail подразумевает, что новые сообщения добавляются в конец почтового ящика; в противном случае некоторые старые сообщения могут считаться новыми и наоборот. Единственное средство решения этой проблемы - использовать IMAP.

Еще одна проблема с POP3 состоит в том, что если нельзя создать файл локировки в домашнем каталге пользователя, некотрые серверы POP3 вовращают недокументированный ответ, который заставляет fetchmail сообщать об отсутствии почты.

IMAP использует наличие или присутствие флага "Seen" для определения того, новое это сообщение или старое. В Unix серверы IMAP используют флаги состояния в стиле BSD, устанавливаемые пользовательскими агентами, и в случае необходимости устанавливают флаг "Seen". Все IMAP-серверы под Unix делают это, хотя это и не описано в RFC. Если вам попадется (крайне маловероятно) сервер, не делающий этого, все старые сообщения будут казаться новыми. В этом случае сообщения, принятые fetchmail с опцией --keep, будут восстановлены и помечены как старые.

В режимах ETRN и ODMR, fetchmail на самом деле не принимает почту; вместо этого он запрашивает SMTP-сервер начать выдачу почтовой очереди клиента по SMTP. Таким образом, пересылаются только недоставленные сообщения.

ФИЛЬТРАЦИЯ СПАМА

Многие SMTP-серверы позволяют администраторам настраивать фильтрацию спама для блокировки нежелательной почты с определенных доменов. При этом происходит проверка строк MAIL FROM и DATA, и в случае обнаружения спама формируется SMTP-ответ (который, к сожалению, разный у разных серверов).

Последние версии sendmail возвращают код ошибки 571. Это значение зафиксировано в RFC 1893 как "Delivery not authorized, message refused" ("Доставка запрещена, сообщение отклонено").

В соответствии с текущими проектами замены RFC 812, правильным кодом должен быть 550 "Requested action not taken: mailbox unavailable" ("Запрошенное действие не выполнено: почтовый ящик не доступен") - (также добавляют "Почтовый ящик не найден, в доступе отказано или команда отвергнута политикой безопасности").

exim возвращает 501 "Syntax error in parameters or arguments", но также скоро перейдет на 550.

postfix возвращает 554.

fetchmail уничтожает сообщение, реагируя на любой код из списка [571, 550, 501, 554], но может быть настроен опцией ‘antispam’ Это один из трех случаев, когда fetchmail уничтожает почту (остальные два - это ошибки 552 и 553, и подавление multidropped сообщений с уже прочитанным message-ID).

При приеме почты с IMAP-сервера спам обнаруживается сразу по получении заголовка письма, и сообщение отвергается без приема тела письма. Поэтому вам не стоит беспокоиться об оплате времени, уходящего на приема всего сообщения.

Если включена опция spambounce, отправитель получит сообщение, информирующее его о том, что мы не принимаем от него почту.

ОБРАБОТКА ОШИБОК SMTP/ESMTP

Помимо обработки спама, fetchmail предпринимает определенные действия в случае получения следующих кодов ошибок

При остальных ошибках письмо возвращается отправителю.

КОНФИГУРАЦИОННЫЙ ФАЙЛ

Наилучший способ настройки fetchmail состоит в написании файла .fetchmailrc в вашем домашнем каталоге (вы можете использовать обычный текстовый редактор или интерактивную утилиту fetchmailconf). Если возникает конфликт между опциями командной строки и опциями в файле, то предпочтение отдается командной строке.

Для защиты ваших паролей маска прав доступа к файлу ~/.fetchmailrc не может быть больше 600 (u=rw,g=,o=); fetchmail проверяет это, и в противном случае прекращает работу.

Вы можете рассматривать .fetchmailrc как список команд, выполняемых fetchmail, если он вызывается без аргументов.

Синтаксис конфигурационного файла

Комментарии начинаются с ’#’ и продолжаются до конца строки. В остальном файл состоит из серий определений серверов или операторов установки глобальных опций в свободном формате на основе ключевых слов.

Существуют 4 типа ключевых слов: грамматические ключевые слова, числа, строки без кавычек и строки в кавычках. Строка в кавычках помещается в двойные кавычки и может содержать пробелы (цифры в кавычках считаются строкой). Строка без каычек - это ключевые слова, разделенные пробелами, они не должны быть числами, не должны содержать специальных символов ‘,’, ‘;’, ‘:’, или ‘=’.

Ключевые слова в определении серверов разделаются любым числом пробелов, в противном случае пробелы игнорируются. Можно использовать ESC-последовательности в стиле языка С (\n, \t,\b) для маскировки непечатных символов.

Строка определения сервера состоит из одного из ключевых слов ‘poll’ или ‘skip’, после которого идет имя сервера, затем опции сервера, затем информация о пользователе. Замечание: распространенная ошибка заключается в смешивании опций сервера и опций пользователя.

Для обратной совместимости, слово ‘server’ является синонимом ‘poll’.

Вы можете использовать слова ‘and’, ‘with’, ‘has’, ‘wants’, и ‘options’ в любом месте. Они служат лишь для облегчения читаемости файла и игнорируются. Символы пунктуации ’:’, ’;’ и ’,’ также игнорируются.

Poll и Skip

Слово ‘poll’ заставляет fetchmail запрашивать указанный сервер, если запускается без аргументов. ‘skip’ заставляет fetchmail не заправшивать указанный сервер, до тех пор пока он не будет указан в командной строке. (‘skip’ позволяет безопасно экпериментировать с разными определениями или запрещать сервера, которые временно не доступны).

Ключевые слова и опции

Здесь приведены доступные опции. Суффиксы, заключенные в квадратные скобки, не обязательны. Соответствие опции командной строки задается символом "-" и буковой опции.

Глобальные опции:

Помните, что все опции пользователя должны следовать после опций сервера.

В файле .fetchmailrc строковый аргумент ‘envelope’ может быть продолжен через пробел числом. Это число, если указано, задает число пропускаемых заголовков (т.е. 1 выбирает второй заголовк указанного типа). Это иногда полезно для игнорирования паразитных строк "Received", создаваемых MDA провайдера.

Ключевые слова, не имеющие соответствия в командной строке

Опции ‘folder’ и ‘smtphost’ (в отличие от командной строки) могут принимать в качестве аргумента список имен, разделенный запятыми.

Опции, не имеющие эквивалента в командной строке: ‘via’, ‘interval’, ‘aka’, ‘is’, ‘to’, ‘dns’/‘no dns’, ‘checkalias’/‘no checkalias’, ‘password’, ‘preconnect’, ‘postconnect’, ‘localdomains’, ‘stripcr’/‘no stripcr’, ‘forcecr’/‘no forcecr’, ‘pass8bits’/‘no pass8bits’ ‘dropstatus/no dropstatus’, ‘dropdelivered/no dropdelivered’, ‘mimedecode/no mimedecode’, ‘idle/no idle’, и ‘no envelope’.

Опция ‘via’ полезна в том случае, если у вас имеется несколько настроек на один и тот же сервер. Если она присуствует, ее аргументом является имя DNS почтового сервера. Она переопределяет опцию poll, которая является просто меткой в конфигурации.

Опция ‘interval’, принимающая числовой аргумент, поволяет запрашивать сервер менее часто, чем определено основным интервалом приема. Если вы укажете ‘interval N’ , то сервер, который содержит эту опцию, будет опрашиваться каждые N интервалов приема.

Слова ‘is’ или ‘to’ ассоциируют имя локального клиента с именем пользователя на удаленном сервере (или соответствие имя_на_сервере и имя_клиента, через знак =). Если список is/to содержит в конце ‘*’, неопознанные имена пропускаются как есть.

Одиночное локальное имя может использоваться для перенаправления почты, когда ваше имя на клиенте отличается от имени на сервере. Поскольку указано только локальное имя, почта передается на этому локальному пользователю вне зависимости от содержимого заголовков Received, To, Cc и Bcc. В этом случае fetchmail не проверяет DNS.

Если указано более одного локального имени (или соответствия), fetchmail проверяет адреса в заголовках Received, To, Cc, and Bcc принятой почты (режим multidrop). Он ищет адреса с частью hostname, которые совпадат с вашим poll name, или вашими опциями ‘via’, ‘aka’ или ‘localdomains’, а также имена машин, найденные в DNS как псевдонимы почтового сервера.

Если fetchmail не может найти соответствия имени на сервере или адресов локальных доменов, почта возвращается отправителю. Однако, если указана опция "nobounce", письмо попадает постмастеру (по умолчанию это пользователь, запустивший fetchmail).

Опция ‘dns’ (обычно включенная - on) управляет способом проверки доменного почтового ящика. Она включает логику проверки адреса узла, не совпадающего с объявлениями ‘aka’ или ‘localdomains’, проверкой в DNS. Если имя пользователя сервера опознано как имя узла (hostname), его локальное соответствие добавляется в список локальных получателей.

Опция ‘checkalias’ (по умолчанию выключена - off) расширяет проверку, выполняемую опцией "dns" в режиме multidrop, помогая справиться с удаленным MTA, идентифицирующего самого себя своим каноническим именем, когда его запрашивают с использованием alias. При запросе такого сервера проверка адреса конверта не работает, и fetchmail возвращается к проверке заголовков To/Cc/Bcc. Указание этой опции заставляет fetchmail извлечь все IP-адреса, ассоциированные как с почтовым сервером, так и с именем, используемым удаленным MTA , и сравнить эти IP-адреса. Это полезно в ситациях, когда удаленный сервер часто меняет свои канонические адреса, что приводило бы к частым изменениям в конфигурационном файле. Опция "checkalias" игнорируется, если указана опция "no dns".

Опция ‘aka’ используется для доменных ящиков. Она позволяет предварительно объявить список DNS-псевдонимов сервера. Это оптимизирует скорость приема почты. Когда fetchmail обрабатывает доменный ящик, пробегая по сообщениям в поиске имен почтового сервера, предварительное объявление имен помогает сэкономить на поиске в DNS. Замечание: имена, указанные в "aka", сравниваются по суффиксам. Например, если вы указали ‘aka netaxs.com’, это будет соответствовать не только машине netaxs.com, но и любому имени машины, заканчивающемуся на ‘.netaxs.com’; т.е., например, pop3.netaxs.com и mail.netaxs.com.

Опция ‘localdomains’ позволяет объявить список доменов, которые fetchmail будет рассматривать как локальные. Если при разборке адресных строк в режиме multidrop адрес заканчивается на один из указанных доменов, этот адрес передается на MTA без изменения (т.е. преобразование в локальные адреса не производится).

Если вы используете опцию ‘localdomains’, вам может потребоваться также указать опцию ‘no envelope’, которая отключает попытку fetchmail извлечь локальные адреса из заголовков "Received" или "X-Envelope-To".

Опция password содержит строковый аргумент, представляющий пароль, используемый для входа на сервер.

Ключевое слово ‘preconnect’ позволяет указать внешнюю команду, запускаемую перед каждым установлением соединения с почтовым сервером. Это полезно, напрмер, если вы пытаетесь установить защищенное соединение POP с помощью ssh. Если команда возвращает ненулевой код возврата, вызов сервера не производится.

Аналогично, ключевое слово ‘postconnect’ также позволяет указать внешнюю команду, выплняемую после каждого отключения от почтового сервера.

Опция ‘forcecr’ заставляет добавлять символ CR в конец каждой строки, заканчивающейся только LF, перед отправкой на MTA. Строго говоря, в соответствии с RFC821 это надо делать, но лишь немногие MTA требуют этого, поэтому по умолчанию эта опция отключена (только для qmail это имеет значение).

Опция ‘stripcr’ определяет, надо ли убирать символы CR из принятой почты перед отправкой на MTA. По умолчанию включено.

Опция ‘pass8bits’ предназначена специально для почтовых программ Microsoft, которые тупо вставляют "Content-Transfer-Encoding: 7bit" куда ни попадя. Если эта опция отключена (по умолчанию) и присутствет такой заголовок, то fetchmail посылает BODY=7BIT на сервер ESMTP. Это может вызвать проблемы с сообщениями, использующих 8-битную кодировку (например,KOI-8), которые будут испорчены путем отсекания старшего бита. Если опция "pass8bits" включена, fetchmail посылает на SMTP команду BODY=8BITMIME. Если MTA может принимать 8-битный текст (большинство могут), то все будет правильно.

Опция ‘dropstatus’ определяет, надо ли удалять (включено по умолчанию) непустые заголовки "Status" и "X-Mozilla-Status" из принятой почты. Если их оставить, пользовательские программы чтения почты будут видеть такие сообщения как будто прочтенные на сервере. С другой стороны, это может смутить программы проверки новой почты, которые будут считать, что новых сообщений нет.

Опция ‘dropdelivered’ определяет, надо ли удалять заголовки "Delivered-To" (по умолчанию не удаляются). Эти заголовки добавляются программами qmail и Postfix для избежания зацикливания почты, но могутпомешать, если вы захотите создать "зеркальный" почтовый сервер в вашем домене. Используйте эту опцию с осторожностью.

Опция ‘mimedecode’ определяет, надо ли перекодировать кодировку сообщений "quoted-printable" в 8-битные данные. Если вы передаете почту на 8-битный ESMTP-сервер (например, sendmail), то закодированные заголовки и тело сообщения декодируются в 8-битные данные, упрощая их чтение. Если ваша программа чтения почты знает, как обрабатывать MIME-сообщения, эта опция вам не нужна.

Опция ‘idle’ используется только с серверами IMAP. Если она включена, и fetchmail обнаруживает, что сервер поддерживает IDLE, то в конце приема почты на сервер посылается команда IDLE. Это заставляет сервер держать соединение открытым и предупреждать клиента о поступлении новой почты. Если вы часто принимаете почту, IDLE может сэкономить траффик, исключая дополнительные соединения TCP/IP. С другой стороны, IDLE забирает почти все время fetchmail, поскольку соединение никогда не разрывается, пока сервер не сделает это по тайм-ауту. Кроме того, это не работает с несколькими ящиками; только с первым.

Опция ‘properties’ предусматривает механизм расширения. Она принимает строковый аргумент, который игнорируется fetchmail'ом. Этот аргумент можно использовать для хранения информации о настройке для скриптов, которым она может понадобиться. В частности, вывод опции "configdump" может сделать ассоциации свойств пользователям и использоваться в языке Python.

Прочие опции

Слова ‘here’ и ‘there’ полезны для облегчения чтения и понимания файла. Например, ‘user eric is esr’ означает, что почта удаленного пользователя eric должна быть доставлена локальному пользователю esr. Это становится еще более понятным, если записать так: ‘user eric there is esr here’.

Допустимые идентификаторы протоколов, используемые в качестве аргумента опции ‘protocol’:

auto (или AUTO)

pop2 (или POP2)

pop3 (или POP3)

sdps (или SDPS)

imap (или IMAP)

apop (или APOP)

kpop (или KPOP)

Допустимые типы аутентификации: ‘any’, ‘password’, ‘kerberos’, ’kereberos_v5’ и ‘gssapi’, ‘cram-md5’, ‘otp’, ‘ntlm’, ‘ssh‘. Тип ‘password’ определяет стандартный тип аутентификации посредством посылки пароля (пароль может быть открытым текстом или зашифрованным); ‘kerberos’ заставляет fetchmail попытаться получить билет Kerberos в начале каждого запроса и послать произвольную строку в качестве пароля; ‘gssapi’ заставляет использовать аутентификацию GSSAPI.

‘kpop’ означает протокол POP3 через порт 1109 с аутентификацией Kerberos V4.

Существуют также четыре глобальных оператора: ‘set logfile’ задает имя лог-файла; ‘set daemon’ задает интервал опроса серверов; ‘set postmaster’ определяет адрес, на который будет направлена почта, если не удалось определить локального пользователя. Наконец, ‘set syslog’ посылает все сообщения на syslogd.

ВЗАИМОДЕЙСТВИЕ С RFC 822

Пытаясь определить адрес отправителя сообщения, fetchmail проверяет следующие заголовки в указанном порядке:

Return-Path:

Resent-Sender: (игнорируется, если не содержит an @ или !)

Sender: (игнорируется, если не содержит an @ или !)

Resent-From:

From:

Reply-To:

Apparently-From:

Адрес отправителя используется для журнализации, и указывается в MAIL FROM при пересылке по SMTP. Такой порядок важен при анализе сообщений от списка рассылки в доменном почтовом ящике. Если локальный адрес не существует, сообщение следует вернуть не автору или в сам список, а администратору рассылки.

В режиме multidrop заголовки назначения обрабатываются следующим образом: Сначала fetchmail ищет "Received:" (или что указано в опции "envelope") для определения адреса локального получателя. Если письмо адресовано более чем одному получателю, "Received:" может не содержать информации об адресе получателя.

Затем fetchmail ищет строки Resent-To:, Resent-Cc:, и Resent-Bcc:. Если они есть, то содержат ареса окончательных получателей и имеют приоритет над To:/Cc:/Bcc:. Если строки Resent-* отсутствуют, ищутся строки To:, Cc:, Bcc: и Apparently-To:

ПРИМЕР НАСТРОЙКИ

Хотя во многих примерах присутствует объявление паролей опцией password, это сделано только в целях иллюстрации. Мы рекомендуем хранить информацию о паролях в файле $HOME/.netrc, откуда они могут браться не только программой fetchmail, но ftp и другими программами.

Основной формат:

ИСПОЛЬЗОВАНИЕ ДОМЕННЫХ ПОЧТОВЫХ ЯЩИКОВ

Использовать функцию множественных локальных получателей следует осторожно. Все функции multidrop не используются в ETRN или ODMR.

Учтите, что в режиме multidrop подавляется дублирование почты. Сообщение считается дубликатом, если имеет тот же идентификатор, что и предыдущее.

Заголовки и конверты

Фундаментальная проблема состотит в том, что когда ваш почтовый сервер помещает сообщения, адресованные нескольким получателям, в один почтовый ящик, возникает проблема определения адрса правильного получателя (адрес конверта, в противоположность объявленных в RFC822 заголовкам To/Cc/Bcc). Этот адрес конверта (envelope address) необходим для правильной маршрутизации почты.

Иногда fetchmail может определить адрес конверта. Если в качестве MTA выступает sendmail и почта имеет только одного получателя, MTA записывает это в виде ‘by/for’ в поле Received. Однако, это надежно не работает с другими MTA или в случае с несколькими получателями. По умолчанию fetchmail ищет адрес конверта в этих строках; вы можете восстановить это значение по умолчанию, указав опцию -E "Received" или ‘envelope Received’.

В качестве альтернативы, локальный MTA и/или почтовый сервер вставляют в каждое сообщение заголовок, соджащий копию адреса конверта. Этот заголовок (если есть) обычно ‘X-Envelope-To’. Это может быть изменено опцией -E или "envelope". Помните, что запись заголовка конверта таким способом раскрывает имена получателей (включая скрытых (Bc) получателей) для всех получателей сообщения, что может создать проблему безопасности/приватности.

Небольшой вариацией заголовка ‘X-Envelope-To’ является ‘Delivered-To’, помещяемый qmail для предотвращения зацикливания почты. Он обычно предваряет имя пользователя строкой домена пользователя. Для удаления этого префикса используйте опцию ‘qvirtual’.

Иногда, к сожалению, ни один из этих методов не срабатывает. В таком случае fetchmail откатывается к обработке содержимого To/Cc/Bcc и пытается отпределить адрес получателя. Но это не очень надежно, поскольку списки рассылки в заголовок To: часто ставят свой широковещательный адрес.

Если fetchmail не может определить адрес локального получателя, а подразумеваемый адрес получателя отличается от адреса пользователя,запустившего fetchmail, почта теряется. Это делает использование функций multidrop рискованным делом.

Аналогичная проблема состоит в том, что скрытая копия, информация из Bcc, передается только через адрес конверта (т.е. не помещается в заголовки, обрабатываемые fetchmail, если это не X-Envelope).

Правильный способ использования доменных почтовых ящиков

На клиентской стороне для администрирования списка рассылки можно использовать множетсвенные локальные имена. Допустим, ваше имя "esr", вы хотите получать собственную почту и одновременно вести список расслки, скажем, "fetchmail-friends", и хотите сохранить псевдоним на вашей клиентской машине.

На своем сервере вы можете создать псевдоним (alias) ‘fetchmail-friends’ на ‘esr’, затем в своем .fetchmailrc объявить ‘to esr fetchmail-friends here’. Тогда при приеме почты, включающей ‘fetchmail-friends’ в качестве локального адреса, имя списка добавится к списку получателей, который увидит SMTP. Тем не менее, локально псевдоним раскроется. Не забудьте включить "esr" в локальное раскрытие псевдонима "fetchmail-friends", иначе не увидите почту, направленную только в список рассылки. Убедитесь также, что мейлер имеет включенную опцию "me-too" (в sendmail это опция -oXm или Oxm в sendmail.cf), иначе ваше имя не удалится из раскрытия псевдонима в отправленном сообщении.

Этот трюк не идеальное решение. Вы увидите, что сообщение, пришедшее в список рассылки, будет содержать заголовок ‘X-Fetchmail-Warning’, поскольку fetchmail не смог найти подходящего локального получателя.

Плохой способ использования доменных ящиков

Нельзя смешивать доменные почтовые ящики и fetchmail, осблуживающий нескольких пользователей в режиме демона. Проблема опять связана со списками рассылок, которые, как правило, не указывают индивидуальных получателей. Если fetchmail не может определить адрес получателя, оно направляется пользователю, запустившему fetchmail (обычно root). Кроме того, скрытые пользователи (указанные в Bc:) никогда не получат почту.

Если вы собираетесь использовать fetchmail для приема почты для многих пользователей с единого почтового ящика по IMAP, подумайте еще раз. В этом случае проще оставить почту в очереди на сервере, а использовать ETRN или ODMR для периодического переключения потока SMTP. Или используйте UUCP.

Если вы все же вынуждены использовать для этого multidrop, убедитесь, что ваш почтовый сервер правильно записывает адреса конверта, чтобы fetchmail смог их определить. Иначе вы можете потерять всю вашу почту.

Ускорение проверки доменныъх ящиков

Обычно при указании нескольких пользователей fetchmail определяет адреса получателей вышеописанным способом и проверяет имя машины в DNS. Если это имя - псевдоним почтового сервера, используется карта соответствий to..here и почта доставляется локально.

Это самый безопасный и самый медленный способ. Для его ускорения можно предопределить псевдонимы почтового сервера с помощью опции "aka". Эти псевдонимы проверяются до обращения к DNS. Если вы уверены, что "aka" включает все псевдонимы DNS (и все записи типа MX, указывающие на него), то можете указать опцию "no dns" для полного отключения запросов к DNS.

КОДЫ ВОЗВРАТА

ФАЙЛЫ

ОКРУЖЕНИЕ

Если установлена переменная окружения FETCHMAILUSER, она используется для установки имени вызывающего пользователя. В противном случае используются переменные LOGNAME или USER. Если и их нет, вызывается getpwuid.

Если переменная окружения FETCHMAILHOME указывает на правильный существующий каталог, то файлы .fetchmailrc, .fetchids и fetchmail.pid будут размещаться в нем (вместо домашнего каталога вызвавшего пользователя). Файл .netrc ищется в домашнем каталоге пользователя независимо от настройки FETCHMAILHOME.

СИГНАЛЫ

Если fetchmail работает в режиме демона под бюджетом root, SIGHUP пробуждает его от спячки и вызывает немедленный опрос серверов (кроме помеченных как skip).

Если fetchmail работает в режиме демона под другим бюжетом (отличном от root), то его пробуждает сигнал SIGUSR1.

Запуск fetchmail на переднем плане в то время, тогда как работает фоновый fetchmail, последний также просыпается.

ОШИБКИ И ИЗВЕСТНЫЕ ПРОБЛЕМЫ

Опции mda и plugin плохо взаимодействуют друг с другом. Чтобы получить код ошибки от MDA, в fetchmail необходимо сменить алгоритм обрабоки сигналов.

Разборщик адресов в режиме multidrop иногда сбоит на некоторых "@-адресах", которые технически верные, но странные. Особенно если используется нестандартное использование кавычек.

В сообщении с несколькими заголовками конверта fetchmail видит только последнее. Чтобы обойти это, используйте на стороне сервера фильтр, собирающий все заголовки конверта в один (procmail, mailagent, maildrop).

Использование некоторых протоколов требует отсылки паролей в открытом виде по каналам TCP/IP на почтовый сервер. Это создает риск перехвата паролей снифферами. В Linux и FreeBSD можно использовать опцию --interface, чтобы принимать почту если указанный интерфейс активен. Мы рекомендуем использовать ssh не только для шифрования вашего пароля, но и для защиты всего траффика.

Использование %F или %T в опции mda может создать брешь в безопасности, поскольку они передают текст, который можно перехватить и подменить.

Для возврата почты и отбрасывания спама необходим открытый порт 25 на localhost.

Если вы изменили ~/.fetchmailrc при работающем в фоновом режиме fetchmail, и нарушили синтаксис, фоновый процесс тихо умрет. К сожалению, тут ничего нельзя поделать - мы не знаем, можно ли писать в syslog.

Опция -f (чтение настроек из stdin) несовместима с опцией plugin.

Код UIDL ненадежный и может потерять свое состояние при ошибках или обрыве связи. Если это случается, переходите на IMAP.

Опция ‘principal’ используетя только в Kerberos IV, но не в V.

Посылайте комментарии, отчеты об ошибках и тому подобное в список рассылки "fetchmail-friends" fetchmail-friends@lists.ccil.org. FAQ в виде HTML на английском языке доступен по адресу http://www.tuxedo.org/~esr/fetchmail

АВТОР

Eric S. Raymond <esr@snark.thyrsus.com>. Слишком много людей, чтобы всех перечислить, принимало участие в разработке кода и заплат. Эта программа призвана заменить popclient, автор <ceharris@mal.com>

Справочное руководство по Fetchmail_PDF