Мы — долго запрягаем, быстро ездим, и сильно тормозим.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||
www.lissyara.su
—> документация
—> EXIM
|
|
Это - закомментированная установка опции
“primary_hostname
”. Exim должен знать официальное, полное имя вашего хоста, и тут можно его задать. Однако, в большинстве случаев, вам не нужно устанавливать эту опцию. Когда она не задана, exim использует системную функцию
“uname()
”, для получения имени хоста.
Первые три раскомментированные линии таковы:
|
Фактически, они не параметры настройки. Это определения двух именованных списков доменов, и одного именованого списка хостов. 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 на интерфейсе обратной петли.
Для того, чтобы не было непонимания: В этом пункте конфигурации мы не устанавливаем никаких значений директив. Мы просто задаём некоторые домены и хосты, использующиеся в директивах заданных позже.
Следующие две строки - настоящие опции настройки:
|
Эти опции задают
“Access Control Lists
” (списки контроля доступа - ACLs), которые используются в течение входящего SMTP-подключения для каждого получателя сообщения (на каждую команду RCPT), и после того, как сообщение было получено, соотвественно.Названия списков -
“acl_check_rcpt
” и
“acl_check_data
”, и мы доберёмся до их определения ниже, в конфигурационной секции ACL. RCPT ACL контролирует, какие получатели разрешены для входящих сообщений - если конфигурация не содержит ACL для проверки получателей, то никакая почта по SMTP не принимается. DATA ACL разрешает проверку содержимого сообщения.
Следующие две закомментированные строки:
|
Они - пример настроек, которые могут использоваться когда exim скомпилен с расширением контентного сканирования (content-scanning extension). Первая задаёт интерфейс к сканеру вирусов, и вторая задаёт интерфейс к SpamAssassin. Дальнейшие детали даются в разделе 41.
После них идут ещё 3 закомментированные строки:
|
Они являются примером настроек, которые могут использоваться, если Exim скомпилирован с поддержкой TLS (SSL), смотрите секцию 4.7. Первая опция задаёт список клиентов, которые при подключении к серверу могут использовать TLS,
“*
” в этом случае подразумевает любого клиента. Остальные опции служат для указания того, где Exim должен искать свой TLS сертификат и приватный ключ (private key), которые вместе однозначно идентифицируют сервер для всех клиентов. Вы можете найти дополнительную информацию в главе 39.
Дальше следуют две закомментированые опции:
|
Эти опции предоставляют улучшенную поддержку удалённым пользователям, которые желают использовать этот сервер для отправки почты. Они редко используются, если Вы не используете TLS (как его включать было описано в предыдущем параграфе) и аутентификацию (о которой говорится в секции 7.7). Очень часто стандартный SMTP порт (25-ый) заблокирован для пользователей из конечных сетей (end-user network), поэтому RFC 4409 позволяет использовать альтернативный, 587-ой порт для передачи почты. К сожалению некоторые приложения (особенно Microsoft Outlook) не могут быть настроены на использование 587-го порта, т.к. настройки выше также включают нестандартный 465 "smtps" ("ssmtp") порт (см. секцию 13.4).
Далее ещё две закомментированных строки:
|
Первая из них задаёт домен, который exim использует, при создании полного адреса электронной почты, из имени логина локального пользователя. Часто это необходимо при получении exim`ом почты от локального процесса. Если вы не задали
“qualify_domain
”, то используется значение
“primary_hostname
”. Если вы задали обе эти опции, то можно иметь разные домены для адресов получателей и отправителей. Если же используете только первую, то её значение используется для обоих директив.
“
Следующая строка может быть раскомментирована, если вы хотите чтобы exim понимал адреса формы user@[10.11.12.13]
”, то есть с
“буквальным доменом
” (
“domain literal
” - IP-адрес в квадратных скобках) вместо именованного домена.
|
RFC всё ещё требуют эту форму, но много людей считают что в современном интернете посылка почты определённым хостам, указывая их IP-адрес имеет мало смысла. Этот старый формат использовался людьми рассылающими спам. Однако, некоторые полагают, что есть обстоятельства (например письма постмастеру), когда этот формат полезен.
Следующая строка конфигурации, своего рода защита:
|
Это определяет, что никакая доставка не должна осуществляться от имени пользователя
“root
”. Нормальное соглашение заключалось в том, что
“root
” - псевдоним системного администратора. Зта опция - охранная. Список пользователей, определённых как
“never_users
” - неполный, при компиляции в
“Local/Makefile
” есть опция
“FIXED_NEVER_USERS
”, задающая список, который не может быть отменён. Содержимое
“never_users
” добавляется к списку. По-умолчанию,
“FIXED_NEVER_USERS
” содержит пользователя
“root
”.
Когда удалённый хост коннектится к exim`y, чтобы послать почту, единственная информация, которую имеет exim, о идентификации хоста - это его IP-адрес. Следующая конфигурационная строка,
|
задаёт, что exim должен проводить обратный поиск в DNS для всех входящих соединений, чтобы получить имя хоста. Это улучшает качество логов, но если вы чувствуете, что это обходиться слишком дорого, то вы можете удалить этот пункт вообще, или ограничить поиск хостами в соседних сетях. Отметьте, что не всегда можно найти имя хоста по его IP-адресу, поскольку не все обратные DNS-зоны обслуживаются, и некоторые DNS-сервера могут быть недоступны.
“
Следующие две строки занимаются вызовом ident
”, как определено в RFC1413, следовательно их имена:
|
Эти настройки заставляют exim делать вызовы
“ident
” для всех входящих SMTP подключений. Вы можете ограничить список хостов, на которые делается этот вызов, или изменить таймаут, если он используется. Можно поставить таймаут в ноль, тогда все вызовы
“ident
” будут заблокированы. Хотя они обходятся дёшево, и могут дать полезную информацию для трассировки проблем сообщений, некоторые хосты и фаерволлы имеют проблемы с запросами
“ident
”. Это может привести к таймауту вместо немедленного сброса подключения, в случае отказа, приводя к задержке на старте входящего SMTP подключения.
Когда exim получает сообщения по SMTP, то ожидается, что все хосты будут иметь полное доменное имя, как требуется по определению SNMP. Однако если на ваш сервер шлют сообщения простые пользователи, то они могут иметь неподходящие адреса. Две закомментированные опции:
|
указывают как вы можете задать хосты, которым разрешается посылать неполные адреса отправителей и получателей (имеются ввиду адреса без домена - тока имя пользователя).
“
Опция percent_hack_domains
” также закомментирована:
|
Она обеспечивает список доменов, для которых должно работать
“percent hack
”. Это - почти устаревшая опция явной почтовой маршрутизации. Если вы ничего не знаете об этом - то также можете проигнорировать эту опцию. (Прим. переводчика: а вообще имеются ввиду адреса, типа user%domain1.su@domain2.su - когда письмо приходит на сервер domain2.su, а тот уже пересылает его на domain1.su. Но лучше это не использовать.)
“
Два последних параметра настройки дефолтовой конфигурации касаются сообщений, замороженных
” в очереди exim`a. Когда сообщение заморожено, exim не продолжает попытки доставить его. Замораживание происходит когда сообщение об отлупе сталкивается с постоянным отказом, поскольку отправитель оригинального сообщения, вызвавшего рикошет, недопустим, и таким образом отлуп нельзя доставить. Это - наиболее частая причина, но есть и другие причины заморозки, и замороженные сообщения - не всегда рикошеты.
|
Первая из этих опций определяет, что рикошеты будут выброшены из очереди через два дня. Вторая задаёт что любое замороженное сообщение (рикошет или другое) будет выброшено из очереди через неделю. При таких настройках, гарантируется, что попытки доставки рикошета никогда не будут длиться неделю (потому как через два дня их выкинут :)))).
7.2 Конфигурация ACL
В дефолтовой конфигурации, секция ACL следует за главной конфигурацией. Она начинается со строки
|
и она содержит определения двух ACL, называемых
“acl_check_rcpt
” и
“acl_check_data
” на которые выше ссылались параметры настройки
“acl_smtp_rcpt
” и
“acl_smtp_data
”.
Первая ACL, используется для всех команд RCPT для входящих SMTP сообщений. Каждая команда RCPT определяет одного получателя сообщения. Утверждения ACL рассматриваются до тех пор, пока адрес либо принимается либо отклоняется. Тогда команда RCPT либо принята, либо отклонена, согласно результату обработки ACL.
|
Эта строка, состоящая из названия завершённого двоеточием, отмечает начало ACL и именует её.
|
Это утверждение ACL принимает получателя, если хост соответствует списку. Но что означает этот странный список? Он, фактически, не содержит никаких имён хостов, или адресов IP. Присутствие двоеточия, помещает в пустой элемент в список; exim сопоставляет его только с входящими сообщениями, которые идут не с удалённого хоста (только с локалхоста), поскольку в этом случае, имя удалённого хоста пустой. Двоеточие важно. Без него список пуст, и никогда ничему не соответствует.
То, что делает это утверждение, - разрешает безоговорочный приём всех получателей в сообщениях переданных по SMTP от локальных процессов, с использованием стандартного ввода и вывода (т.е. без использования TCP/IP). Множество MUA работает в такой манере.
|
Это утверждение занимается тем, чтобы локальная часть адреса не содержали некоторые символы -
“@
”,
“%
”,
“!
”,
“/
”,
“|
”, или точки в необычных местах. Хотя эти символы могут абсолютно законно использоваться в локальной части адреса (в случае
“@
” и начальной точки, только если корректно заэкранировано), обычно они не встречаются в почтовых адресах.
“
Первые три имеют прошлые ассоциации с явным роутингом адресов (символ процента используется до сих пор - смотрите опцию percent_hack_domains
”). Адреса содержащие эти символы регулярно пробуют спамеры, в попытках обойти ограничения релея почты, и программами проверяющими хост на открытый релей. Если вы в них не нуждаетесь, то самое безопасное - отклонить их на ранней стадии. Эта конфигурация отклоняет эти символы для всех удалённых хостов. Это преднамеренная политика, для достижения, насколько возможно, максимальной безопасности.
“
Первое правило более строгое, и оно применяется к сообщениям, которые адресованы к одному из локальных доменов, которые крутятся на этом хосте. Это осуществляется первым условием, которое ограничивает его доменами перечисленными в списке local_domains
”. Символ
“+
” используется для указания ссылки на именованный список. В данной конфигурации, тут только один домен в
“local_domains
”, но вообще, может быть несколько.
“
Второе условие в первом утверждение использует два регулярных выражения, для блокирования локальных частей начинающихся с точки, или содержащих @
”,
“%
”,
“!
”,
“/
”, или
“|
”. Если у вас есть учётки использующие эти символы, то надо изменить это правило.
“
Пустые компоненты (две точки подряд) недопустимы по RFC2822, но exim разрешает их, поскольку с ними столкнулись практически. (Обычно локальная часть выглядит так: first-initial.second-initial.family-name
”, но иногда бывает, что второго инициала нет, как у автора exim) Однако, локальная часть начинающаяся с точки, или содержащая
“/../
” может вызывать проблемы, если она используется как часть имени (например в списке рассылки). Также это истинно для локальных частей содержащих слэши. Символ трубы
“|
” также может принести неприятности, если локальная часть легкомысленно включена в командную строку шелла.
“
Второе правило, применяемое ко всем прочим доменам менее строго. Это позволяет локальным пользователям посылать сообщения к другим серверам, использующим слэши и трубы в локальной части адреса. Оно блокирует локальные части начинающиеся с точки, слэша, или трубы, но разрешает эти символы внутри локальной части. Однако, последовательность /../
” - запрещена. Использование
“@
”,
“%
”, и
“!
” заблокировано. Мотивация - запретить пользователям (или пользовательским вирусам) от определённые виды атак на удалённые сервера.
|
Это утверждение, имеющее два условия, разрешает входящий адрес если локальная часть
“postmaster
” и домен - один из перечисленных в списке
“local_domains
”. Символ
“+
” используется для указания ссылки на именованный список. В данной конфигурации, тут только один домен в
“local_domains
”, но вообще, может быть несколько.
Присутствие этого условия означает, что почта предназначенная постмастеру не блокируется последующими проверками. Это может быть полезным, при разборе проблем в последующих проверках, где неверно запрещается доступ.
|
Это утверждение требует, чтобы адрес отправителя был проверен до того, как будут последующие проверки ACL. Если проверка неудачна, то отказывается в доставке входящему адресу получателя. Проверка состоит из попытки маршрутизировать адрес, с целью выяснить, можно ли по нему доставить сообщение о рикошете. В случае удалённых адресов, проверяется только домен, но для более точной проверки может использоваться
“callouts
”. Смотрите раздел 40.40 для получения дополнительной информации о проверке адреса.
|
Это утверждение принимает адрес, если сообщение приходит с одного из хостов которым разрешён релей через этот хост. Проверка получателя тут опущена, поскольку во многих случаях клиенты - тупые MUA которые не в состоянии справиться ответами об ошибке SMTP. По этой же причине, вторая строка задаёт
“режим подчинения
” (
“submission mode
”) для принятых сообщений. Это детально описано в разделе 44.1; это заставляет exim`a исправлять сообщения которые недоделаны (неполные или несовершенные), например, потому что у них отсутствует строка заголовка
“Date:
”. Если вы передаёте их наружу, с MTA, вы, вероятно, должны тут добавить проверку получателя, и отключить режим подчинения.
|
Это утверждение принимает адрес, если клиентский хост подтвердил свою подлинность. Снова задан режим подчинения, поскольку сообщения, вероятнее всего, будут прибывать с MUA. В умолчальном конфиге не заданы аутентификаторы, хотя, он включает в себя закомемнтированные примеры описанные в 7.7. Это означает, что, фактически, клиенты не могут аутентифицировать, пока вы не завершите определение айтентификаторов.
|
Это утверждение отклоняет адреса, если их домен не является локальным или одним из доменов для которых этот хост является релеем.
|
Это утверждение требует проверки адреса отправителя; если проверка неуспешна, адрес отклоняется.
|
Эти закомментированные строки - пример того как вы можете сконфигурировать exim для проверки отправляющего хоста в блэк-листах DNS. Первое утверждение отклоняет сообщения с хостов находящихся в чёрных списках, тогда как второе только добавляет строку заголовка с предупреждением.
|
Эта закомментированная строка - пример того, как вы можете включить проверку клиентской SMTP авторизации (CSA).
|
Финальное утверждение в первой ACL безоговорочно принимает любых отправителей, которые успешно прошли предыдущие тесты.
|
Эта строка отмечает начало второго ACL, и именует его. Большая часть содержимого этого ACL закомментирована:
|
Эти строки - пример того, как сделать чтобы сообщения были просканированы на вирусы, когда exim скомпилен с поддержкой контентного сканирования, и установлен подходящий сканнер вирусов. Если в сообщении найден вирус, то оно отклоняется с заданным сообщением об ошибке.
|
Эти строки - пример того, как сделать, чтобы сообщения были просканированы SpamAssassin, когда exim скомпилен с поддержкой контентного сканирования, и установлен SpamAssassin. Проверка SpamAssassin`ом выполняется от пользователя nobody, и результаты добавляются к сообщению как ряд дополнительных заголовков. В этом случае, сообщение не отклоняется, вне зависимости от того сколько очков ему поставлено.
|
Это заключительная строка в DATA ACL, сообщение принимается безоговорочно.
7.3 Конфигурация роутера (маршрутизатора)
Конфигурация роутеров в дефолтовом конфиге, начинается со следующей линии:
|
Роутеры - это модули в exim`e, принимающие решение о том, куда слать сообщение. Адрес передаётся каждому маршрутизатору, по очереди, и он его либо принимает, либо нет. Это значит, что порядок в котором заданы роутеры - важен. Каждый роутер, позднее, полностью описан в его разделе, в этом руководстве. Тут даны только краткие обзоры.
|
Этот маршрутизатор закомментирован, поскольку большинство серверов не поддерживает буквальные адреса (вида
“user@[10.9.8.7]
”). Если вы раскомментируете этот роутер, также необходимо будет раскомментить опцию
“allow_domain_literals
” в основной части конфигурации.
|
Первый незакомментированный роутер обрабатывает адреса, не относящиеся к локальным доменом. Это задано строкой
|
Опция
“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 писал бы в логи о проблеме маршрутизации, и продолжал пытаться доставить сообщение, с определённым таймаутом.
|
Управление передаётся этому и последующим роутерам, только если адрес в локальном домене. Этот роутер проверяет, заданa ли локальная часть как альяс в
“/etc/aliases
”, и если это так, переадресовывает адрес согласно данным найденным в этом файле. Если для локальной части не найдено никаких данных, то значение опции
“data
” пустое, и адрес передаётся следующему роутеру.
“
/etc/aliases
” - обычно это файл системных альясов. Именно по этому на него, по-умолчанию, ссылается конфигурационный файл. Однако, это можно поменять, изменив опцию
“SYSTEM_ALIASES_FILE
” в
“Local/Makefile
” до сборки exim`a.
|
Этот маршрутизатор - самый сложный в дефолтовой конфигурации. Это другой перенаправляющий роутер, но он ищет данные перенаправления установленные отдельными пользователями. Установка
“check_local_user
” задаёт проверку локальной части, что она логин локального пользователя. Если это не так - роутер пропускается. За опцией
“check_local_user
” следуют две закомментированные опции, а именно:
|
указывают, как можно задать распознание локальной части суффиксов. Если раскомментировать первое, то суффикс начинающийся с плюса или минуса, за которым идёт какая-то последовательность символов, удаляется из локальной части и помещается в переменную
“$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
” содержит
|
доставка в
“/home/spqr/archive
” будет осуществлена запуском транспорта
“address_file
”.
|
Последний роутер устанавливает доставку в локальные почтовые ящики, при условии, что локальная часть адреса является логином пользователя, принимая адрес и задавая его транспорту
“local_delivery
”. Иначе, т.к. достигнут конец роутеров, адрес возвращается отправителю. Закомментированные настройки суффиксов выполняют ту же самую роль, что и в роутере
“userforward
”.
7.4 Транспортная конфигурация
Транспорты задают механизмы для фактической доставки сообщений. Они работают только когда на них ссылаются роутеры, таким образом порядок в котором они заданы - неважен. Раздел транспортов начинается с
|
Определены один удалённый и четыре локальных транспорта.
|
Этот транспорт используется для доставки сообщений через SMTP-соединение. Все его опции - умолчальные. Список удалённых хостов даётся маршрутизатором.
|
Транспорт
“appendfile
” используется для локальной доставки в пользовательские почтовые ящики, в традиционном формате BSD mailbox. По дефолту, он запускается под uid и gid локального пользователя, что требует установки
“липкого
” (
“sticky
”) бита на директории
“/var/mail
”. Некоторые системы используют иной подход к запуску доставки почты, под специфической группой, вместо использования
“липкого
” бита. Закомментированные опции показывают, как это может быть сделано.
“
При доставке, exim добавляет к сообщению три заголовка: Delivery-date:
”,
“Envelope-to:
” и
“Return-path:
”. Это регулируется тремя опциями, с подобными названиями.
|
Этот транспорт используется для обработки доставки в каналы, генерируемых редиректом (альясингом, или пользовательским файлом
“.forward
”). Опция
“return_output
” определяет, что любой вывод сгенерированный каналом, должен быть возвращён отправителю.
|
Это транспорт используется для обработки доставки в файлы, проиведённым редиректом. Имя файла не задаётся в
“appendfile
”, поскольку оно приходит от маршрутизатора
“redirect
”.
|
Этот транспорт используется для обработки автоматических ответов, сгенерённых пользовательскими фильтрами.
7.5 Дефолтовые правила повторов
Секция повторов конфигурационного файла, содержит правила затрагивающие поведение exim`a при повторах доставки сообщений, которые не удалось доставить с первого раза. Она начинается со строки
|
В дефолтовой конфигурации, есть только одно правило, применяемое ко всем ошибкам:
|
Это заставляет exim пытаться доставить любой временно неудачный адрес в течение двух часов каждые 15 минут, затем интервал начинается с часа и увеличивается с фактором полтора пока не пройдёт 16 часов, затем каждые 6 часов, до срока в 4 дня. Если адрес не удаётся доставить после 4-х дней временного отказа, то происходит генреация рикошета (письмо возвращается отправителю).
Если секция повторов удалена из конфигурации, или она пуста (т.е. - не задано никаких правил повторов), exim не предпринимает попыток повторных доставок. Это превращает временные ошибки в постоянные.
7.6 Конфигурация перезаписи
Раздел конфигурации перезаписи, начинаемый с
|
содержит правила для перезаписи адресов в прибывших сообщениях. В дефолтовом конфиге нет правил перезаписи.
7.7 Конфигурация аутентификаторов
Секция аутентификаторов файла конфигурации, начинаемая с
|
задаёт механизмы для использования в команде SMTP AUTH. В дефолтовом кофигурационном файле содержаться два закомментированных примера аутентификаторов, которые поддерживают аутентификацию пользователь/пароль открытым текстом, используя стандартный механизм PLAIN, и традиционный, но нестандартный механизм LOGIN, в которых exim выступает в роли сервера. PLAIN и LOGIN поддерживаются большинством MUA.
Пример аутентификатора PLAIN выглядит так:
|
И пример аутентификатора LOGIN:
|
Опция
“server_set_id
” заставляет exim запомнить авторизованное имя пользователя в
“$authenticated_id
”, которая может быть использована позднее, в ACL или роутерах. Опция
“server_prompts
” конфигурирует аутентификатор
“plaintext
” таким образом, что он реализует детали специфического аутентификационного механизма, т.е. - PLAIN или LOGIN. Установка
“server_advertise_condition
” контролирует, когда exim посылает клиентам приглашение аутентифицироваться; в примере, это происходит лишь при запуске TLS или SSL, таким образом, для включения этих аутентификаторов вам также необходимо добавить поддержку TLS, как описано в разделе 7.1.
“
Установка server_condition
” определяет как проверить корректность пользователя и пароля. В примерах, она просто выводит сообщение о ошибке. Чтобы аутентификаторы заработали, вы должны использовать выражение раскрытия стоки, похожее на примеры в главе 34.
Помните, что последовательность параметров для PLAIN и LOGIN различна; пользователь и пароль находятся в различных позициях. В главе 34 описаны оба.
=============
translated by lissyara
verifying by Gerk
Этот информационный блок появился по той простой причине,
что многие считают нормальным, брать чужую информацию не уведомляя автора
(что не так страшно), и не оставляя линк на оригинал и автора — что более существенно.
Я не против распространения информации — только за. Только условие простое — извольте
подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой,
незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.
© lissyara 2006-10-24 08:47 MSK