Партнёры:
Хостинг:
fetchmail - прием почты с серверов POP, IMAP, ETRN, или ODMR
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 и ODMR). В режиме ETRN вы запрашиваете соответствующий ESMTP-сервер (например, BSD sendmail версий 8.8.0 и выше) для открытия SMTP-соединения с клиентской машиной и направления почты, лежащей в почтовой очереди сервера, на вашу машину. Режим ODMR работает аналогично ETRN, но не требует наличия на клиентской машине статического DNS.
--smtphost server1,server2/2525,server3,/var/imap/socket/lmtp
Эта опция может использоваться с ODMR, тогда fetchmail будет выполнять роль шлюза между серверами ODMR и SMTP.
interface/iii.iii.iii.iii/mmm.mmm.mmm.mmm
Поле перед первой косой чертой (interface) - имя интерфейса (например, ppp0). Второе поле (iii.iii.iii.iii)- это допустимый IP-адрес. Третье поле (mmm.mmm.mmm.mmm) - это маска, задающая диапазон адресов. Если она не указана, подразумевается маска 255.255.255.255 (т.е. точное совпадение). Эта опция поддерживается только в Linux и FreeBSD. Специфичную информацию для FreeBSD см. в опции monitor.
'Delivered-To:'
Когда qmail доставляет почту в локальный почтовый ящик, он помещает в эту строку имя пользователя и имя узла. Основная причина этого - предотвращение зацикливания почты. При настройке qmail для обработки почты для отключенной машины, почтовый сервер провайдера обычно помещает имя этой машины в свой файл 'Virtualhosts' с тем, чтобы он добавлялся в начало всех адресов для этого сайта. Это вызывает отправку почту к пользователю 'username@userhost.userdom.dom.com', имеющей строку 'Deivered-To:' в виде:
Delivered-To: mbox-userstr-username@userhost.userdom.dom.com
Провайдер может создать любой префикс 'mbox-userstr-', но обычно используется имя пользовательского узла. С помощью опции 'envelope Delivered-To:' fetchmail может надежно определить получателя, но префикс 'mbox-userstr-' необходимо отрезать. Для этого и предназначена эта опция.
Во всех режимах, кроме ETRN, необходима аутентификация клиента. Обычная аутентификация пользователя в fetchmail сходна с механизмом, используемом в ftp. Проверка правильности идентификатора пользователя и пароля зависит от применяемой на почтовом сервере системы безопасности.
Если почтовый сервер является Unix-машиной, на которой вы имеете свою учетную запись, fetchmail будет использовать ваши обычные имя и пароль. Если вы используете одно и то же имя и на сервере, и на клиенте, вам можно не указывать идентификатор пользователя в опции -u -- по умолчанию используется ваше имя на клиентской машине. Если же на сервере используется другое, укажите его в опции -u. Например, если ваше учетное имя 'jsmith' на машине с именем 'mailgrunt', вы можете запустить fetchmail следующим образом:
fetchmail -u jsmith mailgrunt
По умолчанию 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 будет использовать ваш пароль как фразу для генерации ответа. Это предотвращает пересылку паролей в открытом виде.
Поддерживается также аутентификация Compuserv RPA (сходная с APOP). Если вы включили в fetchmail ее поддержку, то вместо посылки не зашифрованного пароля производится аутентификация RPA, если в имени узла обнаруживается "@compuserve.com".
Если вы используете IMAP, то поддерживается также Microsoft 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 -d 900
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 "Segmentation fault (core dumped)
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |