Сайт журнала «Системный администратор»

Последний выпуск: 08.2008

Последние опубликованные статьи: 06.2008

До завершения подписки на 2009 год остался 101 день, 4 ч., 58 мин.

Админский приз

Новости

Авторам

Содержание

Статьи

Исходный код

Подписка 2009

Приобрести

Реклама

Мероприятия

Контактная информация

Диски

Работа (бета!)

Форум журнала

Электронное приложение

Рассылка на Subscribe.ru:

Чем для Вас является журнал «Системный администратор»?

Источником полезных сведений, которые Вы потом применяете на практике

Сборником занимательных материалов и новостей для развлечения

Результаты

Поиск:

www.samag.ru

Web

Как работает Sendmail?
Полезные подробности

Часть 2:
Вопросы конфигурации

Сергей Супрунов

Видел я этот сендмайл – конфиги для конфигов, чтобы создать конфиги!

Цитата с http://forum.oszone.net

Одна из самых сильных сторон Sendmail – функциональная мощь этой
программы. Но вот только запрятана она порой в дальних уголках
конфигурационных файлов.

Ужас, летящий на крыльях
ночи

При первом просмотре основной конфигурационный файл, sendmail.cf, особенно
ближе к концу, напоминает скорее двоичный код, чем что-то читаемое, и тем более
редактируемое. Но на самом деле всё не так уж и сложно – всему виной
перегруженность «знаками пунктуации», сбивающими с толку и не позволяющими
без специальной подготовки сложить их во что-то осмысленное.

Назначение файла sendmail.cf – определить опции
работы Sendmail и правила обработки сообщений. Собственно говоря,
включение в него правил и обусловливает его перегруженность и небывалый
размер (обычно он составляет несколько тысяч строк). Но зато это
значительно повышает гибкость конфигурирования.

Несмотря на то что cf-файл, в общем-то, не
предусматривает прямого редактирования (для этого служит механизм m4, о котором
поговорим в следующем разделе) и генерируется автоматически, он достаточно
хорошо прокомментирован.

Рассмотрим представленные в нём секции и наиболее
характерные параметры. Строки, начинающиеся с «#» – комментарии. Тип параметра
задаётся первой буквой строки (см. таблицу 1). Строка, начинающаяся с
пробельного символа, – продолжение предыдущей. Пустые строки игнорируются.

Таблица 1. Коды строк sendmail.cf

Код

Описание

C

Классы

D

Макросы

F

Файлы с классами

H

Поля заголовка

K

Базы данных

M

Почтовые агенты

O

Опции Sendmail

P

Приоритеты обработки

R

Наборы правил для адресов

S

Группы наборов правил

Классы предназначены для описания имён,
объединённых одним признаком. Сразу после буквы C следует односимвольное или многосимвольное
(в фигурных скобках) имя класса.

Например, класс запрещённых для использования в
доменном имени символов определяется как «CB! % @ : ^».

Макросы представляют собой что-то типа
переменных, позволяя в дальнейшем обращаться к единожды определённому макросу
по имени (перед которым указывается префикс $). Существует ряд предопределённых
макросов (некоторые из них представлены в таблице 2), которые можно
использовать по мере необходимости. Для них зарезервированы строчные
буквы. Для иного использования предназначены прописные буквы или многосимвольные
имена.

Таблица 2. Предопределённые
макросы

Макрос

Значение

$a

Содержимое поля Date:

$f

Адрес отправителя

$i

Идентификатор сообщения в
очереди

$h

Полное доменное имя хоста
получателя

$m

Необработанный адрес
получателя

$u

Имя пользователя из адреса
получателя

$w

Имя данного хоста

$x

Полное имя отправителя

$z

Домашний каталог получателя

F-строки заносят в определённый класс содержимое
указанного файла. Строки типа K задают базы данных, которые в дальнейшем могут
использоваться в правилах преобразования.

Например, так подключается база mailertable:

Kmailertable hash -o /etc/mail/mailertable

Про остальные типы строк у нас будет возможность
поговорить чуть позже. Рассмотрим некоторые секции файла sendmail.cf:

Local info

Здесь определяются общие параметры, влияющие на работу MTA:

n  Cw – класс «w» описывает домены, для
которых будет выполняться обработка почты. Обычно присутствуют строки Cwlocalhost
и Cwdomain.ru (где domain.ru – доменное имя нашего сервера). Если для
указания хостов используется файл local-host-names, он подключается следующей
строкой:

Fw-o /etc/mail/local-host-names

Здесь параметр -o говорит о том, что не нужно выдавать
сообщение об ошибке, если указанный файл отсутствует. Имя файла –
используемое по умолчанию, но в принципе может быть произвольным.
В старых версиях Sendmail использовался файл /etc/sendmail.cw.

