Fetchmail
Fetchmail Мы уже знаем, как настроить mailfilter для fetchmail, а что такое собственно fetchmail?
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 определит наилучший протокол, который поддерживает ваш почтовый сервер и предупредит о потенциальных проблемах.
Аутентификация пользователей и шифрование
Во всех режимах, кроме ETRN, необходима аутентификация клиента. Обычная аутентификация пользователя в fetchmail сходна с механизмом, используемом в ftp. Проверка правильности идентификатора пользователя и пароля зависит от применяемой на почтовом сервере системы безопасности.
Если почтовый сервер является Unix-машиной, на которой вы имеете свою учетную запись, fetchmail будет использовать ваши обычные имя и пароль. Если вы используете одно и то же имя и на сервере, и на клиенте, вам можно не указывать идентификатор пользователя в опции -u — по умолчанию используется ваше имя на клиентской машине. Если же на сервере используется другое, укажите его в опции -u. Например, если ваше учетное имя 'smith' на машине с именем 'comp', вы можете запустить fetchmail следующим образом:
fetchmail -u smith comp
По умолчанию 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). Если вы беспокоитесь о безопасности вашего почтового ящика, используйте туннелирование ssh.
Источник информации: документация по fetchmail
X-Stranger
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 определит наилучший протокол, который поддерживает ваш почтовый сервер и предупредит о потенциальных проблемах.
Аутентификация пользователей и шифрование
Во всех режимах, кроме ETRN, необходима аутентификация клиента. Обычная аутентификация пользователя в fetchmail сходна с механизмом, используемом в ftp. Проверка правильности идентификатора пользователя и пароля зависит от применяемой на почтовом сервере системы безопасности.
Если почтовый сервер является Unix-машиной, на которой вы имеете свою учетную запись, fetchmail будет использовать ваши обычные имя и пароль. Если вы используете одно и то же имя и на сервере, и на клиенте, вам можно не указывать идентификатор пользователя в опции -u — по умолчанию используется ваше имя на клиентской машине. Если же на сервере используется другое, укажите его в опции -u. Например, если ваше учетное имя 'smith' на машине с именем 'comp', вы можете запустить fetchmail следующим образом:
fetchmail -u smith comp
По умолчанию 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). Если вы беспокоитесь о безопасности вашего почтового ящика, используйте туннелирование ssh.
Источник информации: документация по fetchmail
X-Stranger
Компьютерная газета. Статья была опубликована в номере 31 за 2002 год в рубрике soft :: linux
