Мы — долго запрягаем, быстро ездим, и сильно тормозим.
www.lissyara.su —> документация —> EXIM —> 4.70 —> часть 44

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


    Exim выполняет различные преобразования адресов отправителей и получателей для всех обрабатываемых сообщений, и, также, строк заголовков. Некоторые из них - опциональны и могут конфигурироваться, тогда как другие присутствуют всегда. Вся эта обработка, исключая перезапиь как результат роутинга, и добавления/удаления строк заголовков при доставке, происходит при приёме сообщения, до его помещения в очередь exim'a.
   Часть автоматической обработки, по умолчанию, происходит лишь для
сгенерированных локально (locally-originated) сообщений. Это прилагательное используется для описания сообщений которые не были переданы через TCP/IP, а переданы процессу exim'a на его стандартный ввод. Оно включает случай интерактивного локального SMTP, который устанавливается опцией -bs, командной строки.
   Отметьте: Сообщения переданные через TCP/IP на интерфейсе обратной петли (127.0.0.1 или ::1), не рассматриваются как сгенерированные локально. Exim никогда не обрабатывает особым образом интерфейс локальной петли.
   Если вы хотите обработать интерфейс локальной петли особым образом, вы должны гарантировать, что существуют соответствующие записи в ваших ACL.

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

   Происходящую автоматически обработку для локально сгенерированных сообщений (если не установлена опция suppress_local_fixups), также можно затребовать для сообщений полученных по TCP/IP. Термин режим передачи (submission mode) используется для описания этого состояния. Режим передачи устанавливается при помощи модификатора
control = submission

в MAIL, RCPT, или ACL до данных, для входящего собщения (смотрите разделы 40.19 и 40.20). Он заставляет exim обработать сообщение как переданное локально, и, обычно, используется для когда источник сообщения известен как MUA, работающий на клиентском хосте (в противовположность MTA). Например, для установки режима передачи для сообщений приходящих на IPv4 интерфейсе обратной петли, вы могли включить следующее в MAIL ACL:
warn  hosts = 127.0.0.1
      control = submission

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

   Указание sender_retain имеет эффект установки опций local_sender_retain равной true и local_from_check равной false для текущего входящего сообщения. Первая из них позволяет сохранять существующий заголовок Sender:, вторая опция подавляет проверку заголовка From: на соответствие с аутентифицированным пользователем. С этой опцией Exim по прежнему добавляет до сообщения заголовки Date: и Message-ID:, если они отсутствуют, но не пробует проверить отправителя из строк заголовка.