n  DS – имя «умного» (smart) хоста, или
почтового релея, который будет использоваться для пересылки почты. Если Smart-host
указан, то вся исходящая почта будет направляться на него, а он уже
займётся определением маршрутов отдельных сообщений и их дальнейшей отправкой.
Подробнее об этом режиме работы мы поговорим чуть позже.

n  CO @ % ! – символы, которые запрещены
для использования в именах пользователей, поскольку являются разделителями
«именной» и доменной частей адреса.

n  DnMAILER-DAEMON – так наш Sendmail будет
представляться в сообщениях об ошибках.

n  DZ – этот макрос задаёт версию
конфигурации Sendmail, например: DZ8.13.4.

Options

Эта достаточно большая секция содержит массу опций,
управляющих теми или иными аспектами работы почтового сервера. Ниже приведено
несколько примеров (для некоторых опций по старой памяти существуют сокращённые
однобуквенные наименования, но рекомендуется использовать новый стиль):

n  O AliasFile – определяет путь
к файлу псевдонимов (см. ниже).

n  O MaxMessageSize – максимальный размер
обрабатываемого сообщения. Разумное ограничение данного параметра позволит
усложнить реализацию атак, направленных на заполнение всего доступного
пространства в почтовых ящиках пользователей. Однако не забывайте, что в
наши дни прослеживается тенденция к увеличению среднего объёма вложений,
и отправка по почте файла в 2030 Мб является не такой уж редкостью.

n  O HoldExpensive – вы можете объявить (с
помощью флага «e» в Mстроке) агента доставки как «дорогой» (expensive), и
в этом случае Sendmail не будет предпринимать попыток отправить письмо через
такого агента сразу же после получения, а будет просто оставлять его в очереди.
Эта опция может быть весьма полезна в случае коммутируемого соединения, когда
осуществление дозвона до сервера провайдера при получении каждого письма может
оказаться крайне неэффективным. Вместо этого разумнее дозваниваться, скажем,
раз в час, отправляя всё накопленное за это время («оптом – дешевле»).

n  O DeliveryMode – устанавливает режим
доставки (интерактивный, фоновый, отложенная доставка). Подробнее о режимах
доставки мы поговорим в третьей части статьи, посвященной вопросам
администрирования и оптимизации.

n  O SuperSafe – ещё одна связанная с
оптимизацией опция. Её наличие требует обязательной записи сообщения в очередь,
даже если оно может быть передано немедленно. Помните, что, отключив эту опцию,
вы сэкономите немного на операциях записи, но лишитесь права именовать свой
сервер соответствующим стандарту SMTP, поскольку надёжность передачи – это его
основополагающее требование.

n  O QueueFileMode, O TempFileMode –
права доступа, устанавливаемые на вновь создаваемые файлы очереди и временные
файлы соответственно. По умолчанию – 0600, но в некоторых
экзотических (и весьма нежелательных с точки зрения безопасности) случаях
может потребоваться этот параметр изменить.

n  O MaxDaemonChildren – максимальное
количество одновременно работающих процессов Sendmail. Позволяет более
эффективно противостоять DoS-атакам, не допуская чрезмерной перегрузки сервера.

n  O DaemonPortOptions – параметры
прослушиваемых портов и интерфейсов, например:

O
DaemonPortOptions=Port=smtp,Addr=127.0.0.1,Name=MTA

n  O SmtpGreetingMessage – баннер
приветствия. По умолчанию имеет вид «$j Sendmail $v/$Z; $b», где $j
= $w – доменное имя хоста, $v – версия Sendmail, $Z – версия конфигурации,
$b – текущая дата. В процессе работы после имени хоста (точнее, на второе
место) выводится также поддерживаемый протокол:

serg$
sendmail -bs

220
domain.ru ESMTP Sendmail 8.13.4/8.13.4; Tue, 25 Apr 2006 13:24:11 +0400 (MSD)

n  O DoubleBounceAddress – указывает адрес,
на который следует отправлять уведомления об ошибке доставки уведомления об
ошибке. Другими словами, если с адреса [email-masked] пришло сообщение для
несуществующего пользователя, то Sendmail отошлёт отправителю уведомление «User
unknown». Однако если [email-masked] является фальшивым, то это уведомление также
вернётся с ошибкой. Чтобы разорвать порочный круг, вместо попыток и дальше
уведомить несуществующего отправителя, такое сообщение доставляется на указанный
адрес. По умолчанию крайним оказывается postmaster.

n  O MaxRecipientsPerMessage – ограничивает
число получателей, которые могут быть указаны в заголовке одного сообщения.
Наивная попытка бороться со спамом. Хотя и помогает несколько снизить нагрузку
на сервер и усложнить подбор адресов.

По мере рассмотрения дальнейших вопросов мы будем
встречаться и с другими опциями.

