В данном посте я хочу рассказать о настройке почтового сервера для
маршрутизации почты (релея). Причин для создания такого сервера существует несколько. Например, для
доставки почты внутрь разветвленной корпоративной сети. Второй пример
— некоторые господа админы в качестве основного почтового сервера
предпочитают виндовый софт, типо MDaemon, Kerio и иже с ними, но в
инет предпочитают выставлять релей, построенный на nix-ах. Я расскажу о настройке почтового маршрутизатора на базе sendmail. В
качестве ОС используется FreeBSD. Первое, о чем следует позаботится, это соответствие DNS записей для
вашего сервера в прямой и обратной зонах. Для тех, кто не знает что
это, поясню на примере. Допустим, имя вашего почтового сервера
mail. domain. ua и IP адрес — 195. 195. 195. 195. Так вот, IP адресу
195. 195. 195. 195 должно соответствовать имя mail. domain. com.
А вот пример несоответствия записей:
В последнем случае возможны проблемы доставки почты на некоторые
домены, администраторы которых пытаются боротся со спамерами, проверяя
соотверствия прямой и обратной записей. Впрочем, таких немного. Вторым шагом будет, как ни странно, выбор hostname для сервера :). FQDN почтового сервера не должен соответствовать ни одному домену,
который мы собираемся релеить. К примеру, если мы собираемся
маршрутизировать domain. ua, то назвав так-же сервер, мы окажемся в
ситуации, когда sendmail всю почту на этот домен будет складывать
локально, а не передавать на следующий почтовый сервер. Для sendmail-a
FQDN всегда будет локальным доменом. В принципе, его можно обмануть при помощи конфигурационного параметра,
но я не вижу ни одной причины так делать. К тому же, в руководстве по
конфигурационному файлу сказано буквально следующее: «This should only
be done if your system cannot determine your local domain name,and
then it should be set to $w. Foo. COM, where Foo. COM is your domain
name. »
Так что, лучшим вариантом будет присвоить серверу hostname, не
совпадающее с маршрутизируемыми доменами, к примеру, mail. domain. ua. В FreeBSD это делается через rc. conf:
Далее. Необходимо убедится, что sendmail запускается при старте
системы. Для этого нужно добавить параметр sendmail_enable в
/etc/rc. conf.
Теперь приступаем к настройке непосредственно sendmail-a. Конфигурация
естественно будет выполнятся при помощи макроцессора m4. Подробнейшее
руководство по конфигурации sendmail через m4 находится в
/usr/share/sendmail/cf/README. Сразу отмечу, что для комментирования
строки необходимо поместить служебное слово dnl в её начало. Здесь и далее предполагается, что рабочим каталогом является
/etc/mail. Итак, заходим в каталог /etc/mail и выполняем команду make. В результате появится файл _имя_сервера_. mc, т. е. в нашем случае
mail. domain. ua. mc. Содержимое этого файла — дефолтный конфигурационный файл для FreeBSD. Его-то мы и будем править. Основными опциями для наших нужд есть опции access_db и mailertable. Открыв mc-файл редактором, убеждаемся в их наличии:
В конфигурации по умолчанию sendmail настроен на работу по протоколу
IPv6. Если Вы не используете этот протокол, то логично отключить его,
закомментировав строку:
Также, неплохо бы применить некоторые параметры, которые увеличат
защиту нашего sendmail-a. Во-первых, убеждаемся в наличии/незакоментированности строки,
отключающей команды VRFY и EXPN:
Во-вторых, желательно наложить ограничение на использование системных
ресурсов sendmail-ом.
К выбору ограничений следует отнестись разумно, ибо слишком заниженные
значения приведут к нарушении нормальной работы. В третьих, некоторые особо параноидальные админы меняют SMTP-баннер,
чтобы злые дядьки не смогли по его содержимому узнать версию
почтовика. Если Вы относите себя к этой когорте, то баннер меняется
следующим образом
Идем дальше. По умолчанию sendmail пытается выполнить запрос ident к
клиенту. Это совешенно бесполезная фича, которая, к тому же, может
привести к задержкам в доставке почты. Если у клиента блокируется
траффик на 113 TCP порт, то это приведет к 5-секундной задержке,
поскольку sendmail будет ожидать такое время ответ от клиента. Отключаем выполнение ident-запросов следующим параметром:
Если есть желание использовать черные списки для борьбы со спамерами,
то эта возможность включается таким образом:
После сохранения нашего mc-файла необходимо сгенерировать из него
sendmai. cf. Для этого нужно выполнить команды make и make install:
Следующим шагом будет настройка списка доступа и таблицы маршрутизации
почты. В каталоге /etc/mail есть файлы примеров access. sample и
mailertable. sample соответственно. Можно скопировать их, а можно и
создать пустые файлы access и mailertable.
В файле access прописываем почтовые домены, которые будет релеить
сервер. К примеру это domain. ua и domain. ru:
В последней строке указана наша локальная подсеть, ведь мы собираемся
не только принимать почту, но и отправлять ;). В файле mailertable указываем какие домены куда перенаправлять:
Если в качестве домена указать точку (. ), то по этому маршруту будет
отправлятся вся почта, для которой не было найдено маршрута. Файлы access и mailertable в чистом виде не используются, их нужно
скомпилировать в db-файлы.
На этом процесс конфигурирования закончен. Для того, чтобы наша
конфигурация вступила в силу выполняем команду make restart
Примечание. Перезапускать sendmail нужно только после внесения
изменений в конфигурционный файл (sendmail. cf). При изменении access и
mailertable перезапуск не нужен. После перезапуска проверяем работу нашего почтового сервера. Убеждаемся, что сервер слушает 25 порт:
Пытаемся отправить тестовое письмо на наш домен:
Убеждаемся что письмо ушло в соответствии с таблицей маршрутизации:
По желанию, можно подключится к sendmail-у с какого-нибудь внешнего
адреса и попытатся отправить писмо на какой-нить левый домен. Естессно, наша попытка должна быть отфутболена. На этом базовая настройка релея закончилась. Остался последний штрих. Если на сервере используется пакетный фильтр
и в нем по умолчанию неразрешенные пакеты сбрасываются (DROP), то у
других сендмейлов могут быть проблемы с ident-запросами к нашему
серверу. Не будем им усложнять жизнь и настроим пакетный фильтр так,
чтобы запросы на 113 TCP порт не сбрасывались, а отклонялись. Для pf, который я использую на сервере, это будет следующее правило:
Для iptables в Linux-ах нужно будет сделать что-то вроде этого:
Ну и осталось приправить по желанию антиспамом и антивирусом, но
данные вопросы пусть останутся за рамками этого поста.