 |
|
|
|
|
| WebMoney: WMZ Z294115950220 WMR R409981405661 WME E134003968233 |
Visa 4274 3200 2453 6495 |
|
|
|
|
|
|
| WebMoney: WMZ Z294115950220 WMR R409981405661 WME E134003968233 |
Visa 4274 3200 2453 6495 |
Перевод выполнен Алексеем Паутовым в рамках
некоммерческого проекта RussianLDP
(http://www.rldp.ru/). Именно на этом сайте
и надлежит искать новые версии, если таковые будут.
Exim выполняет различные преобразования адресов
отправителей и получателей всех обрабатываемых сообщений,
и также строк заголовков. Некоторые из них опциональны и могут
конфигурироваться, тогда как другие присутствуют всегда. Вся эта обработка,
исключая перезапиь как результат роутинга, и добавления/удаления строк
заголовков при доставке, происходит при приёме сообщения,
до его помещения в очередь exim.
Часть автоматической обработки по умолчанию
происходит лишь для сгенерированных локально (locally-originated) сообщений.
Это прилагательное используется для описания сообщений которые не были
переданы через TCP/IP, а переданы процессу exim на его стандартный ввод.
Оно включает случай интерактивного локального SMTP, который устанавливается
опцией -bs командной строки.
Отметьте: сообщения, переданные через TCP/IP на кольцевом
интерфейсе (127.0.0.1 или ::1), не рассматриваются как сгенерированные
локально. Exim никогда не обрабатывает особым образом кольцевой интерфейс.
Если Вы хотите обработать кольцевой интерфейс особым образом, то должны
гарантировать, что существуют соответствующие записи в Ваших ACL. Происходящую автоматически обработку для локально
сгенерированных сообщений (если не установлена опция
suppress_local_fixups) также можно затребовать для сообщений,
полученных по TCP/IP. Термин "режим передачи" (submission mode)
используется для описания этого состояния. Режим передачи устанавливается
при помощи модификатора:
Есть некоторые опции, которые могут использоваться
когда установлен режим передачи. Слэш используется
для разделения опций. Например:
Домен может быть пустым. Как это значение используется,
описано в разделах 43.11 и
разделах 43.16. Также есть опция name,
которая позволяет задать полное имя пользователя для включения в создаваемые
заголовки Sender: и From:. Например:
Поскольку имя может содержать любые символы,
включая слэши, опция name должна быть дана последней.
Оставшаяся строка используется как имя. Для примера выше,
если /etc/exim/namelist содержит:
По умолчанию режим передачи принудительно ставит путь
возврата в тот же адрес, что используется для
создания заголовка Sender:. Однако, если задана sender_retain,
путь возврата также остаётся неизменным.
Отметьте: изменения, вызванные режимом передачи,
вступают в силу после ACL перед данными. Это означает, что любые проверки
отправителя, выполненные перед адресными привязками, используют
ненадёжный адрес отправителя, заданный пользователем, а не надёжным адресом
отправителя заданным режимом передачи. Хотя это несколько неожиданно, в
действительности это означает, что Вы можете сконфигурировать проверки ACL
на определение того, что пользователь пробует сфабриковать иной адрес. RFC 2821 задаёт, что CRLF (два символа: возврат каретки,
сопровождаемый переводом строки) определяет конец сообщений,
передаваемых через интернет, используя SMTP через TCP/IP.
Однако, в отдельных операционных системах используются иные соглашения.
Например, UNIX-подобные системы используют лишь LF, но иные используют
CRLF или просто CR.
Exim был разработан для UNIX-подобных систем и внутренне
он сохраняет сообщения, используя системное соглашение единственного LF
как терминатора строк. Получая сообщение, все концы строк переводятся в
этот стандартный формат. Изначально предполагалось, что программы,
передающие сообщения напрямую к MTA внутри операционной системы,
будут использовать системные соглашения. Опыт показал, что это почему-то
далеко не так, например, существуют UNIX-приложения, которые в этом случае
используют пару CRLF. Поэтому и для совместимости с другими MTA способы,
которыми exim обрабатывает концы строк для всех сообщений, на данный момент:
По умолчанию 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. Сообщения приходящие из UUCP (и от некоторых других
приложений), часто начинаются со строки, содержащей отправителя конверта и
штамп времени после слова From. Примеры двух обычных форматов:
Эта строка предшествует строкам заголовков,
соответствующим 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-сообщении от источника,
которму его не разрешено посылать. RFC 2822 создаёт условия для добавления в сообщение строк
заголовков, начинающихся со строки Resent-, когда оно пересылается
оригинальным получателем ещё кому-то. Эти заголовки: Resent-Date:,
Resent-From:, Resent-Sender:, Resent-To:,
Resent-Cc:, Resent-Bcc: и Resent-Message-ID:.
В RFC говорится:
Повторно посланные поля являются строго информационными.
Они НЕ ДОЛЖНЫ использоваться в нормальной обработке ответов
или других подобных автоматических действиях для сообщений.
Этим оставляется несколько неопределённым,
насколько затронуты другие действия обработки, типа перезаписи адресов.
Exim обрабатывает строки заголовков Resent- следующим образом:
Каждый раз, когда exim генерирует автоответ, рикошет
или предупреждающее сообщение о задержке, он включает строку заголовка:
Если exim вызывается с опцией -t,
чтобы получить адреса получателей из заголовков сообщений, он удаляет любые
строки заголовков Bcc:, которые могут существовать
(после извлечения их адресов). Если -t не представлена в командной
строке, любые существующие Bcc: не удаляются. Если сгенерированное локально сообщение
или сообщение в режиме передачи не имеет заголовка Date:,
exim добавляет один, используя текущую дату и время, если не была
определена опция suppress_local_fixups. Заголовок Delivery-date: не часть стандартного
набора заголовков RFC 2822. Exim может быть сконфигурирован для её добавления
при финальной доставке сообщений. Смотрите общую транспортную опцию
delivery_date_add. Он не должен присутствовать
во время пути сообщения. Если установлена конфигурационная опция
delivery_date_add (по умолчанию), exim удаляет заголовки
Delivery-date: из входящих сообщений. Заголовок Envelope-to: не часть стандартного
набора заголовков RFC 2822. Exim может быть сконфигурирован для её добавления
при финальной доставке сообщений. Смотрите общую транспортную опцию
envelope_to_add. Он не должен присутствовать
во время пути сообщения. Если установлена конфигурационная опция
envelope_to_add (по умолчанию), exim удаляет заголовки
Envelope-to: из входящих сообщений. Если сообщение в режиме передачи не содержит строки
заголовка From:, exim добавляет её, если истинно любое
из следующих условий:
Непустой отправитель конверта обладает приоритетом.
Если входящее локально сгенерированное сообщение не содержит строки заголовка
From:, и настройка suppress_local_fixups не задана,
exim добавляет заголовок, содержащий адрес отправителя.
Логин вызывающего пользователя и его полное имя используются для
конструирования адреса, как описано в разделе
43.8. Оно получаются из данных пароля, путём вызова getpwuid()
(но смотрите конфигурацию unknown_login).
Адрес квалифицируется с qualify_domain.
Для совместимости с sendmail, если приходящее не-SMTP
сообщение содержит строку заголовка From:,
содержащую лишь неквалифицированное имя вызывающего пользователя,
она заменяется адресом, содержащим пользовательский логин и полное имя,
как описано в секции 43.18. Если сгенерированное локально сообщение или сообщение в
режиме передачи не имеет заголовка Message-ID: или
Resent-Message-ID:, и не установлена опция
suppress_local_fixups, exim добавляет подходящий заголовок в сообщение.
Если в сообщении есть любой заголовок Resent-:, он создаёт
Resent-Message-ID:. Идентификатор конструируется из внутренного
идентификатора сообщения exim с предшествующей буквой 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 из RFC 2822 (которая заявляет, что ответы
должны содержать такую строку заголовка), и секции 3.14 из RFC 3834 (которая
заявляет, что автоматические ответы не различаются в этом отношении).
Однако, поскольку некоторый софт обрабатывающий почту, не очень хорошо
справляется с очень длинными строками заголовков, не более, чем 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 не пуста,
адрес отправителя создаётся следующим образом:
Этот адрес сравнивается с адресом в заголовке From:.
Если они различны, добавляется строка Sender:,
содержащая созданный адрес. Префиксы и суффиксы для локальной части в
From: могут быть разрешены путём установки local_from_prefix и
local_from_suffix соответственно.
Отметьте: Каждый раз, когда создаётся заголовок
Sender:, путь возврата сообщения (адрес отправителя конверта)
изменяется на тот же самый адрес, исключая случай в режиме передачи,
когда задана опция sender_retain. Когда сообщение доставляется, дополнение и удаление
строк заголовков может быть задано в системном фильтре или любом роутере и
транспорте, который обрабатывает сообщение. Раздел
42.6 содержит детали о модификации заголовков в системном фильтре.
Строки заголовков также могут быть добавлены в ACL при получении сообщения
(смотрите раздел 39.19).
В отличие от того, что происходит в системном фильтре,
модификация заголовков, заданная в роутерах и транспортах,
применяется лишь к специфическим адресам получателей,
которые обрабатываются этими роутерами и транспортами. Эти изменения не
актуальны, пока копия сообщения не транспортируется. Поэтому, они не
применяются к базовым наборам заголовков и значениям переменных, которые
ссылаются на строки заголовков.
Отметьте:В частности, это означает, что любые
раскрытия в конфигурации транспорта не могут ссылаться на модифицированные
строки заголовков, поскольку эти раскрытия происходят до
реальной транспортировки сообщения.
Для роутеров и транспортов результат раскрытия опции
headers_add должен быть одной или более строкой заголовков,
в соответствии с RFC 2822, разделённых новой строкой (код \n). Например:
Exim не проверяет синтаксис этих добавляемых заголовков.
Результат раскрытия headers_remove должен состоять из
списка имён заголовков, разделённых двоеточиями.
Это может запутывать, поскольку имена заголовков сами по
себе завершаются двоеточием. В этом случае двоеточие представляет
собой разделитель списка, а не часть имени. Например:
Когда headers_add и headers_remove
заданы в роутере, их значения раскрываются во время роутинга, и затем
ассоциируются с каждым адресом, который принимается роутером, а также с любым
новым адресом, который им генерируется. Если адрес передаётся через несколько
роутеров, как результат алиасинга или форвардинга, изменения кумулятивные.
Однако, это не применяется к нескольким роутерам, как
результату использования опции unseen. Любые модификации заголовков,
заданные путём роутера unseen или его предшественников,
применяются лишь к доставке unseen.
Адреса, которые заканчиваются различными установками
headers_add или headers_remove, не могут быть
доставлены вместе в пакете, таким образом, транспорт всегда имеет дело с
рядом адресов, которые имеют те же самые требования к обработке заголовков.
Транспортировка начинается с записи оригинального набора
заголовков прибывшего с сообщением, возможно, модифицированного системным
фильтром. При выписке этих строк exim консультируется со списком имён
заголовков, которые добавлены адресам получателей путём опции
headers_remove в роутере, и также консультируется с транспортной
опцией headers_remove. Строки заголовков, чьи имена находятся в одном
из этих списков, не выписываются. Если есть несколько любых перечисленных
заголовков, все они пропускаются.
После записи оставшихся строк оригинальных заголовков,
записываются новые строки заголовков, которые заданы опцией роутеров
headers_add, в порядке как они были добавлены к адресам.
Они сопровождаются любыми строками заголовков,
заданными транспортной опцией headers_add.
Этот способ обработки модификации заголовоков в
роутерах и транспортах имеет следующие последствия:
Предупреждение: Опции headers_add и
headers_remove не могут использоваться в роутере redirect,
в котором установлена опция one_time. Когда exim создаёт адрес отправителя для локально
сгенерированных сообщений, он использует форму:
Например:
Имя пользователя получается из установки -F
командной строки (если установлено) или путём поиска вызвавшего пользователя
getpwuid() и извлечения поля gecos из вхождения пароля.
Если поле gecos содержит символ &, он заменяется на логин с первой буквой
в верхнем регистре, как обычно во множестве операционных систем.
Смотрите опцию gecos_name для способа приспособить
обработку поля gecos. Опция unknown_username может использоваться для
задания имени пользователя в случаях, когда в файле паролей нет вхождения.
Во всех случаях имя пользователя должно соответствовать
RFC 2822 путём квотирования всего или частей, по необходимости. Кроме того,
если оно содержит любые непечатаемые символы, оно кодируется, как описано в
RFC 2047, определяющим способ включения не-ASCII символов в строки заголовков.
Значение опции headers_charset задаёт имя кодирования,
которое используется (символы, как предполагается, в этой кодировке).
Установка print_topbitchars контролирует,
считать ли символы с установленным высшим битом
(с кодами больше 127) как печатные символы или нет. RFC 2822 устанавливает, что регистр букв в локальных
частях не может предполагаться незначающим. Exim сохраняет регистр локальных
частей адресов, но по умолчанию он использует форму в нижнам регистре при
роутинге, поскольку на большинстве UNIX-систем имена пользователей в нижнем
регистре и требуется нечувствительный к регистру роутинг.
Однако, любой специфический роутер можно заставить использовать оригинальный
регистр для локальных частей путём установки общей опции роутеров
caseful_local_part. Если Вам необходимо иметь имена пользователей
в смешанном регистре на Вашей системе, лучшим способом перейти, предполагая,
что Вы хотите регистронезависимую обработку входящей почты, установить Ваш
первый роутер на преобразование входящих локальных частей в Ваших доменах в
корректный регистр путём поиска по файлу. Например:
Для этого роутера локальная часть приводится к
нижнему регистру путём действия по умолчанию
(caseful_local_part не установлена).
Локальная часть в нижнем регистре используется для поиска новой локальной
части в корректном регистре. Тогда, если Вы установите
caseful_local_part в любом последующем роутере,
обрабатывающем Ваши домены, они будут оперировать локальными частями в
корректном регистре, в регистрозависимой манере. RFC 2822 запрещает пустые компоненты в локальных частях.
Таким образом, неквотированная локальная часть не может начинаться или
заканчиваться точкой или иметь две точки подряд в середине.
Однако, кажется, многие MTA не принуждают к этому, таким образом,
exim разрешает пустые компоненты для совместимости. Перезапись адресов отправителей и получателей и адресов
в заголовках может происходить автоматически или как результат
конфигурационных опций, как описано в части 31.
Заголовки, которые могут быть этим затронуты: Bcc:, Cc:,
From:, Reply-To:, Sender: и To:.
Автоматическая перезапись включает перезапись, как указано выше.
Другой случай, в котором это может случиться: когда дан
неполный нелокальный домен. Процесс маршрутизации может вызвать
его раскрытие в полное доменное имя. Например, заголовок типа:
Перезапись как результат маршрутизации один из видов
обработки сообщений, которые не происходят во время прихода сообщения,
так как она не может быть сделана до роутинга адреса.
Строго говоря, нельзя производить никакие доставки
сообщения, пока все адреса не будут смаршрутизированы в случае,
если любой заголовок был изменён в результате роутинга.
Однако, выполнение этого практически задержало бы много доставок на
чрезмерное время лишь потому, что один адрес не мог быть немедленно
смаршрутизирован. Поэтому exim не задерживает другие доставки,
когда задерживается маршрутизация одного или более адресов.
43. Обработка сообщения
43.1. Режим передачи для нелокальных сообщений
в MAIL, RCPT или ACL до данных для входящего собщения (смотрите
разделы 39.17 и
разделы 39.18). Он заставляет exim обработать сообщение как переданное
локально и обычно используется, когда источник сообщения известен как MUA,
работающий на клиентском хосте (в противовположность MTA).
Например, для установки режима передачи для сообщений,
приходящих на IPv4-кольцевом интерфейсе, Вы могли включить
следующее в MAIL ACL:
control = submission
warn hosts = 127.0.0.1
control = submission
control = submission/sender_retain
accept authenticated = *
control = submission/domain=wonderland.example/ \
name=${lookup {$authenticated_id} \
lsearch {/etc/exim/namelist}}
когда отправитель аутентифицирован как bigegg,
сгенерированная строка Sender: была бы:
bigegg: Humpty Dumpty
Sender: Humpty Dumpty <bigegg@wonderland.example>
43.2. Завершения строк
43.3. Неквалифицированные адреса
43.4. Строка From UUCP
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
43.5. Строки заголовков Resent-
43.6. Строка заголовка Auto-Submitted:
Auto-Submitted: auto-replied
43.7. Строка заголовка Bcc:
43.8. Строка заголовка Date:
43.9. Строка заголовка Delivery-date:
43.10. Строка заголовка Envelope-to:
43.11. Строка заголовка From:
43.12. Строка заголовка Message-ID:
43.13. Строка заголовка Received:
43.14. Строка заголовка References:
43.15. Строка заголовка Return-path:
43.16. Строка заголовка Sender:
43.17. Добавление и удаление заголовков в роутерах и транспортах
headers_add = X-added-header: added by $primary_hostname\n\
X-added-second: another added header line
headers_remove = return-receipt-to:acknowledge-to
headers_remove = subject
headers_add = Subject: new subject (was: $h_subject:)
43.18. Конструирование адресов
<user name> <login@qualify_domain>
Zaphod Beeblebrox <zaphod@end.univ.example>
43.19. Регистры локальных частей
correct_case:
driver = redirect
domains = +local_domains
data = ${lookup{$local_part}cdb \
{/etc/usercased.cdb}{$value}fail} @$domain
43.20. Точки в локальных частях
43.21. Перезапись адресов
мог быть перезаписан как:
To: hare@teaparty
To: hare@teaparty.wonderland.fict.example
| Найди своих коллег! |