Когда
sender_retain не установлен, настройки режима передачи могут задавать домен, который будет использоваться при создании заголовов From: или Sender:. Например:
control = submission/domain=some.domain

   Домен может быть пустым. Как это значение используется - описано в разделах 44.11 и 44.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 на определение что пользователь пробует сфабриковать иной адрес.

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

   RFC2821 задаёт, что 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 в строке заголовка.

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

       По умолчанию, exim ожидает, что каждый, получаемый с внешнего хоста, адрес конверта, будет полностью квалифицирован (с доменным именем). Неквалифицированные адреса вызывают отрицательные ответы на команды SMTP. Однако, поскольку SMTP используется для как средство транспортировки сообщений от MUA работающих на персональных рабочих станциях, иногда требуется принимать неквалифицированные адреса от специфических хостов или IP-сетей.
       У exim'a есть две опции, которые раздельно управляют тем, какие хосты могут посылать неквалифицированные адреса отправителей или получателей в SMTP-командах, именуемые
    sender_unqualified_hosts и recipient_unqualified_hosts. В обоих случаях, если принимаются неквалифицированные адреса, они квалифицируются путём добавления значения qualify_domain или qualify_recipient, соответственно.
       Неквалифицированные адреса в строках заголовков, автоматически квалифицируются для сгенерённых локально сообщений, если в командной строке не дана опция
    -bnq. Для сообщений принятых по SMTP, неквалифицированные адреса, в заголовках, квалифицируются лишь если в SMTP-командах разрешены неквалифицированные адреса. Другими словами, этой квалификацией также управляют путём sender_unqualified_hosts и recipient_unqualified_hosts.

    44.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
    

       Эта строка предшествует строкам заголовков, соответствующим RFC2822. Для совместимости с sendmail, exim распознаёт такие строки как начало сообщения переданного через командную строку (т.е. на стандартном вводе). Он не распознаёт такие строки во входящих сообщениях, если посылающий хост не совпадает с ignore_fromline_hosts, или не использовалась опция -bs длч локального сообщения, при установленной ignore_fromline_hosts. Распознание управляется регулярным выражением, которое задано опцией uucp_from_pattern, чьё дефолтовое значение совпадает с двумя частыми случаями, показанными выше, и помещает адреса следующие за From в $1.
       Когда пользователь, вызывающий exim для не-SMTP сообщения содержащего строку
    From - доверенный пользователь, адрес отправителя сообщения конструируется путём раскрытия содержимого uucp_sender_address, чьё дефолтовое значение - $1. Затем оно разбирается как адрес по RFC2822. Если в нём нет домена, локальная часть квалифицируется с qualify_domain, если оно - не пустая строка. Однако, если используется опция командной строки -f, она перезадаёт строку From.
       Если exim вызывает не доверенный пользователь, строка
    From распознаётся, но адрес отправителя не изменяется. Для входящих SMTP сообщений с разрешённой строкой From, применяется этот же случай.
       Распознаётся лишь одна строка
    From. Если их больше одной, вторая обрабатывается как строка данных, которая начинает тело сообщения, поскольку она - не допустимая строка заголовка. Также это происходит если строка From представлена во входящем SMTP-сообщении от источника, которму его не разрешено посылать.

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

       RFC2822 создаёт условия для добавления в сообщение строк заголовков начинающихся со строки 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-.

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

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

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

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

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

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

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

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

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

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

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

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

  • Адрес отправителя конверта не пуст (т.е. это - не рикошет). Добавляемая строка заголовка копирует адрес отправителя конверта.
  • Сессия SMTP аутентифицирована, и $authenticated_id - не пуст.
    1. Если нет домена, заданного управлением передачей, локальная часть -
    $authenticated_id, и домен - $qualify_domain.
    2. Если непустой домен задан путём управления передачей, локальная часть -
    $authenticated_id, и домен - заданный домен.
    3. Если управлением передачей задан пустой домен, предполагается, что в
    $authenticated_id - полный адрес.
       Непустой отправитель конверта обладает приоритетом.
       Если входящее, локально сгенерённое сообщение не содержит строки заголовка
    From:, и настройка suppress_local_fixups не задана, exim добавляет заголовок содержащий адрес отправителя. Логин вызывающего пользователя и его полное имя используются для конструирования адреса, как описано в секции 44.18. Оно получаются из данных пароля, путём вызова getpwuid() (но, смотрите конфигурацию unknown_login). Адрес квалифицируется с qualify_domain.
       Для совместимости с sendmail, если приходящее не-SMTP сообщение содержит строку заголовка
    From:, содержащую лишь неквалифицированное имя вызывающего пользователя, она заменяется адресом, содержащим пользовательский логин и полное имя, как описано в секции 44.18.

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

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

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

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

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

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

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

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

    44.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.

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

       Когда сообщение доставляется, дополнение и удаление строк заголовков может быть задано в системном фильтре, или любом роутере и транспорте, который обрабатывает сообщение. Раздел 43.6 содержит детали о модификации заголовков в системном фильтре. Строки заголовков, также могут быть добавлены в ACL, при получении сообщения (смотрите раздел 40.22).
       В отличие от того, что происходит в системном фильтре, модификация заголовков заданная в роутерах и транспортах применяется лишь к специфическим адресам получателей, которые обрабатываются этими роутерами и транспортами. Эти изменения не актуальны, пока копия сообщения не транспортируется. Поэтому, они не применяются к базовым наборам заголовков, и они не применяются к значениям переменных, которые ссылаются на строки заголовков.
       Отметьте:  В частности, это означает, что любые раскрытия в конфигурации транспорта не могут ссылаться на модифицированные строки заголовков, поскольку эти раскрытия происходят до реальной транспортировки сообщения.
       Для обоих, роутеров и транспортов, результат раскрытия опции
    headers_add должен быть одной или более строкой заголовков, в соответствии с RFC2822, разделённых новой строкой (код - \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.

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

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

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

       Имя пользователя получается из установки -F командной строки (если установлено), или, иначе, путём поиска вызвавшего пользователя getpwuid() и извлечения поля gecos из вхождения пароля. Если поле gecos содержит символ &, он заменяется на логин с первой буквой в верхнем регистре, как обычно во множестве операционных систем. Смотрите опцию gecos_name для способа приспособить обработку поля gecos. Опция unknown_username может использоваться для задания имени пользователя в случаях, когда в файле паролей нет вхождения.
       Во всех случаях, имя пользователя должно соответствовать RFC2822 путём квотирования всего, или частей, по необходимости. Кроме того, если оно содержит любые непечатаемые символы, оно кодируется как описано в RFC2047, определяющем способ включения не-ASCII символов в строки заголовков. Значение опции
    headers_charset задаёт имя кодирования, которое используется (символы, как предполагается, в этой кодировке). Установка print_topbitchars контролирует, считать ли символы с установленным высшим битом (т.е., с кодами больше 127) как печатные символы, или нет.

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

       RFC2822 устанавливает, что регистр букв в локальных частях не может предполагаться незначащим. 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 в любом последующем роутере, обрабатывающем ваши домены, то они будут оперировать локальными частями в корректном регистре, в регистрозависимой манере.

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

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

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

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

    мог быть перезаписан как
    To: hare@teaparty.wonderland.fict.example
    

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


    =============
    translated by lissyara
    verifying by Gerk





  •  

      Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
      Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

    © lissyara 2006-10-24 08:47 MSK

    Время генерации страницы 0.0621 секунд
    Из них PHP: 29%; SQL: 71%; Число SQL-запросов: 65 шт.
    Исходный размер: 81031; Сжатая: 16556