Примеры файлов конфигурации
Категория: Электронная почта | Автор: admin | 30-05-2010, 12:05 | Просмотров: 3290

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

Собранные нами в различных системах конфигурационные файлы содержали "мусор", который наслоился в процессе их модификации. Перед включением файлов в книгу мы "почистили" их, исправили грамматические ошибки, несоответствия и пр. Поэтому файлы предстанут перед читателями не совсем в том виде, в котором они находились на реальных узлах. Тем не менее они отражают вполне реальные конфигурации.

 

Домашний компьютер студента факультета вычислительной техники

 

В центре нашего первого примера — студент Роб Браун, который имеет дома Linux-систему (gw.synack.net) и занимается виртуальным хостингом для почтовых доменов своих друзей: xinetd.org, teich.net и cubecast.com.

Роб выполняет хостинг и для собственного домена synack.net. Правильный адресат входящей почты определяется посредством протокола LDAP. Для управления виртуальным хостингом используется средство virtusertable, а для обработки исходящей почты — средство genericstable. Из всего многообразия способов управления исходящей почтой только средство genericstable позволяет менять как имя пользователя, так и адрес домена получателя.

Принадлежащий Робу файл для средства genericstable (называется outmap) содержит следующие записи:

 

bbraun      rob@synack.net

stabilej    jon@synack.net

teich       oren@teich.net

 

 

С целью отслеживания спама Роб ведет список DNS Realtime Blackhole (dnsbl). Он пользуется также функциями маскирования для того, чтобы любые исходящие сообщения, адреса которых еще не модифицированы средством genericstable, выглядели как поступившие от пользователя пользователь@synack.net, а не от пользователь@gw.synack.net. Ниже приведено полное содержимое файла gw.mc:

 

divert(0)

VERSIONID('@(#)synack.net.mc 8.7  (Berkeley)5/19/1998')

OSTYPE(linux)

DOMAIN(generic)

FEATURE(dnsbl)

FEATURE(virtusertable,   '/etc/mail/inmap')

FEATURE(genericstable,   '/etc/mail/outmap')

GENERICS_DOMAIN_FILE(‘/etc/mail/local-host-names’)

MASQUERADE_AS(synack.net)