Queue Group Definitions

Эта секция отвечает за параметры работы почтовой очереди. Учитывая большое
влияние очереди на производительность сервера, мы подробно рассмотрим связанные
с ней вопросы в следующей части.

REWRITING RULES

Правила преобразования адресов. Sendmail в процессе обработки сообщения
разбирает имеющиеся в нём адреса отправителя и получателей, выполняя по мере
необходимости ряд преобразований. Каждый набор правил начинается директивой Sname[=n],
где n – необязательный номер набора, name – его кратное имя. Некоторые номера
(0, 3, 4) предназначены для строго определённых целей. Другие могут задаваться
произвольно (например, SParser1) и служат в основном для дополнения основных
наборов правил.

В процессе обработки наборы правил применяются
в определённом порядке (см. рис. 1). Любой адрес в первую очередь
проходит через набор 3, который отвечает за канонизацию, т.е. адрес приводится
к виду <имя_пользователя>@<доменное_имя>. Затем набор 0 определяет,
какому почтовому агенту это сообщение должно быть передано. От этого зависят
конкретные имена наборов правил, которые будут подставлены вместо S (обработка
адреса отправителя) и R (обработка адреса получателя) – они определяются в
M-строке соответствующего агента. На  последнем этапе адрес
обрабатывается 4-м набором, который выполняет финальные преобразования.

Рисунок 1. Последовательность
применения наборов правил

Сами правила внутри набора начинаются с буквы R
и имеют следующий формат:

R<шаблоны> <преобразование>    <комментарий>

Здесь <шаблоны> задают некоторый формат, на
соответствие которому проверяется входящая информация. В таблице 3
перечислены значения основных специальных символов. Справа (отделяется от левой
части символами табуляции) задаётся <преобразование> – описание того, что
нужно сделать с исходными данными, если они соответствуют шаблону в левой
части. В таблице 4 представлены некоторые операторы

Таблица 3. Значения основных
специальных символов

Шаблон

Значение

$*

Любое количество символов

$+

Один и больше символов

$-

Ровно один символ

$@

Ни одного символа

$=<знач>

Фрагмент равен значению
<знач>

$~<знач>

Фрагмент не равен <знач>

Таблица 4. Операторы
преобразования

Оператор

Значение

$<n>

Ссылка на фрагмент данных,
соответствующих шаблону. <n> – порядковый номер шаблона

$:

Применить правило один раз

$@

Применить правило и выйти
из набора

$>

Передать на обработку
другому набору правил

$( . . .$)

Поиск данных в базе

Очень напоминает регулярные выражения, не правда
ли? Например, следующее правило меняет адрес вида domain!user на user@domain
при условии, что часть «user» содержит хотя бы один символ:

R$* ! $+   $2 @ $1

Следующее правило (взято из набора SParse1) демонстрирует
взаимодействие с базой: вместо фрагмента, соответствующего шаблону (в угловых
скобках), подставляется значение из mailertable. Слово «lookup» здесь является
простым комментарием:

R< $+ > $*       $:
< $(mailertable $1 $) > $2   lookup

Конечно, настраивать эти правила вручную –
занятие неблагодарное, но в ряде случаев с их помощью можно добиться
нестандартных результатов.

Тестирование правил

Как видите, синтаксис правил обработки довольно сложен (по крайней мере,
читать их очень неудобно). Чтобы убедиться в правильности работы, в Sendmail
предусмотрен специальный режим тестирования:

serg$ sendmail
-bt

ADDRESS TEST
MODE (ruleset 3 NOT automatically invoked)

Enter <ruleset>
<address>

> 3,0 admin@my

canonify
input: admin @ my

Canonify2
input: admin < @ my >

Canonify2
returns: admin < @ my . domain . ru . >

canonify
returns: admin < @ my . domain . ru . >

parse
input: admin < @ my . domain . ru . >

Parse0
input: admin < @ my . domain . ru . >

Parse0           returns:
admin < @ my . domain . ru . >

ParseLocal
input: admin < @ my . domain . ru . >

ParseLocal
returns: admin < @ my . domain . ru . >

Parse1
input: admin < @ my . domain . ru . >

Parse1
returns: $# local $: admin

parse
returns: $# local $: admin

В данном примере мы прогоняем адрес admin@my
(предполагая, что полное имя нашего домена – my.domain.ru) через правила 3 и 0.
В первом столбце указываются имена наборов правил, во втором – тип данных (вход
или выход), и после двоеточия – обрабатываемая информация.

Как видите, сначала адрес канонизируется (краткое
имя домена дополняется до полного; обратите внимание на завершающую точку).
Затем Sendmail анализирует полученный адрес (определяется, что он является
локальным).

При необходимости можно повысить детализацию
выводимой информации, используя флаг отладки -d:

