После этого будем считать, что PostgreSQL у нас работает. Однако для полного использования возможностей этой СУБД лучше почитать документацию.

Далее перейдем к настройке собственно MTA exim. Конфигурационный файл для версии «из портов» хранится в /usr/local/etc/exim/configure. Для начала я бы хотел пояснить значение некоторых терминов и рассказать о базовых принципах работы exim.

Представим себе путь прохождения любого почтового сообщения. Любое письмо состоит из так называемого конверта и собственно данных. То, с чем мы привыкли работать в почтовых клиентах, как раз является «данными» и не имеет к конверту никакого отношения. В конверте описываются 2 параметра: mail from: и rcpt to:, которые указывают отправителя и получателей соответственно. Сеанс работы с MTA может предваряться «приветствием» – стандартным (HELO) и расширенным (EHLO). В приветствии должно указываться FQDN клиента, хотя по ряду причин не стоит слишком строго следить за именно FQDN, т.к. многие машины могут находиться за NAT. MTA в ответ на HELO или EHLO сообщает о своих возможностях, обеспечивая тем самым синхронизацию клиента и сервера. Далее exim осуществляет проверку целевых адресов на предмет их допустимости для данного сервера. Этот этап может предваряться аутентификацией и установкой TLS-сессии. Если пользователь прошел какой-либо из этих этапов, ему присваиваются определенные флаги, которые в дальнейшем могут использоваться на этапе проверки конверта. По умолчанию exim осуществляет проверку недопустимых символов в адресах и позволяет отправлять почту только из локальных доменов и только на локальные домены. Кроме того, при успешной аутентификации письмо проходит и в Интернет. Для остальных писем релей (передача писем) запрещена. Все проверки в exim4 осуществляются на основании механизма acl (access control list – список доступа). Также может осуществляться проверка данных (этот механизм добавляется при установке патча exiscan, который при установке портов уже ставится). После успешного прохождения этого этапа exim просматривает rewrite-правила для переписывания отдельных частей конверта (может использоваться в целях перенаправления всех писем на какой-либо смарт-хост, например). Далее письмо попадает на цепочку так называемых роутеров, которые определяют, как именно доставлять письмо. Среди роутеров фигурирует dnslookup, доставляющий письма на основании MX-записей в DNS, проверка файла алиасов и .forward-файлов, ну и локальная доставка. Каждый роутер имеет некое условие срабатывания и соответствующий транспорт. При выполнении условия exim выбирает указанный транспорт для доставки письма, иначе письмо проходит на следующий роутер (поэтому важен порядок описания роутеров в конфигурационном файле). Транспорты же определяют порядок доставки письма. Таким образом, настройка exim состоит из нескольких частей:

n  настройка глобальных параметров;

n  настройка acl’s;

n  настройка роутеров;

n  настройка транспортов;

n  настройка аутентификаторов;

n  настройка очереди;

n  настройка rewrite-правил.

В настройке exim широко используются различные списки (hostlist, domainlist и dnslist) и так называемые lookup, при помощи которых exim извлекает данные из внешних источников.

Многие мои знакомые, пытаясь освоить exim, считали lookup самой запутанной темой, потому я остановлюсь на этом вопросе чуть подробнее. Существует два типа поиска: поиск по одному ключу (single-key) и поиск по запросу (query). Первый используется для поиска в локальных файлах, а второй – в различного рода базах (sql, ldap и прочее). Любые lookup могут быть вложенными, то есть в одном поиске используются результаты другого.

Поиск на основе single key строится примерно так:

${lookup{$var_to_search}lsearch{/path/to/file}}

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

$список -> ${lookup список} -> ${lookup {$var_to_search} driver{driver_arguments}}

При этом сам файл, в котором осуществляется поиск, должен выглядеть так:

$var_to_search: значение

Приведу более конкретный пример – построение списка доменов из файла на основании адреса отправителя (пример из документации):

domainlist domains = ${lookup{$sender_host_address} lsearch{/some/file}}

при этом сам файл должен выглядеть следующим образом:

192.168.3.4: domain1 : domain2 : ...

192.168.1.9: domain3 : domain4 : ...

При этом поиск осуществляется по первому полю. Отличие query-style-поиска в том, что мы явно не обозначаем, что искать, указывая вместо этого запрос. Так выглядит типичный запрос к SQL-базе:

${lookup driver{query}{action_if_query_succeed} {action_if_query_failed}}