FEATURE (‘masquerade_envelope')

FEATURE ('ldap_routing’)

LDAPROUTE_DOMAIN (‘synack.net’)

define ('confLDAP_DEFAULT_SPEC', '-h gw.synack.net -b dc=synack,dc=net')

MAILER(local)

MAILER(smtp)

 

 

Файл /etc/mail/local-host-names (раньше он назывался sendmail.cw) содержит имена компьютеров и доменов, для которых данный узел принимает почту. Средство use_cw_file, подключающее этот файл, скрыто в доменном файле generic (его содержимое приведено в следующем разделе). Ретрансляция отключена по умолчанию, потому что файл /etc/mail/relay-domains обычно пуст. Но в данном случае этот файл содержит имена доменов, для которых узел gw.synack.net осуществляет виртуальный хостинг. База данных LDAP сконфигурирована посредством файла ldap.conf, в котором задается уникальное имя корневого каталога LDAP, узел для сервера LDAP и порт:

 

BASE dc=synack, dc=net

HOST gw.synack.net

PORT 389

 

 

Сама база данных LDAP формируется на основе текстового файла следующего вида:

 

dn: uid=rob,  dc=synack, dc=net

objectClass: inetLocalMailRecipient

mailLocalAddress:  rob@synack.net

mailRoutingAddress:

uid:rob

 

dn: uid=webmaster, dc=synack, dc=net

objectClass:  inetLocalMailRecipient

mailLocalAddress:

mailRoutingAddress:

uid:webmaster

 

dn: uid=teich, dc=synack,  dc=net

objectClass: inetLocalMailRecipient

mailLocalAddress: teich@synack.net

mailRoutingAddress:

uid:teich

 

dn: uid=xinetd, dc=synack, dc=net

objectClass:  inetLocalMailRecipient

mailLocalAddress: xinetd@synack.net

mailRoutingAddress: xinetd

uid:xinetd

 

 

Три первые записи служат для установки соответствия между зарегистрированными именами rob, webmaster и oren и их псевдонимами. Четвертая запись представляет собой список рассылки, который связан с локальным файлом псевдонимов и обрабатывается программой Majordomo. Соответствующие записи файла /etc/mail/aliases выглядят так:

 

xinetd:  "|/usr/local/majordomo/wrapper resend -1 test xinetd-list"

xinetd-list:   : include:/usr/local/majordomo/lists/xinetd

xinetd-owner: bbraun

owner-xinetd: bbraun

xinetd-request: bbraun

xinetd-approval: bbraun

 

 

Рассматривая первый пример, мы познакомились с несколькими вспомогательными файлами. Следующие примеры более наглядно иллюстрируют, что из себя представляет конфигурация программы sendmail, и не содержат текстов вспомогательных файлов.

Не забывайте, что в любом примере для программы sendmail DNS-записи MX играют важную роль и должны соответствовать имеющейся конфигурации.

 

Небольшая компания, использующая программу sendmail

 

В следующем примере мы проанализируем конфигурационные файлы небольшой компании Sendmail, Inc, знающей, как правильно настраивать программу sendmail. Их почтовая система включает главный почтовый сервер, который выполняет функцию концентратора электронной почты для входящих сообщений и служит "интеллектуальным" узлом для исходящих сообщений. Сначала мы познакомимся с конфигурацией клиентов, а затем изучим более сложную конфигурацию сервера.

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

 

Клиентские компьютеры на узле sendmail.com

 

Файл smi-client.mc для клиентских компьютеров довольно прост. Он ссылается на сервер smtp.sendmail.com, что в действительности является псевдонимом (DNS-запись CNAME) узла katroo.sendmail.com. Применение записи CNAME удобно тем, что ее легко изменить при смене главного почтового сервера.

Обратите внимание на то, что файл датирован октябрем 1998 года. В течение периода, прошедшего с того момента, программа sendmail неоднократно обновлялась, однако конфигурационный файл не потребовалось изменять.

 

divert(-1)

##### Этот файл, содержит настройки для клиентских компьютеров

##### компании Sendmail,  Inc.; версия 8.9.3.

divert(0)

VERSIONID('@(#)smi-client.mc 1.0  (Sendmail)  10/14/98')

OSTYPE('bsd4.4') FEATURE ('nocanonifу’)

undefine('ALIAS_FILE')

define (‘MAIL_HUB',   'smtp.sendmail.com')

define ('SMART_HOST',   ‘smtp.sendmail.com')

define ('confFORWARD_PATH',   '’)

MAILER(‘local')

MAILER ('smtp’)

 

 

Макроконстанты MAIL_HUB и SMART_HOST задают перенаправление входящих и исходящих сообщений на узел smtp.sendmail.com. DNS-записи MX должны указывать на то, что этот узел имеет более высокий приоритет (более низкий номер записи MX), чем отдельные клиентские компьютеры. Путь для файлов .forward устанавливается пустым, файл псевдонимов также пуст. Расшифровка псевдонимов осуществляется на сервере. Средство nocanonify установлено здесь для экономии времени, поскольку поиск в службе DNS выполняется на главном компьютере.

 

Главный компьютер на узле sendmail.com

 

Почтовый сервер на узле sendmail.com, как правило, подвергается наиболее интенсивным атакам извне. Он должен обеспечивать высокую эффективность при обработке спама, быть устойчивым ко всем почтовым атакам и защищать клиентские компьютеры. Вот файл, задающий конфигурацию сервера.

 

divert(-1)

##### Серверный файл katroo.mc; версия 8.9.3 divert(0)

VERSIONID(‘@(#)katroo.mc       2.1   (sendmail)  10/19/98')

OSTYPE(‘solaris2')

DOMAIN ('generic’)

MASQUERADE_AS( sendmail.com')

MASQUERADE_DOMAINCsendmail.com')

undefine('BITNET_RELAY')

undefine('UUCP_RELAY’)

define (‘confCHECK_ALIASES',   'True')

define ('confCOPY_ERRORS_TO’,  ‘Postmaster')

define ('confEBINDIR',   '/usr/lib')

define('confERROR_MODE’   'm')

define ('confHOST_STATUS_DIRECTORY’,   '.hoststat')

define ('confNO_RCPT_ACTION',   'add-to-undisclosed’)

define ('confPRIVACY_FLAGS', authwarnings,needmailhelo, noexpn, novrfy')

define ('confTRUSTED_USERS’,   'majordomo')

define ('confMAX_DAEMON_CHILDREN',   ‘30')

FEATURE ('allmasquerade')

FEATURE ('masquerade_entire_domain')

FEATURE ('masquerade_envelope')

FEATURE (‘always_add_domain')

FEATURE ('local_lmtp')

define (‘LOCAL_MAILER_FLAGS',   'SXfmnz9PE')

FEATURE ('mailertable',   'hash /etc/mail/mailertable')

FEATURE ('virtusertable',   'hash /etc/mail/virtusertable')

MAILER ('local’)

MAILER ('smtp’) .

 

LOCAL_CONFIG

'###### Регулярное выражение для отбрасывания:'

'#      * локальных числовых адресов из доменов aol.com и

'#     * локальных адресов из домена juno.com, начинающихся с цифры'

Kcheckaddress regex -aSMATCH

    ^[0-9]+<@(aol|msn).com|[0-9][^<]*<@juno. com).?

'###### Имена,  которые не допускаются в строке "То:"'

C{RejectToLocalparts}      friend you

C(RejectToDomains)         public.com

 

LOCAL_RULESETS

HTo: $>CheckTo

SCheckTo

R$={RejectToLocalparts)@$* $#error $: "553 Header error"

R$*@$=(RejectToDomains) S#error $: "553 Header error"

 

HMessage-Id:  $>CheckMessageId

SCheckMessageld

R< $+ @ $+>     $@ OK

R$*       $#error $: "553 Header error"

 

LOCAL_RULESETS

SLocal_check_mail

'# проверка адресов на соответствие различным регулярным выражениям'

R$*       $: $>Parse0 S>3 $1

R$+       $: S(checkaddress $1 $)

R@MATCH   $#error $:  "553 Header error"

 

 

Макрос LOCAL_CONFIG, расположенный в конце файла, определяет правила проверки заголовков на предмет наличия в них сведений о различных вирусах и известных спамерах. Мы не будет комментировать данный фрагмент, поскольку привели его для тех, кто хорошо знаком с файлом конфигурации и сможет адаптировать его для своего узла.

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

Доменный файл generic.m4, на который имеется ссылка в файле katroo.mc, — это файл, включенный в дистрибутив sendmail в качестве примера. Он содержит следующие записи:

 

divert(-1)

'######## Файл generic.m4 из каталога domain’

divert(0)

VERSIONID{'$Id:  generic.m4,v 8.15 1999/04/04 00:51:09 ca Exp $')

define ('confFORWARD_PATH',   '$z/. forward.$w+$h:$z/.forward+$h:

$z/.forward.$w:$z/. forward')

define ('confMAX_HEADERS_LEN GTH',   '32768')

FEATURE ('redirect’)

FEATURE ('use_cw_file’)

EXPOSEDJJSER('root')

 

 

Строка, где определяется опция confFORWARD_PATH, была разбита нами на две части, так как не умещалась на странице.

 

Еще один пример модели с главным почтовым сервером

 

XOR Inc. — это средняя по величине компания, в которой имеется один главный почтовый сервер. В общих чертах применяющаяся здесь архитектура почтовой системы напоминает ту, что используется на узле sendmail.com, но реализована она при помощи других конфигурационных средств.

Клиентский файл конфигурации имеет следующий вид:

 

divert(-1)

##### Файл xor-client.mc; все клиенты пересылают

##### свои сообщения узлу xor.com.

divert(0)

VERSIONID('@(#)tcpproto.mc8.5  (Berkeley)  3/23/96')

OSTYPE('bsdi')

define ('confPRIVACY_FLAGS',   'noexpn')

FEATURE ('nullclient',   'xor.com')

 

 

Этот файл содержит минимум конфигурационных опций. Даже локальная почта пересылается на узел xor.com (указан в определении средства nullclient). Никакие агенты доставки также не заданы.

Ниже показан файл конфигурации главного компьютера. Компания XOR предоставляет услуги Web-хостинга и обслуживает много виртуальных доменов. В первом примере компьютер студента управлял тремя виртуальными доменами при помощи протокола LDAP и средства genericstable. Компания XOR управляет почти тысячью виртуальных доменов, пользуясь средством virtusertable. А средство genericstable в данном случае применяется для преобразования в исходящей почте регистрационных имен в форму имя.фамилия. Псевдонимы задаются в стандартном файле aliases, который состоит их 3000 строк и содержит много списков рассылки. Некоторые из этих списков включают несколько тысяч получателей, а один — более 100000. И все это ведется в старой системе SunOS.

Файл псевдонимов следует упорядочить и отделить псевдонимы клиентов от псевдонимов служащих компании. Псевдонимы служащих указывают на IMAP-сервер, а клиенты применяют протокол IMAP для доступа к своей почте.

Обратите внимание на то, что в начале файла отсутствуют директивы divert. Они необходимы, только если в начале файла стоят комментарии в стиле интерпретатора команд (начинаются с символа '#').

На сервере работает программа sendmail версии 8.9.3 и применяются некоторые старые (до версии 8.10) конструкции. Высокий уровень загруженности потребовал увеличить стандартные значения некоторых опций, связанных с производительностью.

 

VERSIONID(‘@(#)xor.mc3.0   (trent)  3/29/99’)

OSTYPE(‘sunos4.1’)

define ('confPRIVACY_FLAGS',   ‘noexpn,novrfу')

define ("confMESSAGE_TIMEOUT’,   ‘5d/72h’)

define ("LOCAL_MAILER_PATH’,   '/usr/bin/mail.local')

dnl ##### увеличиваем значения опций, связанных с производительностью

define("confMCI_CACHE_SIZE',  ‘16')

define (' confMCI_CACHE_TIMEOUT', ‘10m')

define ('confCHECK_ALIASES',   'False')

define ('confDOMAIN_NAME',   ‘xor.com')

define ('confMAX_MESSAGE_SIZE',   '5000000')

define ('confDAEMON_OPTIONS',   ‘Port=NNN')

define (‘confQUEUE_LA',  25)

define ("confREFUSE LA',  30)

 

FEATURE(always_add_domain)

FEATURE(use_cw_file)

FEATURE(virtusertable)

GENERICS_DOMAINC(‘xor.com')

FEATURE(genericstable)

FEATURE(‘masquerade_envelope')

FEATURE(‘redirect')

FEATURE(‘access_db',   'hash -o /etc/mail/access')

MAILER(local)

MAILER(smtp)

LOCAL_RULESETS

###### Правила проверки спама и вирусов удалены; см. предыдущий раздел

 

 

Из этих примеров видно, что не существует единого рецепта по составлению конфигурационного файла. В программе sendmail имеется много конструкций, предназначенных для настройки маршрутизации и изменения заголовков сообщений. Поэтому конкретный выбор будет зависеть от личных предпочтений.



 (голосов: 0)
Версия для печати | Комментариев: 0
Информация
Посетители, находящиеся в группе Гости, не могут оставлять комментарии в данной новости.


 
Логин
Пароль
 

 
Locations of visitors to this page