 |
|
|
|
Как работает Sendmail? Полезные подробности. Часть 2: Вопросы конфигурации
Как работает Sendmail? Полезные подробности Часть 2: Вопросы конфигурации Видел я этот сендмайл – конфиги для конфигов, чтобы создать конфиги!
Цитата с http://forum.oszone.net Одна из самых сильных сторон Sendmail – функциональная мощь этой программы. Но вот только запрятана она порой в дальних уголках конфигурационных файлов. Ужас, летящий на крыльях ночи При первом просмотре основной конфигурационный файл, sendmail.cf, особенно ближе к концу, напоминает скорее двоичный код, чем что-то читаемое, и тем более редактируемое. Но на самом деле всё не так уж и сложно – всему виной перегруженность «знаками пунктуации», сбивающими с толку и не позволяющими без специальной подготовки сложить их во что-то осмысленное. Назначение файла sendmail.cf – определить опции работы Sendmail и правила обработки сообщений. Собственно говоря, включение в него правил и обусловливает его перегруженность и небывалый размер (обычно он составляет несколько тысяч строк). Но зато это значительно повышает гибкость конфигурирования. Несмотря на то что cf-файл, в общем-то, не предусматривает прямого редактирования (для этого служит механизм m4, о котором поговорим в следующем разделе) и генерируется автоматически, он достаточно хорошо прокомментирован. Рассмотрим представленные в нём секции и наиболее характерные параметры. Строки, начинающиеся с «#» – комментарии. Тип параметра задаётся первой буквой строки (см. таблицу 1). Строка, начинающаяся с пробельного символа, – продолжение предыдущей. Пустые строки игнорируются. Таблица 1. Коды строк sendmail.cf
Классы предназначены для описания имён, объединённых одним признаком. Сразу после буквы C следует односимвольное или многосимвольное (в фигурных скобках) имя класса. Например, класс запрещённых для использования в доменном имени символов определяется как «CB! % @ : ^». Макросы представляют собой что-то типа переменных, позволяя в дальнейшем обращаться к единожды определённому макросу по имени (перед которым указывается префикс $). Существует ряд предопределённых макросов (некоторые из них представлены в таблице 2), которые можно использовать по мере необходимости. Для них зарезервированы строчные буквы. Для иного использования предназначены прописные буквы или многосимвольные имена. Таблица 2. Предопределённые макросы
F-строки заносят в определённый класс содержимое указанного файла. Строки типа K задают базы данных, которые в дальнейшем могут использоваться в правилах преобразования. Например, так подключается база mailertable: Kmailertable hash -o /etc/mail/mailertable Про остальные типы строк у нас будет возможность поговорить чуть позже. Рассмотрим некоторые секции файла sendmail.cf: Local info Здесь определяются общие параметры, влияющие на работу MTA:
Fw-o /etc/mail/local-host-names Здесь параметр -o говорит о том, что не нужно выдавать сообщение об ошибке, если указанный файл отсутствует. Имя файла – используемое по умолчанию, но в принципе может быть произвольным. В старых версиях Sendmail использовался файл /etc/sendmail.cw. Options Эта достаточно большая секция содержит массу опций, управляющих теми или иными аспектами работы почтового сервера. Ниже приведено несколько примеров (для некоторых опций по старой памяти существуют сокращённые однобуквенные наименования, но рекомендуется использовать новый стиль):
O DaemonPortOptions=Port=smtp,Addr=127.0.0.1,Name=MTA serg$ sendmail –bs
По мере рассмотрения дальнейших вопросов мы будем встречаться и с другими опциями. 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. Операторы преобразования
Очень напоминает регулярные выражения, не правда ли? Например, следующее правило меняет адрес вида domain!user на user@domain при условии, что часть «user» содержит хотя бы один символ: R$* ! $+ $2 @ $1 Следующее правило (взято из набора SParse1) демонстрирует взаимодействие с базой: вместо фрагмента, соответствующего шаблону (в угловых скобках), подставляется значение из mailertable. Слово «lookup» здесь является простым комментарием: R< $+ > $* $: < $(mailertable $1 $) > $2 lookup Конечно, настраивать эти правила вручную – занятие неблагодарное, но в ряде случаев с их помощью можно добиться нестандартных результатов. Тестирование правил Как видите, синтаксис правил обработки довольно сложен (по крайней мере, читать их очень неудобно). Чтобы убедиться в правильности работы, в Sendmail предусмотрен специальный режим тестирования: serg$ sendmail –bt
> 3,0 admin@my
В данном примере мы прогоняем адрес admin@my (предполагая, что полное имя нашего домена – my.domain.ru) через правила 3 и 0. В первом столбце указываются имена наборов правил, во втором – тип данных (вход или выход), и после двоеточия – обрабатываемая информация. Как видите, сначала адрес канонизируется (краткое имя домена дополняется до полного; обратите внимание на завершающую точку). Затем Sendmail анализирует полученный адрес (определяется, что он является локальным). При необходимости можно повысить детализацию выводимой информации, используя флаг отладки -d: serg$ sendmail -bt -d21.5
> 3 my.uudom.ru!user
Здесь показана канонизация адреса, заданного в формате 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-файла был рассмотрен в предыдущей части статьи, сейчас чуть подробнее остановимся на наиболее важных опциях:
define(`LOCAL_MAILER_PATH", `/usr/local/bin/dspam")dnl Ниже представлен пример, позволяющий объявить smtp-агент как «дорогой»: define(`confCON_EXPENSIVE", `True") define(`SMTP_MAILER_FLAGS", `e")
Кстати, поскольку 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 # Разрешаем принимать на ящик abuse@domain.ru любую почту abuse@domain.ru 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 Здесь задаётся соответствие между виртуальными адресами обслуживаемых доменов и именами реальных пользователей. Необходимость в нём возникает тогда, когда несколько адресов в обслуживаемых доменах имеют одинаковые имена пользователей (например, admin@domain1.ru и admin@domain2.ru). В этом случае вы можете занести в virtusertable следующие строки: admin@domain1.ru admin-dom1 admin@domain2.ru admin-dom2 @domain1.ru error:nouser User not found То есть входящая почта будет раскладываться по ящикам разных пользователей. Благодаря третьей строке вся почта в domain1.ru для любых пользователей, кроме описанных в virtusertable (в нашем примере это admin), будет отклоняться. Домен domain2.ru будет обслуживаться традиционно, то есть при получении письма, например, для user@domain2.ru, будет предприниматься попытка доставить его реальному пользователю 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-серверами и пересылать полученные от них сообщения на серверы в локальной сети.
inner1.domain.ru smtp:[inner1.domain.ru] inner2.domain.ru smtp:[inner2.domain.ru] Теперь почта на указанные домены будет по smtp пересылаться на указанные хосты. Квадратные скобки требуют работать с хостом по его A-записи, а не по MX-записи в базе доменных имен (которая указывает на адрес шлюза). 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. Вносим в конфигурацию следующие изменения:
domain.ru client.domain.ru @client.domain.ru %1-client Эта строка означает следующее – при получении письма на любой адрес в домене client.domain.ru следует отдать его пользователю, имя которого соответствует указанному в адресе (%1) плюс суффикс «-client». Почта на другие домены будет обслуживаться обычным образом. FEATURE(virtusertable, `hash -o /etc/mail/virtusertable")dnl define(`confCW_FILE", `-o /etc/mail/local-host-names")dnl root# make all install restart Если после этого выполнить тестирование, то можно увидеть, что разрешение имён выполняется должным образом: > 3,0 serg@client.domain.ru
Продолжение следует… Как видите, 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
Фактически, несколько последовательных файлов рассматриваются как единый поток. То есть того же эффекта можно добиться, объединив макроопределения и исходный текст в одном файле. Чтобы подробнее познакомится с 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-записи. |
Сергей Супрунов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
