RussianLDP Рейтинг@Mail.ru
WebMoney: 
WMZ Z294115950220 
WMR R409981405661 
WME E134003968233 
Visa 
4274 3200 2453 6495 

Перевод выполнен Алексеем Паутовым в рамках некоммерческого проекта RussianLDP (http://www.rldp.ru/). Именно на этом сайте и надлежит искать новые версии, если таковые будут.

43. Обработка сообщения

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

Часть автоматической обработки по умолчанию происходит лишь для сгенерированных локально (locally-originated) сообщений. Это прилагательное используется для описания сообщений которые не были переданы через TCP/IP, а переданы процессу exim на его стандартный ввод. Оно включает случай интерактивного локального SMTP, который устанавливается опцией -bs командной строки.

Отметьте: сообщения, переданные через TCP/IP на кольцевом интерфейсе (127.0.0.1 или ::1), не рассматриваются как сгенерированные локально. Exim никогда не обрабатывает особым образом кольцевой интерфейс. Если Вы хотите обработать кольцевой интерфейс особым образом, то должны гарантировать, что существуют соответствующие записи в Ваших ACL.

43.1. Режим передачи для нелокальных сообщений

Происходящую автоматически обработку для локально сгенерированных сообщений (если не установлена опция suppress_local_fixups) также можно затребовать для сообщений, полученных по TCP/IP. Термин "режим передачи" (submission mode) используется для описания этого состояния. Режим передачи устанавливается при помощи модификатора:
control = submission
в MAIL, RCPT или ACL до данных для входящего собщения (смотрите разделы 39.17 и разделы 39.18). Он заставляет exim обработать сообщение как переданное локально и обычно используется, когда источник сообщения известен как MUA, работающий на клиентском хосте (в противовположность MTA). Например, для установки режима передачи для сообщений, приходящих на IPv4-кольцевом интерфейсе, Вы могли включить следующее в MAIL ACL:
warn hosts = 127.0.0.1
     control = submission

Есть некоторые опции, которые могут использоваться когда установлен режим передачи. Слэш используется для разделения опций. Например:
control = submission/sender_retain

Домен может быть пустым. Как это значение используется, описано в разделах 43.11 и разделах 43.16. Также есть опция name, которая позволяет задать полное имя пользователя для включения в создаваемые заголовки Sender: и From:. Например:
accept authenticated = *
       control = submission/domain=wonderland.example/ \
                 name=${lookup {$authenticated_id} \
                                lsearch {/etc/exim/namelist}}

Поскольку имя может содержать любые символы, включая слэши, опция name должна быть дана последней. Оставшаяся строка используется как имя. Для примера выше, если /etc/exim/namelist содержит:
bigegg: Humpty Dumpty
когда отправитель аутентифицирован как bigegg, сгенерированная строка Sender: была бы:
Sender: Humpty Dumpty <bigegg@wonderland.example>

По умолчанию режим передачи принудительно ставит путь возврата в тот же адрес, что используется для создания заголовка Sender:. Однако, если задана sender_retain, путь возврата также остаётся неизменным.

Отметьте: изменения, вызванные режимом передачи, вступают в силу после ACL перед данными. Это означает, что любые проверки отправителя, выполненные перед адресными привязками, используют ненадёжный адрес отправителя, заданный пользователем, а не надёжным адресом отправителя заданным режимом передачи. Хотя это несколько неожиданно, в действительности это означает, что Вы можете сконфигурировать проверки ACL на определение того, что пользователь пробует сфабриковать иной адрес.

43.2. Завершения строк

RFC 2821 задаёт, что CRLF (два символа: возврат каретки, сопровождаемый переводом строки) определяет конец сообщений, передаваемых через интернет, используя SMTP через TCP/IP. Однако, в отдельных операционных системах используются иные соглашения. Например, UNIX-подобные системы используют лишь LF, но иные используют CRLF или просто CR.

Exim был разработан для UNIX-подобных систем и внутренне он сохраняет сообщения, используя системное соглашение единственного LF как терминатора строк. Получая сообщение, все концы строк переводятся в этот стандартный формат. Изначально предполагалось, что программы, передающие сообщения напрямую к MTA внутри операционной системы, будут использовать системные соглашения. Опыт показал, что это почему-то далеко не так, например, существуют UNIX-приложения, которые в этом случае используют пару CRLF. Поэтому и для совместимости с другими MTA способы, которыми exim обрабатывает концы строк для всех сообщений, на данный момент:

  • LF, которму не предшествовал CR, обрабатывается как завершение строки.
  • CR обрабатывается как конец строки, если сразу за ним идёт LF, то LF игнорируется.
  • Последовательность CR, точка, CR не завершает входящее SMTP-сообщение, а также локальное сообщение в случае, когда строка, содержащая лишь точку, является терминатором.
  • Если в стрке заголовка найден лишь CR, после завершения строки добавляется дополнительное пустое пространство, чтобы не завершить строку заголовка. Рассуждения таковы, что пустые CR в заголовках, наиболее вероятно, ошибки или люди, пробующие игоать в глупые игры.
  • Если первая строка заголовка в сообщении завершается CRLF, последуюшие пустые LF в строке заголовка обрабатывается точно так же, как и пустой CR в строке заголовка.

43.3. Неквалифицированные адреса

По умолчанию exim ожидает, что каждый, получаемый с внешнего хоста, адрес конверта будет полностью квалифицирован (с доменным именем). Неквалифицированные адреса вызывают отрицательные ответы на команды SMTP. Однако, поскольку SMTP используется как средство транспортировки сообщений от MUA, работающих на персональных рабочих станциях, иногда требуется принимать неквалифицированные адреса от специфических хостов или IP-сетей.

У exim есть две опции, которые раздельно управляют тем, какие хосты могут посылать неквалифицированные адреса отправителей или получателей в SMTP-командах, именуемые sender_unqualified_hosts и recipient_unqualified_hosts. В обоих случаях, если принимаются неквалифицированные адреса, они квалифицируются путём добавления значения qualify_domain или qualify_recipient, соответственно.

Неквалифицированные адреса в строках заголовков автоматически квалифицируются для сгенерированных локально сообщений, если в командной строке не дана опция -bnq. Для сообщений, принятых по SMTP, неквалифицированные адреса в заголовках квалифицируются, лишь если в SMTP-командах разрешены неквалифицированные адреса. Другими словами, этой квалификацией также управляют путём sender_unqualified_hosts и recipient_unqualified_hosts.

43.4. Строка From UUCP

Сообщения приходящие из UUCP (и от некоторых других приложений), часто начинаются со строки, содержащей отправителя конверта и штамп времени после слова From. Примеры двух обычных форматов:
From a.oakley@berlin.mus Fri Jan  5 12:35 GMT 1996
From f.butler@berlin.mus Fri, 7 Jan 97 14:00:00 GMT

Эта строка предшествует строкам заголовков, соответствующим RFC 2822. Для совместимости с sendmail exim распознаёт такие строки как начало сообщения, переданного через командную строку (то есть, на стандартном вводе). Он не распознаёт такие строки во входящих сообщениях, если посылающий хост не совпадает с ignore_fromline_hosts или не использовалась опция -bs для локального сообщения при установленной ignore_fromline_hosts. Распознание управляется регулярным выражением, которое задано опцией uucp_from_pattern, чьё значение по умолчанию совпадает с двумя частыми случаями, показанными выше, и помещает адреса, следующие за From, в $1.

Когда пользователь, вызывающий exim для не-SMTP сообщения содержащего строку From, является доверенным, адрес отправителя сообщения конструируется путём раскрытия содержимого uucp_sender_address, чьё значение по умолчанию $1. Затем оно разбирается как адрес по RFC 2822. Если в нём нет домена, локальная часть квалифицируется с qualify_domain, если оно не пустая строка. Однако, если используется опция командной строки -f, она перезадаёт строку From.

Если exim вызывает не доверенный пользователь, строка From распознаётся, но адрес отправителя не изменяется. Для входящих SMTP-сообщений с разрешённой строкой From применяется этот же случай. Распознаётся лишь одна строка From. Если их больше одной, вторая обрабатывается как строка данных, которая начинает тело сообщения, поскольку она не допустимая строка заголовка. Также это происходит, если строка From представлена во входящем SMTP-сообщении от источника, которму его не разрешено посылать.

43.5. Строки заголовков Resent-

RFC 2822 создаёт условия для добавления в сообщение строк заголовков, начинающихся со строки Resent-, когда оно пересылается оригинальным получателем ещё кому-то. Эти заголовки: Resent-Date:, Resent-From:, Resent-Sender:, Resent-To:, Resent-Cc:, Resent-Bcc: и Resent-Message-ID:. В RFC говорится:

Повторно посланные поля являются строго информационными. Они НЕ ДОЛЖНЫ использоваться в нормальной обработке ответов или других подобных автоматических действиях для сообщений.

Этим оставляется несколько неопределённым, насколько затронуты другие действия обработки, типа перезаписи адресов. Exim обрабатывает строки заголовков Resent- следующим образом:

  • Строка Resent-From: содержит лишь логин передающего пользователя и автоматически перезаписывается точно таким же способом, как From: (смотрите ниже).
  • Если есть правило перезаписи для специфической строки заголовка, оно также применяется к заголовку Resent- того же типа. Например, правило, перезаписывающее From:, также перезапишет Resent-From:.
  • Для локальных сообщений если из ввода удалён Sender:, также удаляется и Resent-Sender:.
  • Для локально переданных сообщений если есть какая-либо строка заголовка Resent-, но нет Resent-Date:, Resent-From: или Resent-Message-Id:, они добавляются по мере необходимости. Это содержимое Resent-Message-Id: (а не Message-Id:!), которое включается в строки протоколов в этом случае.
  • Логика для добавления Sender:: дублируется для Resent-Sender:, когда присутствует любой заголовок Resent-.

43.6. Строка заголовка Auto-Submitted:

Каждый раз, когда exim генерирует автоответ, рикошет или предупреждающее сообщение о задержке, он включает строку заголовка:
Auto-Submitted: auto-replied

43.7. Строка заголовка Bcc:

Если exim вызывается с опцией -t, чтобы получить адреса получателей из заголовков сообщений, он удаляет любые строки заголовков Bcc:, которые могут существовать (после извлечения их адресов). Если -t не представлена в командной строке, любые существующие Bcc: не удаляются.

43.8. Строка заголовка Date:

Если сгенерированное локально сообщение или сообщение в режиме передачи не имеет заголовка Date:, exim добавляет один, используя текущую дату и время, если не была определена опция suppress_local_fixups.

43.9. Строка заголовка Delivery-date:

Заголовок Delivery-date: не часть стандартного набора заголовков RFC 2822. Exim может быть сконфигурирован для её добавления при финальной доставке сообщений. Смотрите общую транспортную опцию delivery_date_add. Он не должен присутствовать во время пути сообщения. Если установлена конфигурационная опция delivery_date_add (по умолчанию), exim удаляет заголовки Delivery-date: из входящих сообщений.

43.10. Строка заголовка Envelope-to:

Заголовок Envelope-to: не часть стандартного набора заголовков RFC 2822. Exim может быть сконфигурирован для её добавления при финальной доставке сообщений. Смотрите общую транспортную опцию envelope_to_add. Он не должен присутствовать во время пути сообщения. Если установлена конфигурационная опция envelope_to_add (по умолчанию), exim удаляет заголовки Envelope-to: из входящих сообщений.

43.11. Строка заголовка From:

Если сообщение в режиме передачи не содержит строки заголовка From:, exim добавляет её, если истинно любое из следующих условий:

  • Адрес отправителя конверта не пуст (это не рикошет). Добавляемая строка заголовка копирует адрес отправителя конверта.
  • Сессия SMTP аутентифицирована, и $authenticated_id не пуст:
    • 1. Если нет домена, заданного управлением передачей, локальная часть: $authenticated_id, домен: $qualify_domain.
    • 2. Если непустой домен задан путём управления передачей, локальная часть: $authenticated_id, домен: заданный домен.
    • 3. Если управлением передачей задан пустой домен, предполагается, что в $authenticated_id полный адрес.

Непустой отправитель конверта обладает приоритетом. Если входящее локально сгенерированное сообщение не содержит строки заголовка From:, и настройка suppress_local_fixups не задана, exim добавляет заголовок, содержащий адрес отправителя. Логин вызывающего пользователя и его полное имя используются для конструирования адреса, как описано в разделе 43.8. Оно получаются из данных пароля, путём вызова getpwuid() (но смотрите конфигурацию unknown_login). Адрес квалифицируется с qualify_domain.

Для совместимости с sendmail, если приходящее не-SMTP сообщение содержит строку заголовка From:, содержащую лишь неквалифицированное имя вызывающего пользователя, она заменяется адресом, содержащим пользовательский логин и полное имя, как описано в секции 43.18.

43.12. Строка заголовка Message-ID:

Если сгенерированное локально сообщение или сообщение в режиме передачи не имеет заголовка Message-ID: или Resent-Message-ID:, и не установлена опция suppress_local_fixups, exim добавляет подходящий заголовок в сообщение. Если в сообщении есть любой заголовок Resent-:, он создаёт Resent-Message-ID:. Идентификатор конструируется из внутренного идентификатора сообщения exim с предшествующей буквой E для гарантии, что он всегда начинается с буквы, сопровождается @ и первичным именем хоста. Дополнительная информация может быть включена в эту строку заголовка путём установки опций message_id_header_text и/или message_id_header_domain.

43.13. Строка заголовка Received:

Строка заголовка Received: добавляется в начале каждого сообщения. Содержимое определяется путём конфигурационной опции received_header_text, а exim автоматически добавляет точку с запятой и штамп времени в сконфигурированную строку.

Заголовок Received: генерируется как только приходит строка заголовка сообщения. На этом этапе метка времени в заголовке Received: означает время начала приёма сообщения. Это значение то, которое замечено ACL DATA и функцией local_scan().

Как только сообщение принято, временная метка в заголовке Received: изменяется на время приёма, которое является (кроме маленькой задержки на запись -H файла в спул) наименьшим временем, когда могла начаться доставка.

43.14. Строка заголовка References:

Сообщения, созданные транспортом autoreply, включают заголовок References:. Он создаётся согласно правилам, которые описаны в секции 3.64 из RFC 2822 (которая заявляет, что ответы должны содержать такую строку заголовка), и секции 3.14 из RFC 3834 (которая заявляет, что автоматические ответы не различаются в этом отношении). Однако, поскольку некоторый софт обрабатывающий почту, не очень хорошо справляется с очень длинными строками заголовков, не более, чем 12 идентификаторов сообщений копируются из строки заголовка References: входящего сообщения. Если их больше 12-ти, копируются первый и последующие 11 до добавления идентификатора сообщения для входящего сообщения.

43.15. Строка заголовка Return-path:

Заголовок Return-path: задан как нечто, что MTA может вставить, когда производит финальную доставку сообщения. Смотрите общую транспортную опцию return_path_add. Поэтому, они не должны быть в сообщениях, которые находятся в пути. Если установлена конфигурационная опция return_path_remove (по умолчанию установлена), exim удаляет заголовки Return-path: из входящих сообщений.

43.16. Строка заголовка Sender:

Для локально сгенерированных сообщений от недоверенных пользователей exim может удалять существующий заголовок Sender: и может добавлять новый. Вы можете модифицироать эти действия путём установки опции local_sender_retain в истину, local_from_check в ложь, или используя установку suppress_local_fixups.

Когда локальное сообщение принимается от недоверенного пользователя, а local_from_check истинна (по умолчанию), и не установлена suppress_local_fixups, производится проверка, что адрес, данный в заголовке From:, корректный (локальный) отправитель сообщения. Ожидаемый адрес имеет логин пользователя как локальную часть и значение qualify_domain как доменную. Префиксы и суффиксы для локальных частей могут быть разрешены путём установки local_from_prefix и local_from_suffix, соответственно. Если From: не содержит корректного отправителя, к сообщению добавляется строка Sender:.

Если Вы установите local_from_check в ложь, этой проверки не произойдёт. Однако, всё ещё происходит удаление существующей строки Sender:, если Вы не установили в истину local_sender_retain. Невозможно одновременно установить в истину эти две опции.

По умолчанию для сообщений, полученных по TCP/IP, или для сообщений, посланных доверенными пользователями, не производится обработка заголовка Sender:. Однако, когда сообщение посылается через TCP/IP в режиме передачи, и для управления передачей не задана sender_retain, происходит следующая обработка:

Вначале удаляются любые существующие строки Sender:. Затем, если сессия SMTP аутентифицирована, и $authenticated_id не пуста, адрес отправителя создаётся следующим образом:

  • Если управлением передачей не задан домен, локальная часть: $authenticated_id, домен: $qualify_domain.
  • Если настройками режима передачи задан непустой домен, локальная часть: $authenticated_id, домен: заданный домен.
  • Если настройками режима передачи задан пустой домен, $authenticated_id считается полным адресом.

Этот адрес сравнивается с адресом в заголовке From:. Если они различны, добавляется строка Sender:, содержащая созданный адрес. Префиксы и суффиксы для локальной части в From: могут быть разрешены путём установки local_from_prefix и local_from_suffix соответственно.

Отметьте: Каждый раз, когда создаётся заголовок Sender:, путь возврата сообщения (адрес отправителя конверта) изменяется на тот же самый адрес, исключая случай в режиме передачи, когда задана опция sender_retain.

43.17. Добавление и удаление заголовков в роутерах и транспортах

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

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

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

Для роутеров и транспортов результат раскрытия опции headers_add должен быть одной или более строкой заголовков, в соответствии с RFC 2822, разделённых новой строкой (код \n). Например:
headers_add = X-added-header: added by $primary_hostname\n\
              X-added-second: another added header line

Exim не проверяет синтаксис этих добавляемых заголовков. Результат раскрытия headers_remove должен состоять из списка имён заголовков, разделённых двоеточиями. Это может запутывать, поскольку имена заголовков сами по себе завершаются двоеточием. В этом случае двоеточие представляет собой разделитель списка, а не часть имени. Например:
headers_remove = return-receipt-to:acknowledge-to

Когда headers_add и headers_remove заданы в роутере, их значения раскрываются во время роутинга, и затем ассоциируются с каждым адресом, который принимается роутером, а также с любым новым адресом, который им генерируется. Если адрес передаётся через несколько роутеров, как результат алиасинга или форвардинга, изменения кумулятивные.

Однако, это не применяется к нескольким роутерам, как результату использования опции unseen. Любые модификации заголовков, заданные путём роутера unseen или его предшественников, применяются лишь к доставке unseen.

Адреса, которые заканчиваются различными установками headers_add или headers_remove, не могут быть доставлены вместе в пакете, таким образом, транспорт всегда имеет дело с рядом адресов, которые имеют те же самые требования к обработке заголовков.

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

После записи оставшихся строк оригинальных заголовков, записываются новые строки заголовков, которые заданы опцией роутеров headers_add, в порядке как они были добавлены к адресам. Они сопровождаются любыми строками заголовков, заданными транспортной опцией headers_add.

Этот способ обработки модификации заголовоков в роутерах и транспортах имеет следующие последствия:

  • Оригинальный набор заголовков, возможно, модифицированных системным фильтром, остаётся видимым в том смысле, что переменные $header_xxx продолжают на них ссылаться всё время.
  • Строки заголовков, которые добавлены опцией headers_add роутера, недоступны посредством синтаксиса раскрытия $header_xxx в последующих роутерах или транспортах.
  • Наоборот, строки заголовков, которые определены на удаление путём headers_remove в роутере, остаются видимы в последующих роутерах и транспортах.
  • Заголовки, добавленные к адресу путём headers_add в роутере, не могут быть удалены путём последующих роутеров или транспортами.
  • Добавленные заголовки могут ссылаться на содержимое оригинальных заголовков, которые должны быть удалены, даже если он имеет то же самое имя, как и добавляемый заголовок. Например:
    headers_remove = subject
    headers_add = Subject: new subject (was: $h_subject:)
    

Предупреждение: Опции headers_add и headers_remove не могут использоваться в роутере redirect, в котором установлена опция one_time.

43.18. Конструирование адресов

Когда exim создаёт адрес отправителя для локально сгенерированных сообщений, он использует форму:
<user name> <login@qualify_domain>

Например:
Zaphod Beeblebrox <zaphod@end.univ.example>

Имя пользователя получается из установки -F командной строки (если установлено) или путём поиска вызвавшего пользователя getpwuid() и извлечения поля gecos из вхождения пароля. Если поле gecos содержит символ &, он заменяется на логин с первой буквой в верхнем регистре, как обычно во множестве операционных систем. Смотрите опцию gecos_name для способа приспособить обработку поля gecos. Опция unknown_username может использоваться для задания имени пользователя в случаях, когда в файле паролей нет вхождения.

Во всех случаях имя пользователя должно соответствовать RFC 2822 путём квотирования всего или частей, по необходимости. Кроме того, если оно содержит любые непечатаемые символы, оно кодируется, как описано в RFC 2047, определяющим способ включения не-ASCII символов в строки заголовков. Значение опции headers_charset задаёт имя кодирования, которое используется (символы, как предполагается, в этой кодировке). Установка print_topbitchars контролирует, считать ли символы с установленным высшим битом (с кодами больше 127) как печатные символы или нет.

43.19. Регистры локальных частей

RFC 2822 устанавливает, что регистр букв в локальных частях не может предполагаться незначающим. Exim сохраняет регистр локальных частей адресов, но по умолчанию он использует форму в нижнам регистре при роутинге, поскольку на большинстве UNIX-систем имена пользователей в нижнем регистре и требуется нечувствительный к регистру роутинг. Однако, любой специфический роутер можно заставить использовать оригинальный регистр для локальных частей путём установки общей опции роутеров caseful_local_part. Если Вам необходимо иметь имена пользователей в смешанном регистре на Вашей системе, лучшим способом перейти, предполагая, что Вы хотите регистронезависимую обработку входящей почты, установить Ваш первый роутер на преобразование входящих локальных частей в Ваших доменах в корректный регистр путём поиска по файлу. Например:
correct_case:
  driver = redirect
  domains = +local_domains
  data = ${lookup{$local_part}cdb \
              {/etc/usercased.cdb}{$value}fail} @$domain

Для этого роутера локальная часть приводится к нижнему регистру путём действия по умолчанию (caseful_local_part не установлена). Локальная часть в нижнем регистре используется для поиска новой локальной части в корректном регистре. Тогда, если Вы установите caseful_local_part в любом последующем роутере, обрабатывающем Ваши домены, они будут оперировать локальными частями в корректном регистре, в регистрозависимой манере.

43.20. Точки в локальных частях

RFC 2822 запрещает пустые компоненты в локальных частях. Таким образом, неквотированная локальная часть не может начинаться или заканчиваться точкой или иметь две точки подряд в середине. Однако, кажется, многие MTA не принуждают к этому, таким образом, exim разрешает пустые компоненты для совместимости.

43.21. Перезапись адресов

Перезапись адресов отправителей и получателей и адресов в заголовках может происходить автоматически или как результат конфигурационных опций, как описано в части 31. Заголовки, которые могут быть этим затронуты: Bcc:, Cc:, From:, Reply-To:, Sender: и To:. Автоматическая перезапись включает перезапись, как указано выше. Другой случай, в котором это может случиться: когда дан неполный нелокальный домен. Процесс маршрутизации может вызвать его раскрытие в полное доменное имя. Например, заголовок типа:
To: hare@teaparty
мог быть перезаписан как:
To: hare@teaparty.wonderland.fict.example

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

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

Поиск

 

Найди своих коллег!