Электронная почта прошла долгий путь от элитного развлечения нескольких академиков до повседневного инструмента, от которого зависят бизнес-процессы целых корпораций. Но вместе с этим путём пришла и закономерная проблема. У типичного современного пользователя не один почтовый ящик, а пять, семь, иногда десяток. Рабочий, личный, забытый со студенческих времён, специальный для регистраций на форумах, отдельный для банковских уведомлений, ещё один на Gmail про запас. Заходить в каждый по очереди через веб-интерфейс - утомительное занятие, которое съедает час в день у любого активного пользователя.
Решений у этой проблемы за десятилетия накопилось много. Современные почтовые клиенты вроде Thunderbird или Mutt умеют подключаться к нескольким IMAP-серверам одновременно. Но есть сценарии, где клиентского решения недостаточно. Например, если хочется централизованно прогонять входящую почту через антиспам и антивирус. Или собирать почту с нескольких ящиков в одну централизованную точку для дальнейшей обработки. Или просто иметь надёжный собственный архив всей корреспонденции на случай, если очередной провайдер решит закрыть лавочку. Для всех этих задач существует fetchmail - небольшая, но мощная утилита, написанная Эриком Раймондом ещё в девяностых годах и до сих пор остающаяся стандартом de facto для забора почты с удалённых серверов.
Принцип работы fetchmail простой и элегантный. Программа подключается к указанным почтовым серверам по протоколам POP3 или IMAP, скачивает оттуда письма и передаёт их локальному агенту доставки сообщений. После этого MTA вроде Postfix или Sendmail кладёт письма в почтовый ящик нужного пользователя на локальной системе. Этот пайплайн открывает простор для встраивания дополнительных шагов - проверки на спам через SpamAssassin, антивирусного сканирования через ClamAV, фильтрации по правилам через procmail. В материале разбирается базовая установка fetchmail на Debian и два сценария его использования - запуск как системный демон и работа через cron от имени конкретных пользователей.
Подготовительные требования к серверу и установка пакета fetchmail из стандартных репозиториев Debian
Прежде чем браться за настройку, важно понимать архитектуру всей конструкции. Fetchmail сам по себе ничего не делает с письмами - он только скачивает их с внешних серверов. Распределение писем по локальным почтовым ящикам пользователей выполняет отдельный компонент, MTA. Без работающего MTA fetchmail запустится, но письма девать будет некуда, и они либо потеряются, либо вызовут ошибки при обработке.
В качестве MTA подойдёт любой популярный вариант. Postfix - пожалуй, самый распространённый выбор на современных Linux-серверах благодаря балансу между функциональностью и читаемостью конфигурации. Sendmail - ветеран жанра с богатой историей и уважением старшего поколения администраторов. Exim - выбор многих хостинг-провайдеров за гибкость в обработке маршрутов. Любой из них корректно интегрируется с fetchmail.
В сценариях с фильтрацией почты в пайплайн встраиваются дополнительные компоненты. Amavisd-new работает как универсальный шлюз между MTA и антивирусом с антиспамом, перехватывая письма по дороге к получателю. Procmail позволяет писать сложные правила обработки на основе заголовков, тела письма или результатов внешних проверок. Это уже отдельные темы, заслуживающие собственных материалов.
В разбираемой инсталляции на сервере существуют два пользователя - falko и till. У каждого есть локальный почтовый ящик, в который MTA уже умеет складывать корреспонденцию. Задача fetchmail - дополнить эту картину, забирая письма ещё и с внешних провайдеров.
Установка самого пакета выполняется одной командой через стандартный менеджер пакетов Debian.
apt install fetchmail
В процессе установки apt подтянет несколько зависимостей - библиотеки для работы с криптографией (TLS-соединения с почтовыми серверами требуют проверки сертификатов), парсеры почтовых форматов, базовый набор Perl-модулей для системных скриптов. Размер инсталляции получается скромным, считанные мегабайты. После установки в системе появляется бинарник fetchmail и сопутствующая инфраструктура - init-скрипт для запуска как демона, страницы man-документации, шаблоны конфигов.
Запуск fetchmail в режиме системного демона с глобальным конфигурационным файлом для всех пользователей сервера
Первый сценарий использования - запустить fetchmail как системный сервис, который работает в фоне и периодически опрашивает почтовые серверы для всех пользователей сразу. Преимущество подхода в централизации - один конфиг описывает всё хозяйство, администратор контролирует процесс с одной точки, пользователи получают свою почту автоматически без необходимости что-то настраивать самостоятельно.
В Debian готовность fetchmail работать как демон управляется отдельным флагом в файле дефолтов. По умолчанию демон не стартует, чтобы случайно установленный пакет не пытался куда-то подключаться без явного указания администратора.
nano /etc/default/fetchmail
Внутри находится переменная START_DAEMON, которую нужно перевести в значение yes.
# This file will be used to declare some vars for fetchmail
#
# Uncomment the following if you dont want localized log messages
# export LC_ALL=C
# Declare here if we want to start fetchmail. 'yes' or 'no'
START_DAEMON=yes
Закомментированная строка про LC_ALL отвечает за локализацию системных сообщений. Если хочется видеть логи fetchmail на английском языке независимо от системной локали, эту строку можно раскомментировать. Для англоязычных систем особого смысла нет, для систем с экзотическими локалями иногда выручает.
Теперь основная конфигурация. Главный файл fetchmail в режиме демона лежит по пути /etc/fetchmailrc, и без него демон отказывается стартовать вообще.
Перед написанием конфига нужно собрать исходные данные о ящиках, с которых fetchmail будет забирать почту. В разбираемом примере у пользователя falko два внешних ящика. Первый сидит на сервере pop.someprovider.tld, работает по протоколу POP3, имя пользователя там - полный email-адрес
Создание самого конфига.
nano /etc/fetchmailrc
Содержимое получается осмысленным и относительно компактным.
# /etc/fetchmailrc for system-wide daemon mode
# This file must be chmod 0600, owner fetchmail
set daemon 300 # Pool every 5 minutes
set syslog # log through syslog facility
set postmaster root
set no bouncemail # avoid loss on 4xx errors
# on the other hand, 5xx errors get
# more dangerous...
##########################################################################
# Hosts to pool
##########################################################################
# Defaults ===============================================================
# Set antispam to -1, since it is far safer to use that together with
# no bouncemail
defaults:
timeout 300
antispam -1
batchlimit 100
poll pop.someprovider.tld protocol POP3 user "Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. " there with password "secret" is falko here
poll mail.otherprovider.tld protocol POP3 user "ftimme" there with password "verysecurepassword" is falko here fetchall
poll mailin.tillsprovider.tld protocol POP3 user "tbrehm" there with password "iwonttellyou" is till here keep
Файл логически делится на несколько секций, и каждую стоит разобрать отдельно.
Первый блок задаёт глобальные настройки демона. Директива set daemon 300 говорит fetchmail работать в фоне и опрашивать сервера каждые 300 секунд, то есть каждые пять минут. Этот интервал - компромисс между свежестью почты и нагрузкой на удалённые серверы. Слишком частые опросы могут привести к временной блокировке IP-адреса со стороны провайдера. Слишком редкие - к задержкам в получении срочной корреспонденции.
set syslog направляет ошибки и информационные сообщения в системный syslog-демон, откуда их можно читать через journalctl или классическими инструментами вроде tail -f /var/log/syslog. Без этой опции fetchmail попытается отправлять отчёты по почте, что не всегда удобно.
set postmaster root указывает, кому доставлять письма, которые не удалось доставить адресату по обычным правилам. Это стандартный safety net - если конфиг с ошибкой и письмо некуда положить, оно попадёт в ящик root, откуда администратор сможет разобраться, что пошло не так.
Директива set no bouncemail отключает отправку отказов отправителю при ошибках типа 4xx (временные проблемы вроде переполненного ящика). Вместо этого письма с ошибкой направляются локальному postmaster. Это страховка от потери писем при временных сбоях, но требует осознанной настройки antispam, иначе можно создать петлю обратной связи.
Секция defaults задаёт параметры по умолчанию для всех опросов. Директива timeout 300 говорит ждать ответа от сервера до пяти минут перед признанием соединения мёртвым. Антиспам-параметр со значением -1 фактически отключает интерпретацию SMTP-ответов как признаков спама - это правильное поведение в связке с no bouncemail. Batchlimit 100 ограничивает количество писем, передаваемых через одно соединение с локальным MTA - после сотни писем соединение закрывается и открывается новое, что предотвращает разные неприятности с зависшими сессиями.
Самые интересные строки - это poll-директивы. Каждая описывает один опрос одного внешнего ящика. Синтаксис плотный, но читаемый - сначала имя сервера, затем протокол, имя пользователя на удалённом сервере, пароль, имя локального пользователя для доставки, и опциональные модификаторы поведения.
Первая poll-строка для falko забирает почту с pop.someprovider.tld и доставляет её локальному пользователю falko с поведением по умолчанию - забирать только новые письма. Вторая строка тоже для falko, но с модификатором fetchall - этот режим заставляет fetchmail скачивать вообще все письма, и новые, и уже помеченные как прочитанные. Полезно при первой настройке, когда нужно перенести всю историю с сервера.
Третья строка для till использует модификатор keep - после скачивания письма не удаляются с удалённого сервера. Это удобно, когда хочется оставить дублирующую копию у провайдера или когда тот же ящик читается ещё какими-то клиентами с других устройств. Антоним keep - модификатор nokeep, который явно требует удаления забранных писем (это поведение по умолчанию, и его обычно не указывают явно).
После сохранения файла критически важно правильно выставить права доступа. В конфиге лежат пароли в открытом виде, и его никто кроме fetchmail видеть не должен.
chmod 600 /etc/fetchmailrc
chown fetchmail /etc/fetchmailrc
Права 600 означают чтение и запись только для владельца, никаких прав для группы и для остальных. Команда chown передаёт владение файлом системному пользователю fetchmail, который создаётся автоматически при установке пакета. Без этого шага демон откажется стартовать с подозрением на компрометацию конфига.
Запуск самого демона.
/etc/init.d/fetchmail start
В современных системах с systemd более правильным синтаксисом был бы systemctl start fetchmail, но классический init-скрипт в Debian продолжает работать через wrapper и тоже корректно поднимает сервис.
После запуска fetchmail начинает свой цикл - подключается к каждому из перечисленных серверов, скачивает почту, передаёт её локальному MTA, ждёт пять минут, повторяет цикл. Пользователи falko и till теперь получают свою внешнюю почту автоматически.
Альтернативная настройка с индивидуальными конфигами в домашних каталогах пользователей и запуском через cron
Не всегда модель централизованного демона удобна. Бывают случаи, когда каждый пользователь хочет сам управлять списком своих внешних ящиков, без необходимости беспокоить администратора. Или когда правила разных пользователей слишком сильно расходятся, и держать всё в одном файле получается громоздко. Для таких ситуаций fetchmail поддерживает второй режим работы - запуск от имени конкретного пользователя с конфигом в его домашнем каталоге.
Конфиг в этом случае называется .fetchmailrc (точка в начале делает его скрытым, как принято для пользовательских настроек) и лежит непосредственно в домашнем каталоге. Создаётся он не от имени root, а от имени самого пользователя - этот момент критичен.
cd ~/
vi .fetchmailrc
Содержимое файла для пользователя falko выглядит проще, чем глобальный конфиг.
set postmaster falko
set bouncemail
poll pop.someprovider.tld protocol POP3 user "Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. " there with password "secret"
poll mail.otherprovider.tld protocol POP3 user "ftimme" there with password "verysecurepassword" fetchall
Заметна разница с глобальным конфигом. В poll-строках больше нет фразы is falko here - fetchmail и так понимает, кому доставлять почту, потому что конфиг лежит в домашнем каталоге конкретного пользователя. Указание целевого пользователя стало бы избыточным.
Глобальные опции тоже сократились. Postmaster указывает на самого falko - все системные сообщения, которые fetchmail захочет отправить, попадут в его собственный ящик, а не пойдут к root. Bouncemail включён, потому что в персональном режиме отправка отказов на удалённый адрес часто желательна - falko хочет знать, если что-то пошло не так.
При желании ничто не мешает писать конфиг в более многословной форме с явным указанием целевого пользователя.
set postmaster falko
set bouncemail
poll pop.someprovider.tld protocol POP3 user "Адрес электронной почты защищен от спам-ботов. Для просмотра адреса в браузере должен быть включен Javascript. " there with password "secret" is falko here
poll mail.otherprovider.tld protocol POP3 user "ftimme" there with password "verysecurepassword" is falko here fetchall
Поведение будет идентичным, но конфиг становится самодокументируемым - даже без понимания контекста сразу видно, кому достанется почта.
Права доступа на персональный конфиг тоже строго ограничены.
chmod 600 ~/.fetchmailrc
Те же 600, что и для глобального конфига - чтение и запись только владельцу. Без правильных прав fetchmail откажется работать с конфигом из соображений безопасности. Это предотвращает банальные случаи, когда другой пользователь системы случайно или намеренно прочитает чужие пароли.
Теперь falko может запустить fetchmail руками одной командой.
fetchmail
Программа выполнит один цикл опроса всех настроенных серверов и завершится. Если хочется видеть подробности процесса - что подключается, что скачивается, как обрабатывается, - можно добавить флаг verbose.
fetchmail -v
В verbose-режиме fetchmail выводит подробный лог каждого шага - открытие SSL-соединения, согласование версии протокола, аутентификация, перечень писем на сервере, скачивание тел писем, передача локальному MTA. Незаменимо при отладке проблем с подключением к капризным провайдерам.
Запускать fetchmail каждые пять минут вручную - занятие неблагодарное и быстро надоедающее. Решение классическое - cron-задача, которая будет делать это автоматически. Под учёткой falko открывается редактор crontab.
crontab -e
В файл добавляется одна строка с расписанием.
*/5 * * * * /usr/bin/fetchmail &> /dev/null
Синтаксис cron давно стал классикой и заслуживает разбора по полям. Первое поле */5 означает запуск каждые пять минут (на минутах, кратных пяти - 0, 5, 10, 15 и так далее). Следующие четыре звёздочки означают любое значение для часа, дня месяца, месяца и дня недели соответственно. Дальше идёт сама команда - полный путь к бинарнику fetchmail, потому что в cron-окружении переменная PATH часто отличается от интерактивного shell. Конструкция &> /dev/null перенаправляет и stdout, и stderr в чёрную дыру - cron по умолчанию шлёт пользователю по почте всё, что команда выводит на экран, и без перенаправления почтовый ящик falko быстро забьётся ненужными отчётами.
С такой настройкой fetchmail работает у пользователя в фоне, забирая почту с внешних ящиков с регулярностью пять минут, не требуя ни прав root, ни запущенного системного демона. Каждый пользователь системы может настроить свою схему совершенно независимо от других.
Сравнение двух подходов и практические рекомендации по выбору режима работы fetchmail в зависимости от задач
Два разобранных режима покрывают большинство реальных сценариев, но у каждого свои сильные и слабые стороны. Понимание этих различий помогает сделать правильный выбор для конкретной ситуации.
Демон-режим с глобальным конфигом выигрывает в централизации управления. Один файл - одна точка контроля. Администратор сразу видит всю картину опроса внешних ящиков на сервере, может оперативно вносить изменения, отслеживать общий уровень нагрузки на инфраструктуру. Запуск как системный сервис означает автоматический старт при загрузке системы - не нужно ничего настраивать дополнительно. Минус подхода в том, что пользователи теряют контроль над своими настройками. Любое изменение требует обращения к администратору, что может раздражать в небольших коллективах с продвинутыми пользователями.
Cron-режим с персональными конфигами даёт полную автономию каждому пользователю. Если falko хочет добавить новый внешний ящик в три ночи в воскресенье, он просто правит свой .fetchmailrc и crontab без необходимости беспокоить кого-либо. Минус в распылённости - администратор не видит общей картины, и при проблемах диагностика усложняется. На многопользовательских системах с десятками активных пользователей такая модель может приводить к избыточной нагрузке, если каждый поставит частые опросы.
Гибридный подход тоже имеет право на жизнь. Глобальный конфиг покрывает основные случаи и работает как демон, а отдельные продвинутые пользователи дополнительно держат свои персональные конфиги для экспериментов с особыми настройками. Fetchmail прекрасно справляется с обоими режимами одновременно.
Безопасность хранения паролей в обоих режимах остаётся ахиллесовой пятой fetchmail. Пароли лежат в открытом виде в текстовых файлах. Права 600 защищают от прямого чтения другими пользователями, но при компрометации root или самого пользователя fetchmail все его внешние ящики оказываются под угрозой. Для критически важных учётных записей лучше использовать модель application-specific passwords - многие современные провайдеры почты позволяют создавать специальные пароли для конкретных приложений с возможностью отзыва. Если такой пароль попадёт в чужие руки, ущерб ограничится одной только функцией забора почты, а не всем доступом к аккаунту.
Освоение fetchmail открывает двери к построению собственной почтовой инфраструктуры. Связка fetchmail + Postfix + SpamAssassin + ClamAV + procmail превращает обычный сервер в персональный почтовый шлюз с фильтрацией, архивированием и любой кастомной логикой обработки писем. Вся переписка проходит через инфраструктуру, которой пользователь полностью владеет, без зависимости от прихотей внешних провайдеров и их меняющихся политик. Для тех, кто всерьёз заботится о приватности своей корреспонденции, это не роскошь, а базовый уровень цифровой гигиены.
Канал сайта в Telegram
Канал сайта на YouTube