|
|
www.lissyara.su
—> документация
—> EXIM
—> 4.70
—> часть 3
3. Как еxim получает и доставляет почту
3.1 Общая философия
Exim спроектирован для работы на системах, постоянно связанных с интернетом, и обрабатывающих значительный поток писем. В таких условиях, большинство сообщений можно доставить немедленно. Следовательно, exim не поддерживает независимые очереди сообщений для специфических доменов или хостов, хотя в действительности, пробует послать несколько сообщений в течение одного SMTP-соединения, после того как хост был в дауне (отключен, недоступен и т.п. - прим. lissyara), также он умеет работать с инофрмацией о количестве повторов для каждого хоста.
3.2 Управление политиками
Управление политиками - это теперь важная особенность MTA, связанных с интернетом. Возможно, их самое важное назначение - это не допустить использование MTA в качестве открытого релея людьми отсылающими много спама, и желающими замаскировать его источник. Exim предоставляет гибкие средства для управления политиками применяемыми к входящей почте:
Exim4 (в отличие от предыдущих версий exim) в качестве политик управления, используются “Access Control Lists” (ACL`ы). Каждый список является серией утверждений, могущих предоставлять или запрещать доступ. ACL могут использоваться на различных стадиях SMTP-диалога, при получении сообщения с удалённого хоста. Однако, обычное их местоположение - после каждой команды RCPT, и в самом конце сообщения. Системный администратор может определить условия для приёма или отклонения индивидуальных получателей, или всего сообщения целиком, соответственно, в этих двух точках (смотрите раздел 40). Отказ в доступе приводит к появлению SMTP-ошибки с соответствующим кодом.
Также, ACL, доступны для сгенерённого локально сообщения, не полученного по SMTP. В этом случае, единственно доступными действиями являются отклонение или принятие письма в целом.
Когда exim собран с расширением контентного сканирования, средства механизма ACL позволяют передавать сообщения внешней антивирусной или антиспамовой программе. Результат проверки возвращается ACL, который может использовать его для решения того, что делать с сообщением.
Когда сообщение получено с удаленного, или локального хоста, но до отправки финального подтверждения, может быть выполнена локальная функция С, называемая “local_scan()” для анализа сообщения, и принятия решения о его приёме, или отклонении (смотрите раздел 42). Если сообщение принимается, функция может изменить список получателей.
Использование механизма “local_scan()” - это другой способ вызвать внешнее сканирующее программное обеспечение. Добавочный пакет “SA-Exim” использует этот путь. Эта опция не требует чтобы exim был собран с поддержкой контентного сканирования.
После того, как сообщение было принято, дальнейшие проверяющие механизмы доступны в виде “системного фильтра” (“system filter” - смотрите раздел 43). Он выполняется в начале каждого процесса доставки.
3.3 Пользовательские фильтры
В обычной конфигурации exim`a, пользователи могут запускать частные (собственные) фильтры, устанавливая соответствующие файлы “.forward” в своих домашних директориях. Смотрите раздел 22 (о переадресовывающем маршрутизаторе) конфигурации нуждающейся в этом, и отдельный документ “интерфейсы фильтрации почты exim`a” (“Exim’s interfaces to mail filtering”) для получения дополнительных деталей. Доступны два различных вида фильтрации:
Фильтры Sieve написаные на стандартном языке фильтров, как определено в RFC3028.
Фильтры exim, написанные с использованием уникального синтаксиса exim, являющегося более мощным, чем Sieve, которому он предшествует.
Пользовательские фильтры выполняются как часть процесса маршрутизации, описанного ниже.
3.4 Идентификация сообщений
Каждому сообщению, обрабатываемому exim`ом, даётся “message id” длинной в шестнадцать символов. Они разделяются на три части, с дефисом в качестве разделителя, например “16VDhn-0001bo-D3”. Каждая часть - последовательность букв и цифр, обычно - число кодированное по основанию 62. Однако, в операционной системе Darvin (Mac OS X) и когда exim собран для запуска в Cygwin, взамен используется основание 36 (уход от использования строчных букв), поскольку идентификатор сообщения используется для создания имени файлов,а в этих операционных системах строчные и прописные буквы в именах файлов не всегда различаются.
Способ формирования идентификатора сообщения изменился во время развития Exim. Более ранние версии полагались на операционную систему не использующую заново идентификатор процесса (PID) в течение одной секунды. На современных операционных системах, такое предположение более не может быть сделано, таким образом, алгоритм должен был быть изменён. Для сохранения обратной совместимости, старый формат идентификатора сообщения также поддерживается, поэтому следующие правила выглядят несколько эксцентрично:
Первые шесть символов идентификатора сообщения - время в которое началось получение сообщения, с детализацией до одной секунды. Таким образом, это поле содержит число секунд с начала эпохи (нормальное представление даты и времени в UNIX).
После первого дефиса, следующие шесть символов это идентификатор процесса получившего сообщение.
Для двух заключительных символов есть два варианта:
1. Если “localhost_number” не установлен, это значение - дробная часть времени приёма, обычно в частях 1/2000 секунды, но для систем, которые должны использовать основание 36 вместо основания 62 (из-за нечувствительных к регистру файловых систем), модуль - 1/1000 секунды.
2. Если “localhost_number” установлена, то она умножается на 200(100) и добавляется к дробной части времени, которое в этом случае находится в частях 1/200(1/100) секунды.
После получения сообщения, exim ждёт следующей временной отметки (необходимого разрешения) перед переходом к следующей стадии, на случай, если другое сообщение получено тем же процессом, или другим процессом с тем же (заново использованным) pid, для гарантирования, что время будет отличаться. В большинстве случаев, время успевает измениться при получения сообщения.
3.5 Получение почты
Exim может получать почту с других хостов лишь единственным способом, с использованием SMTP через TCP/IP, когда адреса отправителя и получателя передаются через команды SMTP. Однако, из локально работающих процессов (таких как пользовательские MUA), можно отправить почту несколькими способами:
Если процесс запускает exim с опцией “-bm”, сообщение читается неинтерактивно (обычно через трубу (pipe)), с получателями взятыми из командной строки, или из тела сообщения, если также используется опция “-t”.
Если процесс запускает exim с опцией “-bS”, сообщение также читается неинтерактивно, но в этом случае получатели перечислены в начале сообщения в ряде команд SMTP RCPT, завершаемых командой DATA. Это - так называемый “пакетный SMTP” (“batch SMTP”) формат, но реально, это не SMTP. Команды SMTP - это лишь иной способ передать адреса конверта в неинтерактивном представлении.
Если процесс запускает exim с опцией “-bs”, сообщение читается интерактивно, с использованием протокола SMTP. Двухсторонняя труба (pipe) обычно используется для обмена данными между локальным процессом и процессом exim'a. Это “реальный” SMTP, и обрабатывается он таким же образом как SMTP через TCP/IP. Например, ACL`ы для SMTP-команд используются в этой форме подачи сообщения.
Локальный процесс может сделать вызов TCP/IP к обратной петле (127.0.0.1) хоста, или любому другому из его IP-адресов. Получая сообщения, exim не обрабатывает адрес обратной петли по особенному. Он обрабатывает такие подключения таким же образом как и подключения с других хостов.
В трёх случаях, когда не используется TCP/IP, адрес отправителя составляется из логина пользователя, вызывавшего exim и дефолтового полного (квалифицированного) имени хоста (которое может быть задано конфигурационной опцией “qualify_domain”). Для локального, или пакетного SMTP, адрес отправителя передаваемый командой SMTP MAIL игнорируется. Однако, системный администратор может позволить определённым пользователям (“trusted users”) безусловно задать другой адрес отправителя, или всем пользователям задавать определённую форму иного адреса отправителя. Опция “-f” или команда SMTP MAIL используется для задания этих адресов (имеется в виду - адресов отправителя - прим. lissyara). Смотрите раздел 5.2 для получения деталей о “trusted users”, и опции “untrusted_set_sender” для подробностей о способе изменить адрес недоверенным пользователям.
Сообщения полученные любым неинтерактивным механизмом проверяются не-SMTP ACL, если они заданы. Сообщения полученные с использованием SMTP (по TCP/IP, или от локального процесса) могут быть проверены многими ACL, работающими в разные моменты времени сеанcа SMTP. Может быть отклонено всё сообщение, или индивидуальные получатели, если они не отвечают требованиям локальных политик. Функция “local_scan()” (смотрите раздел 42) запускается для всех входящих сообщений.
Exim может быть сконфигурирован не начинать процесс немедленной доставки после получения сообщения, эта политика может быть безусловной, или зависить от числа входящих SMTP соединений или нагрузки на систему. В таких ситуациях новые сообщения остаются в очереди до тех пор, пока обработчик очереди не выберет их из неё. Однако, в стандартных конфигурациях при нормальных условиях, доставка сообщений начинается сразу же после получения сообщения.
3.6 Обработка входящих сообщений
Когда exim принимает сообщение, он записывает его в два файла, в spool-директории. Первый содержит информацию конверта, текущий статус сообщения, и строки заголовка, второй содержит тело сообщения. Имена обоих файлов состоят из идентификатора сообщения, с добавлением “-H” для файла с заголовками и конвертом, и “-D” для файла с данными.
По дефолту, все эти файлы содержатся в одном каталоге, называемом “input”, внутри главной spool-директории exim. Некоторые операционные системы не очень хорошо работают, когда число файлов в директории становится большим; для улучшения производительности, в таких случаях, может использоваться опция “split_spool_directory”. Она заставляет exim распределять файлы входящих писем по 62-м директориям, с именами в виде одиночных цифр и букв. Когда это сделано, обработка очереди происходит покаталогово, вместо одновременной обработки всех каталогов, это может увеличить производительность даже при небольшом количестве файлов в каждой из директорий, даже если это количество файлов не влияет на быстродействие файловой системы.
Информация конверта состоит из адреса отправителя сообщения и адресов получателей. Эта информация является обособленной от любых адресов содержащихся в строках заголовков. Статус сообщения включается в список получателей, которые уже получили сообщение. Формат первого файла spool-директории описан в разделе 53.
Перезапись адресов, если она задана в конфигурационной секции rewrite (смотрите раздел 31), производится однократно и для всех входящих адресов, и в строках заголовков и в конверте, во время приёма сообщения. Если во время доставки сгенерены новые адреса (например, через альясинг), эти новые адреса перезаписываются в тот момент когда они генерятся. Во время фактической доставки сообщения может быть дальнейшая перезапись; поскольку это транспортная опция, она может быть различной для разных типов доставки. Также возможно задать добавление, или удаление определённых строк заголовков, во время доставки сообщения (смотрите разделы 15 и 24).
3.7 Цикл жизни сообщения
Сообщение остаётся в spool-директории до полной доставки получателям или ошибочному адресу (адресу куда шлют сообщения об ошибках - прим. lissyara), или до уничтожения администратором или пользователем изначально создавшим его. В случае, когда доставка не может быть произведена - например, когда сообщение не может быть доставлено получателю, и не может быть возвращено отправителю, то оно отмечается как “замороженное” в spool`e и больше не предпринимается попыток его доставки.
Администратор может “разморозить” такие сообщения, когда проблема исправлена, а также может вручную заморозить отдельные сообщения. Кроме того, администратор может вызывать принудительную ошибку доставки, вызвав отсыл сообщения о недоставке (рикошет).
Эти опции, называемые “ignore_bounce_errors_after” и “timeout_frozen_after”, отбрасывают замороженные сообщения после определённого времени. Первое применяется только к замороженным сообщениям о недоставке, вторые - к любым замороженным сообщениям.
Когда exim работает с сообщением, он записывает информацию о каждой попытке доставки в свой лог-файл. Туда включаются успешные, неуспешные и отложенные доставки для каждого получателя (смотрите главу 49). Строки логов также пишутся в отдельные файлы “message log” для каждого сообщения. Эти логи - исключительно для использования администратором, и обычно удаляются вместе вместе с файлами spool`a, когда обработка сообщения завершена. Использование индивидуальных логов сообщений может быть отключено установкой опции “no_message_logs”; это может дать прирост производительности на очень загруженных системах.
Вся информация необходимая exim`y для доставки сохраняется в первом spool-файле, наряду со строками заголовка. Когда происходит успешная доставка, адрес немедленно вписывается в конец журнального файла, имя которого - идентификатор сообщения с добавленным “-J”. В конце выполненной доставки, если остались адреса, которые необходимо доставить позднее, первый spool-файл (“-H” - файл) обновляется, для указания какой момент доставки сейчас, и журнальный файл удаляется. Обновление spool-файла завершается записью нового файла и переименовыванием его, для минимизации возможной потери данных.
Если происходит падение системы или программы после успешной доставки, но до обновления spool-файла, журнал остаётся лежать (на диске, видимо - прим. lissyara). В следующий раз, когда exim пытается доставить сообщение, он читает журнал и обновляет spool-файл до обработки. Это минимизирует возможность двойной доставки, вызванную сбоями.
3.8 Обработка адреса для доставки
Главную доставку обрабатывают элементы exim называемые “роутеры” (“routers”) и “транспорты” (“transports”), и вместе они известны как “драйверы” (“drivers”). Их код распространяется с исходным дистрибутивом, и опции компиляции задают, какие из них включаются в бинарный файл. Опции выполнения (во время выполнения) определяют, какие из них фактически используются для доставки сообщения.
Каждый драйвер, который задан в выполняемой конфигурации - “экземпляр” (“instance”) того специфического типа драйвера. Многократное использование одного роутера разрешается; например, вы можете задать несколько различных транспортов “smtp”, каждый с различными значениями опций, например задающие иные порты или таймауты. В дальнейшем, обычно, будет использоваться само название драйвера (т.е. одна, определённая конфигурация), и общее название драйвера, при обсуждении общих особенностей драйвера.
“Роутер” (“router”, или “маршрутизатор”) - драйвер, работающий с адресами, также определяет каким образом должна произойти его доставка, задавая определённый транспорт, или преобразуя адрес в один или несколько новых адресов (например, через файл альясов). Маршрутизатор также может явно (в смысле, целенаправленно - прим. lissyara) вызвать ошибку адреса, вызывая доставку сообщения о недоставке.
“Транспорт” (“transport”) - драйвер, который передаёт копию сообщения из spool-директории exim`a в другое место назначения. Есть два вида транспортов: локальный, с местом назначения в файле или трубе на локальном хосте, и удалённый - с местом назначения на иных хостах. Сообщение передаётся определённому транспорту как результат успешной маршрутизации. Если у сообщения несколько получателей, оно может быть передано нескольким различным транспортам.
Адрес обрабатывается передачей его каждому сконфигурированному роутеру, по очереди, подчиняясь определённым условиям, до тех пор пока роутер не примет адрес, или определит, что надо вызвать ошибку адреса (принудительно - прим. lissyara). Скоро этот процесс будет описан в деталях. Вначале, как простой пример, рассмотрим, как каждый адрес получателя в сообщении обрабатывается в небольшой конфигурации из трёх роутеров.
Для того, чтобы сделать это более конкретным примером, описание сделано в терминах некоторых актуальных роутеров, но помните, что это лишь пример. Вы можете сконфигурить роутеры exim`a несколькими разными способами, и может быть любое число роутеров в конфигурации.
Обычно первый маршрутизатор, определённый в конфигурации, занимается обработкой адресов в доменах, которые не распознаны, как относящиеся к локальному хосту. Обычно это адреса произвольных доменов интернета. Установлено предварительное условие ищущее домены относящиеся к локальному хосту, и маршрутизатор выполняется для адресов не соответствующих условию. Обычно, этот роутер ищет домены в DNS, для нахождения хостов к которым направляется этот адрес. Если поиск успешен, адрес передаётся подходящему SMTP-транспорту; если неуспешен, роутер сконфигурен на отказ адреса (генерится сообщение о недоставке - прим. lissyara).
Второй роутер достигается лишь в случае, если домен распознан как “принадлежаший” локальной машине. Этот роутер делает редирект - известный также как альясинг, форвардинг. Когда он генерит один или больше новых адресов из оригинального, каждый из них роутится независимо от начального. Иначе маршрутизатор может вызвать отказ адреса, или просто отказаться обрабатывать его, передав следующему роутеру.
Последний роутер во многих конфигурациях проверяет, принадлежит ли адрес локальным почтовым ящикам. Предварительное условие может содержать проверку - является ли локальная часть именем логина пользователя, или он ищет её в файле или базе данных. Если эти предварительный условия не выполнены, роутер отклоняется, и на этом маршрутизаторы заканчиваются. Когда такое происходит (письмо с этим адресом было отклонено всеми роутерами - прим. lissyara), происходит рикошет (шлётся письмо отправителю с сообщением, что не удалось доставить письмо - прим. lissyara).
3.9 Обработка адреса в режиме верификации
Роутеры exim`a используются для принятия решения о том, как доставлять почту, а также для “проверки адреса” (“address verification”). Верификация может быть запрошена как одна из проверок, которая должна быть выполнена в ACL для входящих сообщений, для обоих адресов - отправителя и получателя, и она может быть протестирована с использованием опций “-bv” и “-bvs” командной строки.
Когда адрес проверяется, роутеры работают в “режиме проверки” (“verify mode”). Это не изменяет порядка выполнения роутеров, но может изменять результат их работы. Это значит, роутер может быть пропущен или вынужден вести себя иначе при проверке. Типичным примером может быть конфигурация, в которой первый роутер посылает все сообщения в сканирующую программу, если они не были просканированы ранее. Таким образом, первый роутер принимает все адреса без каких бы то ни было проверок, делая его бесполезным для проверки. Обычно для таких маршрутизаторов, устанавливается опция “no_verify”, заставляя его быть пропущенным в проверяющем режиме.
3.10 Работа отдельного роутера
Как объяснено в примере выше, несколько предварительных условий проверяются до запуска роутера. Если любое условие не встречается, роутер пропускается и адрес передаётся следующему маршрутизатору. Когда все предварительные условия для маршрутизатора соблюдены, он выполняется. Что происходит дальше, зависит от результата, являющегося одним из следующих:
accept”: маршрутизатор принимает адрес, и, или передаёт его транспорту, или генерит один или более “дочерних” адресов. Обработка оригинального адреса прекращается, если опция “unseen” не установлена на маршрутизаторе. Эта опция может использоваться для многократных доставок, с различной маршрутизацией (например, для сохранения архивных копий сообщений). Когда опция “unseen” установлена, адрес передаётся следующему роутеру. Однако, обычно, “accept” означает конец роутинга.
Любой дочерний адрес, сгенерённый роутером, обрабатывается независимо, начиная с первого дефолтового маршрутизатора. Можно изменить это, установкой опции “redirect_router”, для определения с какого маршрутизатора начинается обработка дочерних адресов. В отличие от опции “pass_router” (см. ниже), роутер, определённый “redirect_router” может быть в любом месте конфигурации.
pass”: Роутер распознаёт адрес, но не может сам его обработать. Он запрашивает отправку адреса другому роутеру. По-умолчанию, адрес передаётся следующему роутеру, но это может быть изменено установкой опции “pass_router”. Однако (в отличие от “redirect_router”) названный маршрутизатор должен быть ниже текущего роутера (для избежания петель).
decline”: Роутер отказывается принимать адрес, поскольку вообще отказывается принимать их все. По-умолчанию, адрес передаётся следующему маршрутизатору, но это может быть предотвращено установкой опции “no_more”. Когда “no_more” установлена, все последующие роутеры пропускаются. В действительности, “no_more” преобразует “decline” в “fail”.
fail”: Роутер решает, что адрес ошибочен, и ставит его в очередь на рикошет. Дальнейшая обработка адреса отсутствует, если опция “unseen” не установлена на роутере.
defer”: В настоящее время роутер не может обработать адрес. (Может быть недоступна БД, или таймаут DNS) Дальнейшая обработка адреса не производится для этой попытки доставки. Попытка обработать этот адрес будет произведена при следующей обработке этого сообщения.
error”: В маршрутизаторе какая-то ошибка (например, ошибка конфигурации). Действие - такое же как и для “defer”.
Если адрес достигает конца маршрутизаторов, и не принимается ни одним из них, он срывается, как “unrouteable”. Дефолтовая ошибка, в такой ситуации - “unrouteable address”, но можно установить своё сообщение, используя опцию “cannot_route_message”. Она может быть установлена для любого роутера, используется значение из последнего роутера “видевшего” адрес.
Иногда, при роутинге, вы хотите сделать ошибку доставки, вместо передачи адреса для дальнейшей маршрутизации, когда одни условия совпадают, а другие нет. Вы можете сделать это, при наличии второго маршрутизатора, который явно делает доставку неудачной, когда необходимые условия выполняются. Роутер “redirect” для этой цели имеет средство “fail”.
3.11 Дублирующиеся адреса
Как только маршрутизация завершена, exim просматривает адреса, предназначенные для локальных и удалённых транспортов, и отбрасывает любые найденные дубликаты (повторения). В процессе этой проверки локальные части обрабатываются с учётом регистра. Это происходит лишь при реальной доставке сообщения; при тестировании роутеров с опцией “-bt” отображаются все адреса появившиеся в процессе работы роутеров.
3.12 Предварительные условия роутера
Предварительные условия, проверяемые на каждом маршрутизаторе, перечислены ниже в порядке их проверки. Индивидуальные конфигурационные опции описаны более подробно в разделе 15.
Опции “local_part_prefix” и “local_part_suffix” могут определять, что локальные части, обработанные маршрутизатором, могут или должны иметь префиксы и/или суффиксы. Если принудительный аффикс (префикс или суффикс) отсутствуют, роутер пропускается. Эти условия проверяется первыми. Когда аффикс есть, он удаляется из локальной части до последующей обработки, включая оценку любых других условий.
Маршрутизаторы могут назначаться для использования только когда не проверяется адрес, т.е. только в том случае, когда письмо маршрутизируется для доставки (или проверяется маршрутизация доставки). Eсли опция “verify” установлена в “false”, при проверке адреса роутер пропускается. Установка опции “verify” реально устанавливает две опции - “verify_sender” и “verify_recipient”, которые независимо управляют использованием роутера для проверки отправителя и получателя. Вы можете установить эти опции непосредственно, если хотите чтобы роутер использовал только один тип проверки.
Если опция “address_test” установлена в “false”, роутер пропускается, когда exim запущен с опцией “-bt” для проверки маршрутизации адреса. Это может быть полезным, когда первый роутер посылает все новые сообщения для сканирования; это позволяет использовать “-bt” для проверки последующей маршрутизации доставки без необходимости моделировать эффект сканера.
С помощью опции "verify_only" можно сконфигурировать роутеры, только для работы в режиме проверки адреса.
Отдельные роутеры могут быть явно пропущены, при проверке адрессов переданных с помощью SMTP комманды EXPN (смотрите опцию “expn”).
Если установлена опция “domains”, домен адреса должен быть в списке заданных доменов.
Если установлена опция “local_parts”, локальная часть адреса должна быть в списке заданных локальных частей. Если используются “local_part_prefix” или “local_part_suffix”, префикс или суффикс удаляются из локальной части перед проверкой. Если вы хотите призвести проверку предварительного условия на локальной части со включенными аффиксами, вы можете сделать это включением опции “condition” (см. ниже), которая использует переменные “$local_part”, “$local_part_prefix” и “$local_part_suffix” по мере необходимости.
Если уставновлена опция “check_local_user”, локальная часть должна быть именем учётной записи на локальном хосте. Если эта проверка успешна, uid и gid локального пользователя помещаются в “$local_user_uid” и “$local_user_gid”, и пользовательская домашняя директория помещается в “$home”; эти значения могут использоваться в оставшихся предварительных условиях
Если установлена опция “router_home_directory”, это раскрывается в этой точке, поскольку оно отменяет значение “$home”. Если бы раскрытие откладывали на более позднее или ранее время, то значение “$home” установленное “check_local_user” использовалось бы в последующих проверках. Наличие двух различных значений “$home” в одном и том же роутере может привести к беспорядку.
Если установлена опция “senders”, адрес отправителя конверта должен быть задан в наборе адресов.
Если установлена опция “require_files”, проверяется существование или отсутствие указанных файлов.
Если установлена опция “condition”, о её значение раскрывается и проверяется. Эта опция использует раскрытие строк, для разрешения возможности установить собственные предварительные условия. Раскрываемые строки описаны в разделе 11.
Отметьте, что “require_files” находится в конце списка, таким образом, вы не можете использовать её для проверки существования файлов в которых ищется домен, локальная часть, или отправитель. Однако, поскольку все эти опции раскрыты, вы можете использовать раскрытие условия “exists” для создания проверок внутри условий. Опция “require_files” предназначена для проверки файлов, которые роутер может собираться использовать внутри себя, или которые необходимы определённым транспортам (например, “.procmailrc”).
3.13 Доставка в деталях
Когда необходимо доставить сообщение, последовательность событий такова:
Если определён общесистемный фильтр, то сообщение передаётся ему. Фильтр может добавить в сообщение получателей, заменить получателей, отказать сообщению, сгенерить новое сообщение, или сделать вынужденную невозможность доставки сообщения. Формат файла системного фильтра такой же как у пользовательских фильтров exim`a, описанный в отдельном документе называющемся “Exim’s interfaces to mail filtering”. (Отметьте: Sieve не может использоваться в файлах системного фильтра.)
Некоторые дополнительные особенности доступны в системном фильтре - смотрите раздел 43 для получения дополнительной информации. Заметьте, что сообщение передаётся системному фильтру только одина раз за попытку доставки, однако он установлен у многих получателей. Однако, если происходит несколько попыток доставки, при невозможности доставить немедленно один, или несколько адресов, системный фильтр выполняется каждый раз. Условие “first_delivery” может использоваться для обнаружения первого запуска системного фильтра.
Каждый адрес получателя предлагается по очереди каждому сконфигурированному роутеру, следуя его предварительным условиям, пока один из роутеров не сможет его обработать. Если ни один маршрутизатор не может обработать адрес, т.е. они все отклоняются, адрес неверный. Поскольку роутеры могут быть целями разных доменов, несколько разных локальных доменов можно обработать независимо друг от друга.
Роутер принимающий адрес, может назначить его локальному или удалённому транспорту. Однако, в это время транспорт не выполняется. Вместо этого адрес помещается в список специфического транспорта, который будет выполнен позже. Альтернативно, маршрутизатор может генерить один, или несколько новых адресов (обычно, из альясов, форвардов, или файлов фильтров). Новый адреса возвращаются назад к началу процесса, но во избежание петель, маршрутизатор игнорирует любой адрес имеющий одноимённого предка, обрабатывающегося отдельно.
Когда вся маршрутизация завершена, успешно обработанные адреса передаются назначенным им транспортам. Когда локальные транспорты делают действительно локальные доставки, они обрабатывают только один адрес за раз, но если локальный транспорт используется как псевдо-удалённый (например, для сборки пакетов SMTP-сообщений, для передачи каким-то другим средствам), могут быть обработаны несколько адресов. Удалённые транспорты всегда могут обрабатывать более одного адреса за раз, но они могут быть сконфигурированы не делать так, или ограничены в нескольких одновременных обращениях к одинаковому домену.
Каждая локальная доставка в файл, или трубу, запускается отдельным процессом с непривелигированным uid, и выполняются они по одной. Удалённые доставки также выполняются отдельными процессами, обычно под частным uid exim`a (“пользователь exim”), но в этом случае, несколько удалённых доставок могут выполняться параллельно. Максимальное число одновременных удалённых доставок, для любого сообщения, устанавливается опцией “remote_max_parallel”. Порядок, в котором производятся доставки, не определён, за тем исключением, что все локальные доставки происходят до удалённых.
Если во время обработки очереди встречается локальная доставка, exim проверяет базу повторов для поиска - была ли временная ошибка для этого адреса ранее, перед выполнением работы локального транспорта. Если ранее была ошибка, exim не делает новую попытку доставки, пока для этого адреса не достигнуто время повторения. Подобные ситуации могут случаться только для тех попыток доставки, которые порождены во время обработи текущей очереди. Локальные доставки всегда производятся сразу после завершения приёма сообщения, даже если для них установлено время повтора. Это делается для улучшения поведения в случае если одно сообщение вызывает проблемы (например, вызывает переполнение квоты, или ошибку в фильтре).
Удалённые транспорты выполняют собственную обработку повторов, так как адрес может доставляться к одному из множества хостов, каждый из которых может иметь различное время повтора. Если были предыдущие временные сбои, и никакой хост не достиг своего времени повтора, попытка доставки не предпринимается, независимо от того работала очередь или нет. Смотрите раздел 32, для деталей об обработке повторения.
Если были какие-то постоянные ошибки, рикошет возвращается к соответствующему адресу (отправитель, в общем случае), с деталями ошибки для каждого ошибочного адреса. Exim может быть сконфигурирован для отправки копий сообщений о рикошете на другие адреса.
Если один или несколько адресов потерпели временный сбой, сообщение остаётся в очереди, для дальнейших попыток. Доставка этих адресов, как говорят, “задержана” (“deferred”).
Когда все адреса получателей доставлены, или сорвались, обработка сообщения завершена. Файлы спула и логи сообщения удаляются, хотя лог, опционально, может быть сохранён, в случае необходимости.
3.14 Механизм повтора
Этот механизм exim'a предназначен для повтора сообщений, которые обработчик очереди не сумел доставить с первой попытки. Вы должны запустить демона exim`a с опцией “-q” с параметром "интервал времени", для запуска обработчика очереди с регулярными интервалами времени, или использовать другие средства (например, cron)? чтобы запустить его. Если вы не будете предпринимать мер к запуску обработчика очереди, сообщения, недоставленные при первой попытке, навсегда останутся в очереди. Обработчик очереди обрабатывает очередь по одному сообщению, пробуя каждую доставку (адреса получателей - прим. переводчика) с прошедшим временем повторения. Вы можете запустить несколько обработчиков очереди одновременно.
Exim использует набор конфигурационных правил для определения, когда должен быть попытка отправки для ошибочного адреса (смотрите раздел 32). Эти же правила определяют, когда exim должен прекратить попытки доставки адреса, и сгенерировать рикошет. Если для частного хоста, адреса или комбинации ошибок не установлены правила повтора, то временные ошибки обрабатываются как постоянные.
3.15 Временные ошибки доставки
Существует много причин, по которым сообщение не доставляется немедленно по частному адресу. Сбой подключения к удалённой машине (поскольку хост, или подключения к нему, отcутствовали) - одна из самых распространённых. Временные ошибки могут быть обнаружены в процессе роутинга, а также в течение транспортной стадии доставки. Локальные доставки могут быть задержаны, если недоступны NFS файлы, или почтовый ящик находится в файловой системе, в которой у пользователя превышена квота. Exim может быть сконфигурирован для использования собственных квот на локальные почтовые ящики; там, где используются системные квоты, они также применяются.
Если хост недоступен некоторое время, множество сообщений может ожидать его, к тому времени, когда он станет доступен, и их отправка в течение одного SMTP-соединения, явно выгодна. Всякий раз, когда доставка на удалённый компьютер задерживается, exim делает примечание в своей БД хинтов (можно перевести как БД намёков - прим. lissyara), и всякий раз когда происходит успешная SMTP-доставка, он смотрит, есть ли другие сообщения для этого же хоста. Если они найдены, они отправляются по тому же самому SMTP-соединению, ограниченные указанным в конфигурации числом максимальных сообщений через одно соединение.
3.16 Постоянные ошибки доставки
Когда сообщение невозможно доставить к нескольким или всем его получателям, генериться сообщение рикошета. Временные ошибки доставки превращаются в постоянные ошибки, когда истекает их время ожидания. Все адреса, которые ошибочны в данной попытке доставки, перечисляются в одном сообщении. Если у оригинального сообщения много получателей, возможно что некоторые адреса недоставлены в первую попытку, и другие были неудачны в последующие попытки, возможна генерация более одного рикошета. Формулировка сообщения рикошета может быть настроена администратором. Для дополнительных деталей, смотрите раздел 46.
Сообщения рикошета содержат строку заголовка “X-Failed-Recipients:”, содержащую список неудачных адресов, для программ которые автоматически анализируют такие сообщения.
Рикошет, обычно, отправляется отправителю оригинального сообщения, полученного из адреса конверта. Для входящих SMTP-сообщений, это адрес, данный в команде MAIL. Однако, когда адрес раскрывается через форвардинг или альясинг, может быть задан альтернативный адрес для доставки рикошетов от сгенерённых адресов. При использовании списков рассылки (смотрите раздел 47.2), рикошеты обычно отправляются менеджеру списка рассылки.
3.17 Сбой доставки рикошета
Если с рикошетом (сгенерированным локально, или пришедшим с удалённого хоста) происходит сбой доставки, сообщение остаётся в очереди замороженным (“frozen message” - прим. переводчика), ожидая внимания администратора. Существуют опции, которые могут использоваться для того, чтобы заставить exim отбросить такие сообщения, или хранить их короткий период времени (смотрите опции “timeout_frozen_after” и “ignore_bounce_errors_after”).
=============
translated by lissyara
verifying by Gerk
Ссылка на обсуждение: http://forum.lissyara.su/viewforum.php?f=20.
|
|
2014-07-27, lissyara
gmirror
Удалённое создание софтверного зеркала средствами gmirror, на диске разбитом с использованием gpart. Использование меток дисков для монтирования разделов.
2013-08-20, zentarim
Scan+Print server FreeBSD 9
Настройка сервера печати и сервера сканирования под управлением операционной системы FreebSD 9 для МФУ Canon PIXMA MP540
2011-11-20, BlackCat
Разъём на WiFi-карту
Делаем съёмной несъёмную антену на WiFi-карте путём установки ВЧ-разъёма
2011-09-14, manefesto
Настройка git+gitosis
Настройка системы контроля версия исходного кода в связке git+gitosis+ssh
2011-08-14, zentarim
Wi-FI роутер + DHCP + DNS
Настройка Wi-Fi роутера на Freebsd 8 + DNS сервер + DHCP сервер: чтобы Wi-Fi клиенты были в одной подсети с проводными, проводные и беспроводные клиенты получали адреса автоматически по DHCP, кэширующ
2011-06-15, -ZG-
Охранная система на FreeBSD+LPT
В этой статье описана попытка реализации простой охранной системы на базе FreeBSD с подключением к ней охранных устройтсв на LPT порт и видеорегистрацией.
2011-03-13, terminus
ng_nat
Описание работы ng_nat, практическое использование, достоинства и недостатки в сравнении с ipfw nat
2011-02-20, Капитан
Nagios+Digitemp
Статья описывает создание системы оповещения о превышении температуры в специальных помещениях на основе Nagios с использованием программы Digitemp.
2011-02-17, Le1
Zyxel Configuration
Скрипт для массового изменения конфига свичей Zyxel. Берет из файла iplist список ip-шек, заходит последовательно на каждый и выполняет комманды из файла commands, записывая происходящее в лог файл.
2011-02-16, fox
hast carp zfs ucarp cluster
HAST (Highly Available Storage), CARP, UCARP, ZFS, Cluster настройка и одаптация плюс личные размышления…
2011-02-04, BlackCat
Восстановление ZFS
История о том, как был восстановлен развалившийся RAIDZ ZFS-пул (перешедший в FAULTED) с помощью скотча и подручных средств. Или о том, какие приключения ожидают тех, кто не делает резервных копий.
2011-02-03, Капитан
1-Wire
Статья описывает самостоятельное изготовление контроллера DS9097 для съёма показаний с датчиков температуры DS1820 с помощью программы Digitemp.
2011-01-28, Капитан
Температура в серверной
Статья описывает построение системы наблюдения за температурой в помещении серверной с использованием программы Digitemp и выводом графиков в MRTG
2011-01-21, m4rkell
Syslog server
Как то буквально на днях, у нас завалилось, что то в еве) или не в еве не суть. Суть в том, что когда захотели снять логи с хостов esx обнаружили, что хранят эти негодяи логии только за последнии сутк
2011-01-07, lissyara
Canon/gphotofs
Монтирование цифровых фотоаппаратов Canon (PTP) как файловой системы, автоматизация этого процесса через события devd и внешние скрипты.
2010-12-13, Al
IPSec
Описание принципов работы IPSEC и способов аутентификации.
2010-12-07, manefesto
FreeBSD on flash
Было принято решении переехать на USB Flash и установить минимальный джентельменский набор для работы своего роутера. Делаем =)
2010-12-05, Fomalhaut
root ZFS, GPT
Инструкция по установке FreeBSD с использованием в качестве таблицы разделов GPT и в качестве основной файловой системы - ZFS
2010-09-05, Cancer
Настройка аудиоплеера на ximp3
Цели: Простенький аудиоплеер, для того что бы тетя продавец в магазине утром пришла нажала на кнопку Power и заиграла в зале музыка, так же был доступ по сети, общая шара куда можно заливать музыку, к
2010-08-31, Cancer
Установка и настройка OpenVPN
На днях появилась задача - объединить головной офис и 3 филиала в одну сеть через интернет посредством OpenVPN, чтобы люди могли подключаться через RDP к базам 1С на серверах.
2010-08-25, manefesto
freebsd lvm
Использование linux_lvm для работы с LVM разделами из-под FreeBSD. Проблемы которые возники при монтирование lvm раздела
2010-04-30, gonzo111
proftpd file auth"a
Proftpd - квоты и авторизация из файлов, без использования базы данных и/или системных пользователей
2010-04-22, lissyara
tw_cli
Пошаговая инструкция по восстановлению RAID на контроллере 3ware, из которого выпал один диск. Настройка мониторинга состояния рейда и отчётов о его состоянии на email.
2010-04-14, fox
MySQL Master+Master
MySQL (Master Master) and (Master Slave) Как настроить репликацию…
2010-03-09, terminus
DNS zones
Краткий ликбез про управление DNS зонами. Примеры проведения делегирования прямых и обратных DNS зон.
2010-03-09, aspera
Squid+AD (group access)
Настройка прокси сервера SQUID с автроризацией пользователей в AD. Разделение пользователей на группы
2010-03-02, BlackCat
Шлюз: Часть 4
Настройка дополнительных сервисов: синхронизация времени (OpenNTPD), клиент DynDNS.org.
2010-03-01, BlackCat
Шлюз: Часть 3
Настройка DHCP и DNS серверов для работы внутри частной сети, c поддержкой внутренних (частных зон) DNS, а так же интеграция DHCP и DNS сервисов.
2010-03-01, BlackCat
Шлюз: Часть 2
Конфигурация МСЭ pf для проброса портов с изменением порта назначения и без, а так же поддержки активного режима FTP и ограничения максимального размера сегмента
2010-03-01, BlackCat
Шлюз: Часть 1
Быстрая настройка шлюза/маршрутизатора с установлением PPPoE-соединения, поддержкой NAT и DNS-forwarding.
2010-02-23, Morty
darkstat
Простая считалка траффика, со встроенным веб-сервером. Очень маленькая, может делать отчеты трафика по хостам, портам, протоколам, а также строить графики
2010-01-23, gonzo111
squid+sams+sqstat
Пилим squid и sams - примеры конфигов с объяснениями. Установка SqStat.
2009-12-19, schizoid
mpd5 + radius + ng_car + Abills
Настройка pppoe-сервера с биллинговой системой Abills и шейпером ng_car
2009-11-16, lissyara
UFS->ZFS
Удалённая миграция с UFS на ZFS. Загрузка с раздела zfs. Настройка для работы с малым количеством памяти под архитектурой i386.
2009-11-13, gx_ua
fusefs-ntfs
Установка, настройка и использование fusefs-ntfs, драйвер NTFS, предназанченного для монтирования NTFS разделов под FreeBSD
2009-11-12, Morty
LiveCD
Создание собственного LiveCD с необходимыми вам изменениями, автоматизирование данного процесса, а так же вариант скоростной сборки СД.
2009-09-27, lissyara
Samba как PDC
Контроллер домена - аналог M$ NT4 домена под самбой, без использования LDAP и прочей хиромантии. Просто и быстро =)
2009-08-30, terminus
ipfw nat
Подробное руководство по ipfw nat, сложные случаи конфигурации.
2009-08-24, levantuev
HotSpot
Установка Hotspot системы в общественное заведение.
2009-08-18, lissyara
diskless
Создание бездисковых терминалов под управлением FreeBSD - с загрузкой по сети. Используются для старта rdesktop и подключения к виндовому серверу терминалов.
2009-07-29, BAV_Lug
Видеонаблюдение
Настройка бюджетного варианта видеонаблюдения на удаленном объекте
2009-07-22, Cancer
OpenLDAP адресная книга
Настройка и создание адресной книги на базе OpenLDAP + phpLDAPadmin
2009-06-30, SergeySL
AimSniff
Руководство по созданию системы мониторинга ICQ-переписки на базе AimSniff, использующей базу данных MySQL для хранения и Web-интерфейс WAS (Web Aim Sniff) для просмотра перехваченных сообщений
2009-06-25, atrium
Управление правами доступа
Полномочия пользователей и файлов, принадлежащих им, формирует концепцию ОС UNIX.
2009-06-16, DNK
Exim+PgSQL
Установка почтовой системы exim+pgsql на FreeBSD 7.1
2009-05-30, mvalery
HDD(mbr) -> HDD(gpt)
Как разбить диск размером более 2TB на разделы, сделать загрузочным, а затем перенести на него информацию с рабочей системы — донора.
2009-05-22, Cancer
SendXMPP
Отправка сообщений на Джаббер сервер по средствам SendXMPP
2009-05-11, Raven2000
Network UPS Tools
Network UPS Tools представляет собой набор программ, которые обеспечивают общий
интерфейс для мониторинга и администрирование UPS оборудования.
2009-04-29, m0ps
IPSEC over GRE with RIP
Пример IPSEC over GRE и динамическим роутингом (RIP), с ADSL в качестве последней мили на оборудовании Cisco.
2009-04-24, WhiteBear777
qemu network
Появилась необходимость поставить на БСД эмулятор(qemu) и настроить в качестве гостевой ОС Windows XP, предоставив ей выход в локалку и в сеть internet...
2009-04-22, vp
freebsd + huawei 162 gsm modem
В статье описывается простой способ подключения модема huawei 162 к freebsd + первичная настройка smstools
2009-04-12, mvalery
Мониторинг RAID
Мониторинг из командной строки RAID компаний AMCC 3ware, HighPoint, Dell (Perc 5/i и PERC 6/i) и LSI (MegaRAID SAS 8408E и SAS1078)
2009-04-09, texnotronic
RAID1 via LAN
Функциональности DRBD во FreeBSD можно добиться примонтировав блочное устройство по сети при помощи GEOM Gate (ggate) и добавив его в зеркало с локальным диском средствами gmirror.
|