serg$ sendmail
-bt -d21.5

ADDRESS TEST
MODE (ruleset 3 NOT automatically invoked)

Enter <ruleset>
<address>

> 3 my.uudom.ru!user

canonify
input: my . uudom . ru ! user

rewritten as: my
. uudom . ru ! user < @ >

rewritten as: my
. uudom . ru ! user

rewritten as:
< my . uudom . ru ! user >

rewritten as: my
. uudom . ru ! user

Canonify2
input: user < @ my . uudom . ru >

rewrite: RHS $&{daemon_flags}
=> "(NULL)"

rewritten as:
$| user < @ my . uudom . ru >

rewritten as: user
< @ my . uudom . ru >

Canonify2
returns: user < @ my . uudom . ru >

rewritten as: user
< @ my . uudom . ru >

canonify
returns: user < @ my . uudom . ru >

Здесь показана канонизация адреса, заданного в
формате UUCP с детализацией 5-го уровня (21 – категория отладки, отвечающая за
трассировку правил обработки адресов). Выводится информация не только о том,
через какие наборы правил проходит адрес, но и какие действия выполняются.

Для выхода из режима отладки используйте команду
«/quit». Полный список доступных команд можно увидеть, введя «?».

Знакомьтесь: m4

Естественно, долго мириться с произволом формата sendmail.cf мало кто хотел,
поэтому со временем задача создания этого файла была возложена на макроязык m4.
Этот язык является универсальным и пригоден для решения достаточно широкого
круга задач, прежде всего связанных с обработкой текста. В частности, он
используется в Autoconf. Однако его использование для конфигурации Sendmail
является, пожалуй, наиболее известным применением.

Эпиграф к статье как нельзя лучше отражает
положение дел с настройками Sendmail. Сначала вы создаёте конфигурационный файл
в формате m4 (так называемый «master config», или mc-файл). Затем
макропроцессор m4, руководствуясь этим файлом, генерирует cf-файл из входящих в
поставку Sendmail шаблонов (макросов). Схематически этот процесс изображён на
рис. 2.

Рисунок 2. Схема работы
макропроцессора

Фактически, m4 собирает воедино элементы шаблонов
согласно опциям, имеющимся в mc-файле. Шаблоны сосредоточены в каталоге /usr/share/sendmail/cf/.
В общих чертах синтаксис языка рассматривается во врезке «Введение в m4».

Вносить изменения в шаблоны не рекомендуется
(поскольку они будут перезаписываться при обновлении операционной системы или
почтового сервера). Все необходимые корректировки лучше делать в mc-файле. В
последних версиях FreeBSD по умолчанию используется файл, соответствующий
доменному имени вашего сервера. Например, domain.ru.mc. Если у вас такого файла
нет, он будет автоматически создан при первом вызове команды make в каталоге /etc/mail,
используя при этом как шаблон файл freebsd.mc (при его отсутствии последует
ошибка).

Коротко состав mc-файла был
рассмотрен в предыдущей части статьи, сейчас чуть подробнее остановимся
на наиболее важных опциях:

n  include – встроенный макрос для
подключения других m4-файлов.

n  define – ещё один встроенный макрос
языка m4, позволяющий описывать другие макросы. Например, так можно определить
макрос LOCAL_MAILER_PATH со значением, содержащим полное имя локального агента
доставки:

