По умолчанию, 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 ”.



   Сообщения приходящие из UUCP (и некоторых других приложений), часто, начинаются со строки содержащей отправителя конверта и штамп времени, после слова “From”. Примеры двух обычных форматов:


From [email protected] Fri Jan 5 12 : 35 GMT 1996 From [email protected] 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-сообщении от источника, которму его не разрешено посылать.



   RFC2822 создаёт условия для добавления в сообщение строк заголовков начинающихся со строки “Resent-”, когда оно пересылается оригинальным получателем ещё кому-то. Эти заголовки - “ Resent-Date: ”, “ Resent-From: ”, “ Resent-Sender: ”, “ Resent-To: ”, “ Resent-Cc: ”, “ Resent-Bcc: ” и “ Resent-Message-ID: ”. В RFC говорится:
   Повторно посланные поля являются строго информационными. Они НЕ ДОЛЖНЫ использоваться в нормальной обработке ответов, или других подобных автоматических действиях для сообщений.
   Этим оставляются несколько неопределённым, насколько затронуты другие действия обработки, типа перезаписи адресов. Exim обрабатывает строки заголовков “ Resent- ” следующим образом:


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


Auto-Submitted: auto-replied

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



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



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



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



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


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



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



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



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



   Для локально сгенерённых сообщений от недоверенных пользователей, 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 ” непуста, адрес отправителя создаётся следующим образом:


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


headers_remove = subject
headers_add = Subject: new subject (was: $h_subject:)

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



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


<user name> <login@qualify_domain>

   Например:


Zaphod Beeblebrox <[email protected]>

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



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



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



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


To: hare@teaparty

мог быть перезаписан как


To: [email protected]

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




=============
Автор перевода: lissyara, оригинал: http://www.lissyara.su/?id=1200




Партнёры:

Хостинг: