Танкист Апокалипсиса
Сегодня расскажу про решение одной проблемки, связанной с наличием двух и более почтовых серверов в одном домене.
Итак, что имеем:
1. основной почтовый сервер, который распологается на наших мощностях.
2. резервный почтовый сервер, который поддерживает провайдер.
Проблемы начинаются в в двух случаях:
а) по причине того, что провайдер держит на одном сервере не только наш почтовый домен, но и ещё штук двадцать-тридцать-пятьдесят-сто, существует вероятность, что однажды товарищи, хостящиеся у провайдера, захотят написать мне письмо. И вот тут начинается проблема в собственном соку - почтарь не станет отправлять письмо на почтовый сервер, имеющий максимальный приоритет в домене, он его положит себе под бок, так как имеет право принимать почту и для моего домена.
б) Если упал канал связи или основной сервер, то в действие вступает резервный сервер, который, естественно, начинает собирать почту.
Что имеем в результате этих случаев: по причине того, что на резервный сервер никто заглядывать и не собирается, письма потихоньку накапливаются и теряются...
Решение проблемы.
Оговорюсь сразу - решение не претендует на абсолютную безошибочность, адекватность поведения в случае отправления одного послания нескольким адресатам и в некоторых других случаях - мне просто было лень прописывать все необходимые правила. Более того, решение рассматривает вариант, когда на резервном почтовом сервере все сообщения валятся на один ящик (как правило, postmaster), так как случай, когда оба почтовых сервера имеют идентичный набор учётных записей, является более простым.
Для решения поставленной задачи будем использовать две программы, предназначенные для работы с почтой.
fetchmail - позволяет забирать почту с удалённого почтового сервера.
procmail - позволяет осуществлять фильтрацию сообщений по определённым критериям.
Ниже привожу вырезки из конфигурационных файлов
---- начало файла /etc/procmail.conf-----
MAILDIR=/var/mail
:0
* ^To.*maxim@.*domain.ru
| formail >> maxim
:0
* ^To.*@.*domain.ru
| formail >> info
:0
*
/dev/null
---- конец файла /etc/procmail.conf -----
Смысл вышеприведённого прост:
1. если в адресе письма содержится имя какого-либо пользователя (maxim), то письмо отдаём ему.
2. если ничего не подошло, но письмо отправлено в domain.ru, то письмо отдадим секретарю - пусть разбирается (Правда туго придётся человеку, но что поделать).
3. во всех остальных случаях пришедшее письмо уничтожаем.
Использование команды formail обязательно, так как эта команда осуществляет
переформатирование заголовка для приведения его в соответствие формату почтового ящика.
---- начало файла /etc/fetchmail.rc -----
poll mail.domain.ru
proto POP3
user [email][email protected][/email]
pass *********
mda "/usr/bin/procmail -m /etc/procmail.conf"
---- конец файла /etc/fetchmail.rc -----
Самое интересное в этом файле то, что мы заставляем fetchmail принятые сообщения пропустить через procmail так, как будто он - почтовый сервер.
Запускаем fetchmail командой fetchmail -f /etc/fetchmail.rc и - вуаля! - почта принимается и раскладывается туда, куда надо.
...И администратор погружается в сладостный сон до следующего проишествия...
Current music: Опять та же самая композиция.
Итак, что имеем:
1. основной почтовый сервер, который распологается на наших мощностях.
2. резервный почтовый сервер, который поддерживает провайдер.
Проблемы начинаются в в двух случаях:
а) по причине того, что провайдер держит на одном сервере не только наш почтовый домен, но и ещё штук двадцать-тридцать-пятьдесят-сто, существует вероятность, что однажды товарищи, хостящиеся у провайдера, захотят написать мне письмо. И вот тут начинается проблема в собственном соку - почтарь не станет отправлять письмо на почтовый сервер, имеющий максимальный приоритет в домене, он его положит себе под бок, так как имеет право принимать почту и для моего домена.
б) Если упал канал связи или основной сервер, то в действие вступает резервный сервер, который, естественно, начинает собирать почту.
Что имеем в результате этих случаев: по причине того, что на резервный сервер никто заглядывать и не собирается, письма потихоньку накапливаются и теряются...
Решение проблемы.
Оговорюсь сразу - решение не претендует на абсолютную безошибочность, адекватность поведения в случае отправления одного послания нескольким адресатам и в некоторых других случаях - мне просто было лень прописывать все необходимые правила. Более того, решение рассматривает вариант, когда на резервном почтовом сервере все сообщения валятся на один ящик (как правило, postmaster), так как случай, когда оба почтовых сервера имеют идентичный набор учётных записей, является более простым.
Для решения поставленной задачи будем использовать две программы, предназначенные для работы с почтой.
fetchmail - позволяет забирать почту с удалённого почтового сервера.
procmail - позволяет осуществлять фильтрацию сообщений по определённым критериям.
Ниже привожу вырезки из конфигурационных файлов
---- начало файла /etc/procmail.conf-----
MAILDIR=/var/mail
:0
* ^To.*maxim@.*domain.ru
| formail >> maxim
:0
* ^To.*@.*domain.ru
| formail >> info
:0
*
/dev/null
---- конец файла /etc/procmail.conf -----
Смысл вышеприведённого прост:
1. если в адресе письма содержится имя какого-либо пользователя (maxim), то письмо отдаём ему.
2. если ничего не подошло, но письмо отправлено в domain.ru, то письмо отдадим секретарю - пусть разбирается (Правда туго придётся человеку, но что поделать).
3. во всех остальных случаях пришедшее письмо уничтожаем.
Использование команды formail обязательно, так как эта команда осуществляет
переформатирование заголовка для приведения его в соответствие формату почтового ящика.
---- начало файла /etc/fetchmail.rc -----
poll mail.domain.ru
proto POP3
user [email][email protected][/email]
pass *********
mda "/usr/bin/procmail -m /etc/procmail.conf"
---- конец файла /etc/fetchmail.rc -----
Самое интересное в этом файле то, что мы заставляем fetchmail принятые сообщения пропустить через procmail так, как будто он - почтовый сервер.
Запускаем fetchmail командой fetchmail -f /etc/fetchmail.rc и - вуаля! - почта принимается и раскладывается туда, куда надо.
...И администратор погружается в сладостный сон до следующего проишествия...
Current music: Опять та же самая композиция.
