Exim 7 Дефолтовый конфигурационный файл
Содержание
Дефолтовый конфигурационный файл
Дефолтовый конфигурационный файл, поставляемый с exim`ом как “src/configure.default”, достаточен для хоста, не имеющему особых требований к почтовой системе. В качестве вводной главы, в конфигурировании exim`а, этот раздел представляет собой “путь через значения по-умолчанию”, давая краткие пояснения параметров настройки. Детальные описания опций, даются в последующих главах. Дефолтовый конфигурационный файл содержит много комментариев о том, как изменить умолчальные значения. Однако, необходимо отметить, что имеется множество опций, которые вообще не упомянуты в дефолтовой конфигурации.
Главные конфигурационные настройки
Главные (глобальные) конфигурационные опции должны быть в начале файла. Первое, что необходимо установить, после вводных комментариев, это строка:
# primary_hostname =
Это - закомментированная установка опции “primary_hostname”. Exim должен знать официальное, полное имя вашего хоста, и тут можно его задать. Однако, в большинстве случаев, вам не нужно устанавливать эту опцию. Когда она не задана, exim использует системную функцию “uname()”, для получения имени хоста.
Первые три раскомментированные линии таковы:
domainlist local_domains = @ domainlist relay_to_domains = hostlist relay_from_hosts = 127.0.0.1
Фактически, они не параметры настройки. Это определения двух именованных списков доменов, и одного именованого списка хостов. Exim позволяет давать имена спискам доменов, хостов и e-mail адресов для облегчения управления конфигурационным файлом (смотрите секцию 10.5).
Первая строка задаёт список доменов, называемый “local_domains”; он используется позже, в конфигурации, для определения доменов которые нужно доставлять на локальный хост.
Tут, в этом списке, только одно значение, строка “@”. Это специальная форма, вхождение которой означает имя локального хоста. Таким образом, если локалхост называется “a.host.example”, то почта к любому пользователю типа “any.user@a.host.example” будет доставляться локально. Поскольку на имя локалхоста ссылаются косвенно, то можно использовать одинаковый конфиг на разных хостах.
Вторая строка задаёт список доменов, называемый “relay_to_domains”, но список пуст. Позже, в конфигурации, будет часть контролирующая релеинг почты через локальный хост; он позволяет релеить любые домены из этого списка. По дефолту, здесь, не разрешён релей на основе имён почтовых доменов.
Третья строка задаёт список хостов, называемый “relay_from_hosts”. Этот список используется позже, в конфигурации, для разрешения релея от любых хостов или IP-адресов, которые совпадают со списком. По-умолчанию, в нём содержится только IP-адрес интерфейса обратной петли, что означает, что процессы на локальном хосте могут пересылать почту к другим хостам через exim, соединяясь с ним по TCP/IP на интерфейсе обратной петли.
Для того, чтобы не было непонимания: В этом пункте конфигурации мы не устанавливаем никаких значений директив. Мы просто задаём некоторые домены и хосты, использующиеся в директивах заданных позже.
Следующие две строки - настоящие опции настройки:
acl_smtp_rcpt = acl_check_rcpt acl_smtp_data = acl_check_data
Эти опции задают “Access Control Lists” (списки контроля доступа - ACLs), которые используются в течение входящего SMTP-подключения для каждого получателя сообщения (на каждую команду RCPT), и после того, как сообщение было получено, соотвественно.Названия списков - “acl_check_rcpt” и “acl_check_data”, и мы доберёмся до их определения ниже, в конфигурационной секции ACL. RCPT ACL контролирует, какие получатели разрешены для входящих сообщений - если конфигурация не содержит ACL для проверки получателей, то никакая почта по SMTP не принимается. DATA ACL разрешает проверку содержимого сообщения.
Следующие две закомментированные строки:
# av_scanner = clamd:/tmp/clamd # spamd_address = 127.0.0.1 783
Они - пример настроек, которые могут использоваться когда exim скомпилен с расширением контентного сканирования (content-scanning extension). Первая задаёт интерфейс к сканеру вирусов, и вторая задаёт интерфейс к SpamAssassin. Дальнейшие детали даются в разделе 40.
Далее ещё две закомментированных строки:
# qualify_domain = # qualify_recipient =
Первая из них задаёт домен, который exim использует, при создании полного адреса электронной почты, из имени логина локального пользователя. Часто это необходимо при получении exim`ом почты от локального процесса. Если вы не задали “qualify_domain”, то используется значение “primary_hostname”. Если вы задали обе эти опции, то можно иметь разные домены для адресов получателей и отправителей. Если же используете только первую, то её значение используется для обоих директив.
Следующая строка может быть раскомментирована, если вы хотите чтобы exim понимал адреса формы “user@[10.11.12.13]”, то есть с “буквальным доменом” (“domain literal” - IP-адрес в квадратных скобках) вместо именованного домена.
# allow_domain_literals
RFC всё ещё требуют эту форму, но много людей считают что в современном интернете посылка почты определённым хостам, указывая их IP-адрес имеет мало смысла. Этот старый формат использовался людьми рассылающими спам. Однако, некоторые полагают, что есть обстоятельства (например письма постмастеру), когда этот формат полезен.
Следующая строка конфигурации, своего рода защита:
never_users = root
Это определяет, что никакая доставка не должна осуществляться от имени пользователя “root”. Нормальное соглашение заключалось в том, что “root” - псевдоним системного администратора. Зта опция - охранная. Список пользователей, определённых как “never_users” - неполный, при компиляции в “Local/Makefile” есть опция “FIXED_NEVER_USERS”, задающая список, который не может быть отменён. Содержимое “never_users” добавляется к списку. По-умолчанию, “FIXED_NEVER_USERS” содержит пользователя “root”.
Когда удалённый хост коннектится к exim`y, чтобы послать почту, единственная информация, которую имеет exim, о идентификации хоста - это его IP-адрес. Следующая конфигурационная строка,
host_lookup = *
задаёт, что exim должен проводить обратный поиск в DNS для всех входящих соединений, чтобы получить имя хоста. Это улучшает качество логов, но если вы чувствуете, что это обходиться слишком дорого, то вы можете удалить этот пункт вообще, или ограничить поиск хостами в соседних сетях. Отметьте, что не всегда можно найти имя хоста по его IP-адресу, поскольку не все обратные DNS-зоны обслуживаются, и некоторые DNS-сервера могут быть недоступны.
Следующие две строки занимаются вызовом “ident”, как определено в RFC 1413, следовательно их имена:
rfc1413_hosts = * rfc1413_query_timeout = 5s
Эти настройки заставляют exim делать вызовы “ident” для всех входящих SMTP подключений. Вы можете ограничить список хостов, на которые делается этот вызов, или изменить таймаут, если он используется. Можно поставить таймаут в ноль, тогда все вызовы “ident” будут заблокированы. Хотя они обходятся дёшево, и могут дать полезную информацию для трассировки проблем сообщений, некоторые хосты и фаерволлы имеют проблемы с запросами “ident”. Это может привести к таймауту вместо немедленного сброса подключения, в случае отказа, приводя к задержке на старте входящего SMTP подключения.
Когда exim получает сообщения по SMTP, то ожидается, что все хосты будут иметь полное доменное имя, как требуется по определению SNMP. Однако если на ваш сервер шлют сообщения простые пользователи, то они могут иметь неподходящие адреса. Две закомментированные опции:
# sender_unqualified_hosts = # recipient_unqualified_hosts =
указывают как вы можете задать хосты, которым разрешается посылать неполные адреса отправителей и получателей (имеются ввиду адреса без домена - тока имя пользователя).
Опция “percent_hack_domains” также закомментирована:
# percent_hack_domains =
Она обеспечивает список доменов, для которых должно работать “percent hack”. Это - почти устаревшая опция явной почтовой маршрутизации. Если вы ничего не знаете об этом - то также можете проигнорировать эту опцию. (Прим. переводчика: а вообще имеются ввиду адреса, типа user%domain1.su@domain2.su - когда письмо приходит на сервер domain2.su, а тот уже пересылает его на domain1.su. Но лучше это не использовать.)
Два последних параметра настройки дефолтовой конфигурации касаются сообщений, “замороженных” в очереди exim`a. Когда сообщение заморожено, exim не продолжает попытки доставить его. Замораживание происходит когда сообщение об отлупе сталкивается с постоянным отказом, поскольку отправитель оригинального сообщения, вызвавшего рикошет, недопустим, и таким образом отлуп нельзя доставить. Это - наиболее частая причина, но есть и другие причины заморозки, и замороженные сообщения - не всегда рикошеты.
ignore_bounce_errors_after = 2d timeout_frozen_after = 7d
Первая из этих опций определяет, что рикошеты будут выброшены из очереди через два дня. Вторая задаёт что любое замороженное сообщение (рикошет или другое) будет выброшено из очереди через неделю. При таких настройках, гарантируется, что попытки доставки рикошета никогда не будут длиться неделю (потому как через два дня их выкинут :)))).
Конфигурация ACL
В дефолтовой конфигурации, секция ACL следует за главной конфигурацией. Она начинается со строки
begin acl
и она содержит определения двух ACL, называемых “acl_check_rcpt” и “acl_check_data” на которые выше ссылались параметры настройки “acl_smtp_rcpt” и “acl_smtp_data”.
Первая ACL, используется для всех команд RCPT для входящих SMTP сообщений. Каждая команда RCPT определяет одного получателя сообщения. Утверждения ACL рассматриваются до тех пор, пока адрес либо принимается либо отклоняется. Тогда команда RCPT либо принята, либо отклонена, согласно результату обработки ACL.
acl_check_rcpt:
Эта строка, состоящая из названия завершённого двоеточием, отмечает начало ACL и именует её.
accept hosts = :
Это утверждение ACL принимает получателя, если хост соответствует списку. Но что означает этот странный список? Он, фактически, не содержит никаких имён хостов, или адресов IP. Присутствие двоеточия, помещает в пустой элемент в список; exim сопоставляет его только с входящими сообщениями, которые идут не с удалённого хоста (только с локалхоста), поскольку в этом случае, имя удалённого хоста пустой. Двоеточие важно. Без него список пуст, и никогда ничему не соответствует.
То, что делает это утверждение, - разрешает безоговорочный приём всех получателей в сообщениях переданных по SMTP от локальных процессов, с использованием стандартного ввода и вывода (т.е. без использования TCP/IP). Множество MUA работает в такой манере.
deny message = Restricted characters in address
domains = +local_domains
local_parts = ^[.] : ^.*[@%!/|]
deny message = Restricted characters in address
domains = !+local_domains
local_parts = ^[./|] : ^.*[@%!] : ^.*/\\.\\./
Это утверждение занимается тем, чтобы локальная часть адреса не содержали некоторые символы - “@”, “%”, “!”, “/”, “|”, или точки в необычных местах. Хотя эти символы могут абсолютно законно использоваться в локальной части адреса (в случае “@” и начальной точки, только если корректно заэкранировано), обычно они не встречаются в почтовых адресах.
Первые три имеют прошлые ассоциации с явным роутингом адресов (символ процента используется до сих пор - смотрите опцию “percent_hack_domains”). Адреса содержащие эти символы регулярно пробуют спамеры, в попытках обойти ограничения релея почты, и программами проверяющими хост на открытый релей. Если вы в них не нуждаетесь, то самое безопасное - отклонить их на ранней стадии. Эта конфигурация отклоняет эти символы для всех удалённых хостов. Это преднамеренная политика, для достижения, насколько возможно, максимальной безопасности.
Первое правило более строгое, и оно применяется к сообщениям, которые адресованы к одному из локальных доменов, которые крутятся на этом хосте. Это осуществляется первым условием, которое ограничивает его доменами перечисленными в списке “local_domains”. Символ “+” используется для указания ссылки на именованный список. В данной конфигурации, тут только один домен в “local_domains”, но вообще, может быть несколько.
Второе условие в первом утверждение использует два регулярных выражения, для блокирования локальных частей начинающихся с точки, или содержащих “@”, “%”, “!”, “/”, или “|”. Если у вас есть учётки использующие эти символы, то надо изменить это правило.
Пустые компоненты (две точки подряд) недопустимы по RFC 2822, но exim разрешает их, поскольку с ними столкнулись практически. (Обычно локальная часть выглядит так: “first-initial.second-initial.family-name”, но иногда бывает, что второго инициала нет, как у автора exim) Однако, локальная часть начинающаяся с точки, или содержащая “/../” может вызывать проблемы, если она используется как часть имени (например в списке рассылки). Также это истинно для локальных частей содержащих слэши. Символ трубы “|” также может принести неприятности, если локальная часть легкомысленно включена в командную строку шелла.
Второе правило, применяемое ко всем прочим доменам менее строго. Это позволяет локальным пользователям посылать сообщения к другим серверам, использующим слэши и трубы в локальной части адреса. Оно блокирует локальные части начинающиеся с точки, слэша, или трубы, но разрешает эти символы внутри локальной части. Однако, последовательность “/../” - запрещена. Использование “@”, “%”, и “!” заблокировано. Мотивация - запретить пользователям (или пользовательским вирусам) от определённые виды атак на удалённые сервера.
accept local_parts = postmaster
domains = +local_domains
Это утверждение, имеющее два условия, разрешает входящий адрес если локальная часть “postmaster” и домен - один из перечисленных в списке “local_domains”. Символ “+” используется для указания ссылки на именованный список. В данной конфигурации, тут только один домен в “local_domains”, но вообще, может быть несколько.
Присутствие этого условия означает, что почта предназначенная постмастеру не блокируется последующими проверками. Это может быть полезным, при разборе проблем в последующих проверках, где неверно запрещается доступ.
require verify = sender
Это утверждение требует, чтобы адрес отправителя был проверен до того, как будут последующие проверки ACL. Если проверка неудачна, то отказывается в доставке входящему адресу получателя. Проверка состоит из попытки маршрутизировать адрес, с целью выяснить, можно ли по нему доставить сообщение о рикошете. В случае удалённых адресов, проверяется только домен, но для более точной проверки может использоваться “callouts”. Смотрите раздел 39.31 для получения дополнительной информации о проверке адреса.
accept hosts = +relay_from_hosts
control = submission
Это утверждение принимает адрес, если сообщение приходит с одного из хостов которым разрешён релей через этот хост. Проверка получателя тут опущена, поскольку во многих случаях клиенты - тупые MUA которые не в состоянии справиться ответами об ошибке SMTP. По этой же причине, вторая строка задаёт “режим подчинения” (“submission mode”) для принятых сообщений. Это детально описано в разделе 43.1; это заставляет exim`a исправлять сообщения которые недоделаны (неполные или несовершенные), например, потому что у них отсутствует строка заголовка “Date:”. Если вы передаёте их наружу, с MTA, вы, вероятно, должны тут добавить проверку получателя, и отключить режим подчинения.
accept authenticated = *
control = submission
Это утверждение принимает адрес, если клиентский хост подтвердил свою подлинность. Снова задан режим подчинения, поскольку сообщения, вероятнее всего, будут прибывать с MUA. В умолчальном конфиге не заданы аутентификаторы, что означает, что никакой клиент не сможет подтвердить свою подлинность. Вам необходимо добавить определения аутентификаторов если вы хотите использовать это утверждение ACL.
# deny message = rejected because $sender_host_address \ # is in a black list at $dnslist_domain\n\ # $dnslist_text # dnslists = black.list.example # # warn message = X-Warning: $sender_host_address is \ # in a black list at $dnslist_domain # log_message = found in $dnslist_domain # dnslists = black.list.example
Эти закомментированные строки - пример того как вы можете сконфигурировать exim для проверки отправляющего хоста в блэк-листах DNS. Первое утверждение отклоняет сообщения с хостов находящихся в чёрных списках, тогда как второе только добавляет строку заголовка с предупреждением.
accept domains = +local_domains
endpass
verify = recipient
Это утверждение принимает входящий адрес, если домен - один из локальных доменов, но тока если подтверждён адрес. Проверка локальных адресов, обычно, заключается в проверке локальной и доменной частей. Строка “endpass” нуждается в некотором пояснении: если условие выше “endpass” неудачно, т.е. в данном случае, получатель не в локальном домене, управление передаётся следующей ACL. Однако, если условие ниже “endpass” неудачно, т.е. если получатель в локальном домене не может быть подтверждён, то доступ запрещается и получатель отклоняется.
accept domains = +relay_to_domains
endpass
verify = recipient
Это утверждение принимает входящий адрес, если домен - один из доменов для которых этот хост является релеем, но снова, тока если адрес может быть проверен.
deny message = relay not permitted
Заключительное утверждение, запрещает доступ, выдавая специфическое сообщение об ошибке. Достижение конца ACL также запрещает доступ, но с общим сообщением “administrative prohibition”.
acl_check_data:
Эта строка отмечает начало второго ACL, и именует его. Большая часть содержимого этого ACL закомментирована:
# deny malware = * # message = This message contains a virus \ # ($malware_name).
Эти строки - пример того, как сделать чтобы сообщения были просканированы на вирусы, когда exim скомпилен с поддержкой контентного сканирования, и установлен подходящий сканнер вирусов. Если в сообщении найден вирус, то оно отклоняется с заданным сообщением об ошибке.
# warn spam = nobody # message = X-Spam_score: $spam_score\n\ # X-Spam_score_int: $spam_score_int\n\ # X-Spam_bar: $spam_bar\n\ # X-Spam_report: $spam_report
Эти строки - пример того, как сделать, чтобы сообщения были просканированы SpamAssassin, когда exim скомпилен с поддержкой контентного сканирования, и установлен SpamAssassin. Проверка SpamAssassin`ом выполняется от пользователя nobody, и результаты добавляются к сообщению как ряд дополнительных заголовков. В этом случае, сообщение не отклоняется, вне зависимости от того сколько очков ему поставлено.
accept
Это заключительная строка в DATA ACL, сообщение принимается безоговорочно.
Конфигурация роутера (маршрутизатора)
Конфигурация роутеров в дефолтовом конфиге, начинается со следующей линии:
begin routers
Роутеры - это модули в exim`e, принимающие решение о том, куда слать сообщение. Адрес передаётся каждому маршрутизатору, по очереди, и он его либо принимает, либо нет. Это значит, что порядок в котором заданы роутеры - важен. Каждый роутер, позднее, полностью описан в его разделе, в этом руководстве. Тут даны только краткие обзоры.
# domain_literal: # driver = ipliteral # domains = !+local_domains # transport = remote_smtp
Этот маршрутизатор закомментирован, поскольку большинство серверов не поддерживает буквальные адреса (вида “user@[10.9.8.7]”). Если вы раскомментируете этот роутер, также необходимо будет раскомментить опцию “allow_domain_literals” в основной части конфигурации.
dnslookup: driver = dnslookup domains = ! +local_domains transport = remote_smtp ignore_target_hosts = 0.0.0.0 : 127.0.0.0/8 no_more
Первый незакомментированный роутер обрабатывает адреса, не относящиеся к локальным доменом. Это задано строкой
domains = ! +local_domains
Опция “domains” - список доменов к которым применяется этот роутер, но восклицательный знак является признаком отрицания (несоответствия), таким образом роутер используется только для доменов, которые не находятся в списке “local_domains” (который был определён в начале конфигурации). Символ “+” используется для указания ссылки на именованный список. Адреса в других доменах передаются следующим роутерам.
Имя драйвера маршрутизатора - “dnslookup”, оно задано в опции “driver”. Вас не должно смущать то, что имя маршрутизатора такое же как и имя драйвера. Название примера может быть произвольным, но имя заданное в опции “driver” - должен быть один из модулей драйверов из исполняемого файла exim`a.
Роутер “dnslookup” маршрутизирует адреса, ища их домены в DNS, для получения списка хостов к которым к которым должен маршрутизироваться адрес. Если роутер успешен, адрес ставиться в очередь транспорта “remote_smtp”, как задано в опции “transport”. Если роутер не находит домен в DNS, то никакие дальнейшие роутеры не рассматриваются из-за опции “no_more”, таким образом адрес неудачен, и не доставляется (возвращается сообщение о ошибке).
Опция “ignore_target_hosts” задаёт список IP-АДРЕСОВ, которые должны полностью игнорироваться. Эта опция присутствует по причине, что было много случаев, когда MX-запись в DNS указывает на имя хоста с адресом 0.0.0.0 или из 127-й подсети (обычно, 127.0.0.1). Полное игнорирование этих адресов лишает возможности exim маршрутизировать почту к ним, таким образом доставка срывается. Иначе, exim писал бы в логи о проблеме маршрутизации, и продолжал пытаться доставить сообщение, с определённым таймаутом.
system_aliases:
driver = redirect
allow_fail
allow_defer
data = ${lookup{$local_part}lsearch{/etc/aliases}}
# user = exim
file_transport = address_file
pipe_transport = address_pipe
Управление передаётся этому и последующим роутерам, только если адрес в локальном домене. Этот роутер проверяет, заданa ли локальная часть как альяс в “/etc/aliases”, и если это так, переадресовывает адрес согласно данным найденным в этом файле. Если для локальной части не найдено никаких данных, то значение опции “data” пустое, и адрес передаётся следующему роутеру.
“/etc/aliases” - обычно это файл системных альясов. Именно по этому на него, по-умолчанию, ссылается конфигурационный файл. Однако, это можно поменять, изменив опцию “SYSTEM_ALIASES_FILE” в “Local/Makefile” до сборки exim`a.
userforward: driver = redirect check_local_user # local_part_suffix = +* : -* # local_part_suffix_optional file = $home/.forward # allow_filter no_verify no_expn check_ancestor file_transport = address_file pipe_transport = address_pipe reply_transport = address_reply
Этот маршрутизатор - самый сложный в дефолтовой конфигурации. Это другой перенаправляющий роутер, но он ищет данные перенаправления установленные отдельными пользователями. Установка “check_local_user” задаёт проверку локальной части, что она логин локального пользователя. Если это не так - роутер пропускается. За опцией “check_local_user” следуют две закомментированные опции, а именно:
# local_part_suffix = +* : -* # local_part_suffix_optional
указывают, как можно задать распознание локальной части суффиксов. Если раскомментировать первое, то суффикс начинающийся с плюса или минуса, за которым идёт какая-то последовательность символов, удаляется из локальной части и помещается в переменную “$local_part_suffix”. Вторая опция суффикса определяет, что присутствие суффикса в локальной части является опциональны. Когда суффикс есть, проверка локального логина пользователя использует локальную часть без суффикса.
Когда найден локальный аккаунт пользователя, то просматривается файл “.forward” в домашней директории пользователя. Если он не существует, или пуст, то роутер пропускается. Иначе, содержимое “.forward” интерпретируется как данные перенаправления (для дополнительных деталей, обратитесь к главе 22).
Традиционный файл “.forward” содержит лишь список адресов, каналов (труб), или файлов. Exim поддерживает всё это по-умолчанию. Однако, если установлена опция “allow_filter” (по дефолту, она закомментирована), содержимое файла интерпретируется инструкции exim`a или sieve, если файл начинается с “#Exim filter” или “#Sieve filter”, соответственно. Фильтры пользователей обсуждаются в отдельном документе “Exim’s interfaces to mail filtering”.
Опции “no_verify” и “no_expn” означают что этот роутер пропущен, когда проверяется адрес, или когда он выполняется вследствие команды SMTP EXPN. Есть две причины, чтобы это сделать:
- 1. В действительности, не очень важно, есть у пользователя файл “.forward” или нет, при проверке адреса на существование; это делается сознательно, чтобы не тратить ресурсы на бесполезную работу.
- 2. Ещё более важно, когда exim проверяет адрес или обрабатывает команду EXPN во время SMTP сессии он работает от имени своего пользователя, а не от root. Группа - тоже его группа, и никаких дополнительных групп не установлено. Поэтому, вполне возможно, что exim не сможет прочитать пользовательский файл “.forward” в этот момент.
Установка “check_ancestor” препятствует роутеру генерить новый адрес, являющийся таким же как и предыдущий, который переадресуется. (Это связано с относительно плохим взаимодействием между альясингом и форвардингом - смотрите раздел 22.5)
Три финальных параметра настройки задают транспорты, которые должны использоваться когда форвардинг совершает прямую доставку в файл, или в трубу, или делает авто-ответ, соответственно. Например, если файл “.forward” содержит
a.nother@elsewhere.example, /home/spqr/archive
доставка в “/home/spqr/archive” будет осуществлена запуском транспорта “address_file”.
localuser: driver = accept check_local_user # local_part_suffix = +* : -* # local_part_suffix_optional transport = local_delivery
Последний роутер устанавливает доставку в локальные почтовые ящики, при условии, что локальная часть адреса является логином пользователя, принимая адрес и задавая его транспорту “local_delivery”. Иначе, т.к. достигнут конец роутеров, адрес возвращается отправителю. Закомментированные настройки суффиксов выполняют ту же самую роль, что и в роутере “userforward”.
Транспортная конфигурация
Транспорты задают механизмы для фактической доставки сообщений. Они работают только когда на них ссылаются роутеры, таким образом порядок в котором они заданы - неважен. Раздел транспортов начинается с
begin transports
Определены один удалённый и четыре локальных транспорта.
remote_smtp: driver = smtp
Этот транспорт используется для доставки сообщений через SMTP-соединение. Все его опции - умолчальные. Список удалённых хостов даётся маршрутизатором.
local_delivery: driver = appendfile file = /var/mail/$local_part delivery_date_add envelope_to_add return_path_add # group = mail # mode = 0660
Транспорт “appendfile” используется для локальной доставки в пользовательские почтовые ящики, в традиционном формате BSD mailbox. По дефолту, он запускается под uid и gid локального пользователя, что требует установки “липкого” (“sticky”) бита на директории “/var/mail”. Некоторые системы используют иной подход к запуску доставки почты, под специфической группой, вместо использования “липкого” бита. Закомментированные опции показывают, как это может быть сделано.
При доставке, exim добавляет к сообщению три заголовка: “Delivery-date:”, “Envelope-to:” и “Return-path:”. Это регулируется тремя опциями, с подобными названиями.
address_pipe: driver = pipe return_output
Этот транспорт используется для обработки доставки в каналы, генерируемых редиректом (альясингом, или пользовательским файлом “.forward”). Опция “return_output” определяет, что любой вывод сгенерированный каналом, должен быть возвращён отправителю.
address_file: driver = appendfile delivery_date_add envelope_to_add return_path_add
Это транспорт используется для обработки доставки в файлы, произведённым редиректом. Имя файла не задаётся в “appendfile”, поскольку оно приходит от маршрутизатора “redirect”.
address_reply: driver = autoreply
Этот транспорт используется для обработки автоматических ответов, сгенерённых пользовательскими фильтрами.
Дефолтовые правила повторов
Секция повторов конфигурационного файла, содержит правила затрагивающие поведение exim`a при повторах доставки сообщений, которые не удалось доставить с первого раза. Она начинается со строки
begin retry
В дефолтовой конфигурации, есть только одно правило, применяемое ко всем ошибкам:
* * F,2h,15m; G,16h,1h,1.5; F,4d,6h
Это заставляет exim пытаться доставить любой временно неудачный адрес в течение двух часов каждые 15 минут, затем интервал начинается с часа и увеличивается с фактором полтора пока не пройдёт 16 часов, затем каждые 6 часов, до срока в 4 дня. Если адрес не удаётся доставить после 4-х дней временного отказа, то происходит срыв адреса (письмо возвращается отправителю).
Конфигурация перезаписи
Раздел конфигурации перезаписи, начинаемый с
begin rewrite
содержит правила для перезаписи адресов в прибывших сообщениях. В дефолтовом конфиге нет правил перезаписи.
Конфигурация аутентификаторов
Секция аутентификаторов файла конфигурации, начинаемая с
begin authenticators
задаёт механизмы для использования в команде SMTP AUTH. В дефолтовом конфиге нет правил аутентификации.