define(`LOCAL_MAILER_PATH',
`/usr/local/bin/dspam')dnl

Ниже
представлен пример, позволяющий объявить smtp-агент как «дорогой»:

define(`confCON_EXPENSIVE', `True')

define(`SMTP_MAILER_FLAGS', `e')

n  FEATURE – одна из самых востребованных
директив. Аналогично рассмотренным в первой части статьи директивам OSTYPE и
DOMAIN, подключает соответствующий шаблон из каталога /usr/share/sendmail/cf/feature.
Через FEATURE реализуется подключение баз данных (см. в указанном каталоге
файлы access_db.m4, use_cw_file.m4, virtusertable.m4 и т. д.), различные
«управляющие» директивы, такие как nocanonify (отключение канонизации адреса,
что может быть оправдано на серверах, работающих исключительно в режиме
транзитной передачи), nodns (не использовать DNS-запросы для разрешения имён) и
т. д. Если вам интересно, какой код та или иная «фича» добавляет в cf-файл,
ознакомьтесь с содержимым шаблона в указанном выше каталоге.

n  MASQUERADE_AS – если вы хотите, чтобы
ваш почтовый сервер отправлял почту от имени, отличающегося от имени данного
хоста, можно использовать этот макрос. Дополнительно опции (такие как
MASQUERADE_EXCEPTION(`host.domain’), FEATURE (`masquerade_envelope’) и др.)
позволяют не маскировать указанные хосты, детализовать, какие именно
адреса (в заголовке, в конверте или все) должны маскироваться.

n  MAILER – подключает шаблон, отвечающий
за работу того или иного почтового агента, из каталога cf/mailer. В этих
шаблонах определяются имена и флаги соответствующих утилит, наборы правил
обработки адресов и M-строки конфигурационного файла. Директивы MAILER должны
быть указаны после всех остальных, в конце mc-файла.

Кстати, поскольку mc-файл – это обычный файл в
формате m4, то он может содержать помимо макроопределений и собственно входные
данные. При необходимости вы можете указать нужные cf-строки прямо здесь
(хорошим примером является mc-файл основного разработчика Sendmail Эрика Олмана
– /usr/share/sendmail/cf/cf/knecht.mc).

Последовательность подключения различных шаблонов
можно найти в самом начале cf-файла – обратите внимание на строки, начинающиеся
с «#### $Id:». Самым первым подключается cfhead.m4, в котором определены
основные макросы.

Если быть точным, то в команде m4 подключается
cf.m4 – вручную создание cf-файла обычно запускается такой командой:

m4 /usr/share/sendmail/cf/m4/cf.m4
domain.ru.mc > domain.ru.cf

Но одной из первых директив cf.m4 значится следующая:

ifdef(`OSTYPE', `dnl',`include(_CF_DIR_`'m4/cfhead.m4)dnl

Которая и выполняет подключение cfhead.m4. При
желании вы можете включить cf.m4 непосредственно в mc-файл (с помощью макроса include),
чтобы не указывать его в командной строке. Но во FreeBSD это не требуется – make
сделает всё, что нужно.

Файлы специального назначения

В первой части мы бегло окинули взглядом содержимое каталога /etc/mail.
Настало время познакомиться с расположенными в нём конфигурационными файлами и
их задачами более подробно.

Файл aliases

Файл псевдонимов служит для сопоставления адреса электронной почты с
конкретным получателем. По умолчанию, Sendmail работает с системными
пользователями. То есть если у вас есть пользователь admin, то автоматически
для него создаётся одноимённый почтовый ящик. Однако в ряде случаев
необходимо (или просто удобно) перенаправить входящую почту, направленную на
тот или иной адрес, другому пользователю. Например, работа с почтой с
правами root – не самая лучшая идея. А как же тогда читать системные сообщения,
которые традиционно отправляются на этот адрес? Ответ можно увидеть в
файле aliases:

root:            admin

bin:             root

bind:            root

. . . пропущено . . .

uucp:            root

abuse:           root

security:        root

ftp:             root

Формат достаточно прост: слева – почтовый адрес,
на который направляется письмо, справа – адрес, куда письмо следует
перенаправить.

Приведённый фрагмент показывает, что по умолчанию
почта «служебных» пользователей будет перенаправляться пользователю root, в то
время как почта пользователя root уйдёт в ящик администратора admin (это
следует задать вручную).

Всё работает правильно благодаря тому, что
подстановка псевдонимов выполняется рекурсивно – после первой замены
осуществляется ещё один «прогон» с новым адресом, и так далее, пока не будет
выполнено ни одной подстановки. Кстати, чтобы не допустить бесконечной
подстановки в случае ошибки, когда образуется петля псевдонимов, полезно
использовать опцию «O MaxAliasRecursion», которая задаёт максимальное число
«проходов» по списку (в mc-файле задаётся как define(`confMAX_ALIAS_RECURSION’)).

В правой части может находиться не только один
пользователь. Перенаправление может выполняться для нескольких пользователей
(они разделяются запятыми), на адрес в другом домене, на список адресов,
указанный в файле (подключается с помощью конструкции «:include: <имя_файла>»).

Можно отдавать почту на обработку внешней
программе, используя операцию конвейера (в данном примере почта, пришедшая
на адрес spam-me, отдаётся на обработку спам-фильтру dspam для
переобучения его байесового анализатора):

spam-me:    "| dspam --user
me --class=spam --source=error"

Помимо системного файла aliases пользователи
могут создавать свои файлы перенаправлений – ~/.forward (точнее, будут
проверяться файлы, указанные в директиве confFORWARD_PATH). Формат ещё проще –
в них просто указываются адреса, на которые следует перенаправлять входящие
сообщения. Нужно заметить, что когда Sendmail запускается с правами
непривилегированного пользователя, этот пользователь должен иметь права на
чтение всех .forward-файлов в домашних каталогах.

Файл access

Формат этого файла, отвечающего за доступ к серверу с различных
адресов, достаточно прост. Каждая строка состоит из разделённых пробелами или
табуляцией объекта и действия. В качестве объекта могут выступать: IP-адрес;
подсеть, заданная неполным IP-адресом; доменное имя (будет относиться и ко всем
поддоменам); адрес электронной почты. Действия: OK (всегда принимать почту,
даже если другими директивами это запрещено), RELAY (разрешить транзит), REJECT
(отклонить соединение), DISCARD (отклонить без выдачи сообщения об ошибке).
Можно указывать и конкретный код ответа (см. пример).

Комментарии, как обычно, предваряются символом
«#». Например:

# Блокируем конкретный
IP-адрес

1.2.3.4     REJECT

# Разрываем соединения из
указанного домена

spammers.dom      550 Closed for
you.

# Разрешаем транзит из
локальной сети

192.168     RELAY

# Разрешаем принимать на ящик
[email-masked] любую почту

[email-masked]  OK

Обратите внимание, что «действия», которые
разрешают принимать входящие соединения, указываются в cf-файле в классе {Accept}:

C{Accept}OK RELAY

В данном примере такое разрешение будет
распространяться на действия «OK» и «RELAY».

Раньше access-файл широко использовался для
борьбы со спамом, когда в него заносились спамерские адреса/сети/домены. В наши
дни, естественно, это не представляется разумным.

Однако если вы работаете лишь с определёнными
почтовыми серверами (например, принимаете почту только от вышестоящей
организации и своих филиалов), то с помощью этого файла можно довольно легко
ограничить круг общения вашего сервера.

Файл relay-domains

Ещё один файл, разрешающий транзитную пересылку – relay-domains. Здесь, в
отличие от access, указываются домены-получатели, для которых данный сервер
может принимать сообщения и выполнять их дальнейшую пересылку. Например, если
вы хотите, чтобы сервер backup.mail.domain.ru работал как резервный для mail.domain.ru,
то создайте файл /etc/mail/relay-domains следующего содержания:

mail.domain.ru

И подключите его следующей директивой:

define(`confCR_FILE', `/etc/mail/relay-domains')

Файл mailertable

В файле mailertable определяются агенты, ответственные за обработку почты
для определённых доменов.

Файл virtusertable

Здесь задаётся соответствие между виртуальными адресами обслуживаемых
доменов и именами реальных пользователей. Необходимость в нём возникает тогда,
когда несколько адресов в обслуживаемых доменах имеют одинаковые имена
пользователей (например, [email-masked] и [email-masked]).

В этом случае вы можете занести в virtusertable
следующие строки:

[email-masked]         admin-dom1

[email-masked]         admin-dom2

@domain1.ru              error:nouser
User not found

То есть входящая почта будет раскладываться по
ящикам разных пользователей. Благодаря третьей строке вся почта в domain1.ru
для любых пользователей, кроме описанных в virtusertable (в нашем примере это admin),
будет отклоняться. Домен domain2.ru будет обслуживаться традиционно, то есть
при получении письма, например, для [email-masked], будет предприниматься
попытка доставить его реальному пользователю user.

Файл genericstable

Этот файл решает обратную задачу: в условиях виртуального хостинга ставит в
соответствие имени пользователя домен, с которого этот пользователь будет
отправлять сообщения.

Примеры конфигурации

Рассмотрим несколько практических примеров. При их решении конфигурационные
файлы целиком приводиться не будут – покажем только опции, необходимые для
решения конкретной задачи. Во всех примерах подразумевается, что DNS настроен
должным образом (см. врезку «DNS, DNS, DNS…»).

Пример 1. Использование «умного» хоста

Вы хотите построить почтовый сервер для обслуживания локальной сети, однако
хотели бы переложить заботу об определении маршрута писем на сервер вашего
провайдера (предполагается, что провайдер не запрещает транзитную пересылку
вашей почты). В этом случае достаточно пересобрать конфигурационный файл со
следующей опцией в mc-файле:

define(`SMART_HOST',
`1.2.3.4')

Здесь 1.2.3.4 – адрес smtp-релея вашего
провайдера. Теперь вся исходящая почта будет отправляться на указанный сервер,
который и будет заниматься дальнейшей рассылкой.

Пример 2. Почтовый сервер в
режиме шлюза

Предположим, у вас есть локальная сеть с размещёнными в ней двумя почтовыми
серверами (inner1.domain.ru и inner2.domain.ru). Вы хотели бы обеспечить
возможность полноценной работы этих серверов, но без непосредственного
подключения к Интернету. Настроим на машине, выполняющей роль шлюза, сервер Sendmail,
задачей которого – взаимодействовать с внешними smtp-серверами и пересылать
полученные от них сообщения на серверы в локальной сети.

1. В mailertable заносим строчки:

inner1.domain.ru  smtp:[inner1.domain.ru]

inner2.domain.ru  smtp:[inner2.domain.ru]

Теперь почта на указанные домены будет по smtp
пересылаться на указанные хосты. Квадратные скобки требуют работать с хостом по
его A-записи, а не по MX-записи в базе доменных имен (которая указывает на
адрес шлюза).

2. Для отправки почты нужно разрешить пересылку
сообщений с внутренних серверов (указав для них в файле access значение RELAY),
а внутренние серверы настроить на отправку сообщений вышестоящему серверу
(в случае с Sendmail это достигается использованием опции define(`SMART_HOST’,
`<ip-адрес>’)).

3. Подключим соответствующие файлы в mc-файле:

FEATURE(mailertable, `hash -o
/etc/mail/mailertable')dnl

FEATURE(access_db, `hash -o
-T<TMPF> /etc/mail/access')dnl

После чего нужно пересобрать конфигурационный
файл и перезапустить сервер:

root# make all install restart

Пример 3. Виртуальный почтовый сервер

У вас есть почтовый сервер с Sendmail. Требуется обеспечить на нём
обслуживание двух доменов – вашего (domain.ru) и домена одного из клиентов (client.domain.ru).
Предполагается, что принято следующее соглашение об именах пользователей:
пользователи domain.ru имеют обычные имена (например, user), а для client.domain.ru
используются имена вида user-client. Вносим в конфигурацию следующие изменения:

1. В local-host-names заносим обслуживаемые
домены:

domain.ru

client.domain.ru

2. В virtusertable записываем «шаблон»
преобразования имён:

@client.domain.ru        %1-client

Эта строка означает следующее – при получении
письма на любой адрес в домене client.domain.ru следует отдать его
пользователю, имя которого соответствует указанному в адресе (%1) плюс суффикс
«-client». Почта на другие домены будет обслуживаться обычным образом.

3. В domain.ru.mc включаем поддержку
соответствующих файлов:

FEATURE(virtusertable, `hash
-o /etc/mail/virtusertable')dnl

define(`confCW_FILE', `-o /etc/mail/local-host-names')dnl

4. Всё пересобираем и перезапускаем сервер:

root# make all install restart

Если после этого выполнить тестирование, то можно
увидеть, что разрешение имён выполняется должным образом:

> 3,0 [email-masked]

canonify
input: serg @ client . domain . ru

Canonify2
input: serg < @ client . domain . ru >

Canonify2
returns: serg < @ client . domain . ru . >

canonify
returns: serg < @ client . domain . ru . >

parse
input: serg < @ client . domain . ru . >

Parse0
input: serg < @ client . domain . ru . >

Parse0
returns: serg < @ client . domain . ru . >

ParseLocal
input: serg < @ client . domain . ru . >

ParseLocal
returns: serg < @ client . domain . ru . >

Parse1
input: serg < @ client . domain . ru . >

Recurse
input: serg-client

canonify
input: serg-client

Canonify2
input: serg-client

Canonify2
returns: serg-client

canonify
returns: serg-client

parse
input: serg-client

Parse0
input: serg-client

Parse0
returns: serg-client

ParseLocal
input: serg-client

ParseLocal
returns: serg-client

Parse1
input: serg-client

Parse1
returns: $# local $: serg-client

parse
returns: $# local $: serg-client

Recurse
returns: $# local $: serg-client

Parse1           returns:
$# local $: serg-client

parse
returns: $# local $: serg-client

Продолжение следует…

Как видите, Sendmail является очень гибкой программой, способной эффективно
решать разнообразные задачи. Сложность формата cf-файла перекладывается на плечи
макропроцессора m4, оставляя вам возможность заниматься настройкой на «верхнем»
уровне, не вдаваясь в детали синтаксиса. Впрочем, при необходимости вы вполне
можете вносить изменения и непосредственно в sendmail.cf. Но просто настроить
сервер недостаточно, особенно если речь идёт о высокой нагрузке. Поэтому в
следующий раз мы поговорим о вопросах сопровождения сервера и его оптимизации.
Также коснёмся и вопросов безопасности.

Приложение

Введение в m4

В далёком 1977 году, когда Sendmail ещё даже не планировался, Брайан Керниган
(Brian Kernighan) и Деннис Ритчи (Dennis Ritchie), внёсшие немалый вклад в
развитие UNIX-систем (достаточно упомянуть язык программирования C),
разработали макропроцессор m4.

Его основное назначение – «пропускать» через себя
поток информации, выполняя макроподстановки по мере их обнаружения. Он с
успехом может использоваться для программирования, генерирования документации.
Но наиболее популярным применением является генерация конфигурационных файлов и
прочие вопросы администрирования.

Фундаментом m4 является набор встроенных
макросов, которые служат для управления потоком данных, ветвлений, определения
пользовательских макросов, некоторых математических операций.

Язык m4 отличается довольно-таки своеобразным
синтаксисом. Во-первых, в нём различаются открывающая и закрывающая
кавычки. По умолчанию используются символы «`» и «’», которые в случае
необходимости можно переопределить с помощью встроенного макроса changequote.
Во-вторых, в качестве признака конца строки используется макрос dnl. (То есть
после него вы можете указывать любые комментарии). Для управления потоком
служит макрос divert. В частности, divert(0) очищает буфер и направляет вывод в
нулевой поток (всего существует 10 выходных потоков 0-9, которые на выходе
объединяются в порядке их нумерации). Конструкции $n, где n – некоторое число,
являются ссылками на параметры макроса, размещённые на соответствующих местах
(например, $1 ссылается на первый параметр указанного макроса). Рассмотрим
простейший пример. Для начала создадим файл макроопределений:

serg$ vi test.m4

divert(0)dnl

define(`header',
`<H1>$1</H1>')dnl

define(`footer',
`<HR><SMALL>$1</SMALL>')dnl

define(`company', `Наша
компания')dnl

Здесь мы определили три макроса, причём в header
и footer используются ссылки на первый аргумент, т.е. вызов этих макросов
подразумевается с одним параметром. Этот файл мы подключим как шаблон. Далее
файл с исходной информацией (обратите внимание на макро-вставки):

serg$ vi test.in

header(`Страница компании')

company рада приветствовать
Вас на своём сайте!

footer(`Заходите снова!')

Результат работы будет таким:

serg$ m4
test.m4 test.in

<H1>Страница
компании</H1>

Наша компания
рада приветствовать Вас на своём сайте!

<HR><SMALL>Заходите
снова!</SMALL>

Фактически, несколько последовательных файлов
рассматриваются как единый поток. То есть того же эффекта можно добиться,
объединив макроопределения и исходный текст в одном файле.

Чтобы подробнее познакомится с m4, просмотрите
страницу справки man m4(1). Также много интересного можно найти в шаблонах
Sendmail.

DNS, DNS, DNS…

Для нормальной работы любого MTA очень важную
роль играет правильная настройка DNS-сервера. Адрес почтового сервера,
обслуживающего тот или иной домен, не обязан совпадать с самим доменным именем.

Например, вы можете посчитать целесообразным
выделить для обслуживания почты, адресованной в domain.ru, отдельный сервер mail.domain.ru.
Как же удалённый smtp-сервер поймёт, куда следует отправлять почту?

Для этого в DNS предусмотрен специальный тип
записи – MX (Mail eXchanger). Этот же механизм позволяет организовать резервные
серверы, которые возьмут на себя обслуживание (или, по крайней мере,
временное размещение) сообщений в случае недоступности основного MTA.
Рассмотрим фрагмент файла зоны:

domain     IN      MX      10  mail.domain.ru.

IN      MX      20
backup.top.ru.

dom2       IN      MX      10
mail.domain.ru.

IN      MX      20
backup.top.ru.

Эти строки определяют, что почта для domain и
dom2 будет обслуживаться машиной mail.domain.ru. Если этот сервер окажется недоступен,
почта должна будет направляться на backup.top.ru. Приоритет использования
MX-записей задаётся числом перед именем хоста – чем это число меньше, тем выше
приоритет (т.е. сначала будет предприниматься попытка доставить почту на этот
хост).

Впрочем, протоколом SMTP предусмотрено, что если
для некоторого домена отсутствует MX-запись, то почту следует направлять
непосредственно на хост, определяемый по соответствующей A-записи.

Хочешь регулярно читать все последние статьи в журнале? Подпишись на журнал «Системный администратор»!

— Версия статьи для печати.

Обсуждение статьи:

Тема:

Сообщение:

Имя:

E-mail:

К статьям из журнала 06.2006 >>
Вернуться в раздел статей >>

Новые статьи:

Дефекты проектирования Intel Core 2 Duo. Аналитический обзор с точки зрения безопасности

Создаем персональный набор ярлыков для каждого пользователя в папке «Мой Компьютер»

Сколько стоит переход на легальный софт?

PowerShell: часто задаваемые вопросы

Жучки в электронных письмах

Последние темы форума:

Админский приз (09.09.2008)

WIN XP + win 2k server +AD не могу войти (09.09.2008)

Новый раздел 1С (09.09.2008)

как узнать через IP адрес имя компьютера? (09.09.2008)

подключение к интернет через bluetooth (09.09.2008)

Обсуждаемые статьи:

Сколько стоит переход на легальный софт? [22] (07.09.2008)

Дефекты проектирования Intel Core 2 Duo. Аналитический обзор с точки зрения безопасности [10] (06.09.2008)

Есть такая профессия [25] (02.09.2008)

Обзор систем резервного копирования [6] (27.08.2008)

Как купить ПО от Microsoft? Особенности приобретения и использования OEM-версий [51] (21.08.2008)

© Все права защищены, по всем вопросам обращаться сюда.