24. Общие опции для транспортов

    Следующие общие опции применяются ко всем транспортам:



   Если эта опция установлена, заголовки сообщения не транспортируются. Эта опция взаимоисключаяющая с “ headers_only ”. Если она используется с транспортом “ appendfile ” или “ pipe ”, должны быть проверены установки “ message_prefix ” и “ message_suffix ”, поскольку эта опция не подавляет их автоматически.



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



   Если эта опция установлена в истину, ничего не логгируется ни для каких доставок транспортом, и никаие ошибки в логи не пишутся. Вы не должны устанавливать эту опцию, если не понимаете что делаете.



   Если эта опция установлена и отладка включена (смотрите опцию командной строки “ -d ”), строка раскрывается и включается в отладочный вывод, при работе транспорта. Если раскрытие строки неудачно, сообщение о ошибке пишется в отладочный вывод, и exim продолжает обработку. Это средство предоставлено для помощи при проверке значений переменных и т.п. при отладке конфигурации драйвера. Например, если некорректно работает опция “ headers_add ”, “ debug_print ” может быть использована для вывода зависимых переменных. В текст добавляется символ новой строки, если он им не заканчивается.



   Если эта опция истинна, в сообщение добавляется заголовок “ Delivery-date: ”. Это даёт актуальное время, когда призошла доставка. Это не стандартный заголовок, у exim`a есть конфигурационная опция (“ delivery_date_remove ”), запрашивающая его удаление из из входящих сообщений, таким образом, доставленные сообщения можно безопасно пересылать другим получателям.



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



   Если эта опция истинна, в сообщение добавляется заголовок “ Envelope-to: ”. Этим даётся оригинальный адрес (или адреса) во входящем конверте, который вызвал эту доставку. Может быть представлено более одного адреса, если транспорт сконфигурирован для обработки сразу нескольких адресов, или к одному финальному адресу было переадресовано более одного адреса. Это не стандартный заголовок, у exim`a есть конфигурационная опция (“ envelope_to_remove ”), запрашивающая его удаление из из входящих сообщений, таким образом, доставленные сообщения можно безопасно пересылать другим получателям.



   Эта опция задаёт gid для выполнения транспортного процесса, перезадавая любое значение переданное из роутера, и, также, перезадавая любое значение ассоциированное с “ user ” (смотрите ниже).



   Эта опция определяет строку текста, который раскрывается и добавляется в заголовочную часть сообщения при транспортировке, как описано в разделе 43.17. Также, дополнительные строки заголовков, могут быть заданы роутерами. Если результат раскрытия - пустая строка, или раскрытие принудительно неудачно - никаких действий не предпринимается. Другие ошибки раскрытия обрабатываются как ошибки, и вызывают задержку доставки.



   Если эта опция установлена, тело сообщения не транспортируется. Эта опция взаимоисключаема с “ body_only ”. Если она используется с транспортом “ appendfile ” или “ pipe ”, должны быть проверены установки “ message_prefix ” и “ message_suffix ”, поскольку эта опция не подавляет их автоматически.



   Эта опция определяет строку текста, который раскрывается в список имён заголовков; эти заголовки опускаются (они в нём остаются, но при передаче сообщения далее они не передаются - прим. lissyara) из сообщения при транспортировке, как описано в разделе 43.17. Также, удаление заголовка, может быть задано роутером. Если результат раскрытия - пустая строка, или раскрытие принудительно неудачно - никаких действий не предпринимается. Другие ошибки раскрытия обрабатываются как ошибки, и вызывают задержку доставки.



   Эта опция позволяет перезаписывать адреса в строках заголовков во время транспортировки, т.е. когда сообщение копируется в его местоназаначение. Содержимое опции - список правил перезаписи, разделённых двоеточиями. Каждое правило - в той же самое форме, что и общие правила перезаписи применяемые при передаче сообщения. Они описаны в разделе 31. Например,


headers_rewrite = a@b c@d f : \
                  x@y w@z

заменит “a@b” на “c@d” в строке заголовка “ From: ”, и “x@y” на “w@z” - во всех строках заголовков содержащих адрес. Правила применяются к строкам заголовков сразу перед их передачей при транспортировке, таким образом, они затрагивают лишь те копии сообщений, которые проходят через транспорт. Однако, перезаписываются лишь оригинальные строки заголовков, и те, которые были добавлены системным фильтром. Если роутер или транспорт добавляет строки заголовков, они не затрагиваются этой опцией. Эти правила перезаписи не применяются к конверту. Вы можете изменить обратный путь используя опцию “ return_path ”, но в этот момент обработки сообщения вы не можете изменить получателей конверта.



   Эта опция определяет установку домашней директории для локального транспорта, перезадавая любое значение, которое может быть установлено роутером. Домашняя директория помещается в “ $home ”, при раскрытии частных опций транспорта. Она также используется как текущая директория, если текущая директория не установлена в транспорте опцией “ current_directory ”, или опцией роутера “ transport_current_directory ”. Если раскрытие неудачно по какой-либо причине, включая принудительную неудачу, ошибка логгируется, и доставка задерживается.



   Если эта опция истинна, и uid процесса доставки предоставлен транспортом, при работе транспорта вызывается функция “ initgroups() ”, для гарантии, что любые группы, связянные с uid установлены.



   Эта опция контролирует размер сообщений, проходящих через транспорт. Она раскрывается до использования; результат раскрытия должен быть последовательностью цифр, опционально сопровождаемых “K” или “M”. Если раскрытие неудачно по какой-либо причине, включая принудительную неудачу, или результат не имеет необходимую форму (не цифры, или вообще левая строка текста - прим. lissyara), доставка задерживается. Если значение больше нуля, и размер сообщения больше этого значения, адрес неудачен. Если есть какой-то шанс, что результирующий рикошет будет маршрутизирован на тот же самый транспорт, вы должны гарантировать, что “ return_size_limit ” меньше чем “ message_size_limit ” транспорта, иначе будет невозможно доставить рикошет.



   Когда эта опция ложна (по умолчанию), и адрес, имевший любые аффиксы (преффиксы или суффиксы) удалённые из локальной части, доставляется любой формой SMTP или LMTP, аффиксы не включаются. Например, если роутер содержит


local_part_prefix = *-

маршрутизирует адрес “abc-xyz@some.domain” на SMTP-транспорт, конверт доставляется с


RCPT TO:<xyz@some.domain>

   Это также происходт, когда во время ACL для проверки адреса получателя используется обратный вызов. Однако, если “ rcpt_include_affixes ” установлена в истину, в команду RCPT включается полная локальная часть. Эта опция применяется к доставкам BSMTP через транспорты “ appendfile ” и “ pipe ”, также как и к транспортам “ lmtp ” и “ smtp ”.



   Когда происходит временная ошибка доставки, в БД подсказок exim`a создаётся отчёт повтора. Для удалённых доставок, ключ для записи повтора основан на имени и/или IP-адресе хоста вызывашего ошибку. Для локальных доставок, ключ, обычно, - весь адрес, включая локальную часть и домен. Это подходит для большинства общих случаев временных ошибок локальной доставки - например, превышение квоты почтового ящика, должно вызывать задержку доставки лишь в почтовый ящик с превышением, а не на весь домен.
   Однако, в некоторых специальных случаях, у вас может возникнуть необходимость обработать локальную ошибку доставки как ассоциированную с доменом, а не со специфической локальной частью. (Например, если вы храните всю почту какого-то домена в файлах.) Вы можете это сделать путём установки “ retry_use_local_part ” в ложь.
   Для всех локальных транспортов, его дефолтовое значение - истина. Для удалённых транспортов, значение по умолчанию - ложь, в целях опрятности, но изменение значения не оказывает никакого эффекта на удалённый транспорт, в текущей реализации (имеется ввиду, что в будущих релизах exim`a, она чё-то будет делать - прим. lissyara).



   Если эта опция задана, строка раскрывается во время транспортировки, и заменяет значение существующего обратного пути (отправителя конверта), в копии доставляемого сообщения. Пустой путь возврата допускается. Эта возможность спроектирована для удалённых доставко, где значение этой опции используется в команде SMTP MAIL. Если вы установите “ return_path ” для локального транспорта, будет единственный эффект - измениться адрес, помещаемый в строку заголовка “ Return-path: ”, если она добавляется к сообщению (смотрите следующую опцию).
   Раскрытие может обратиться к существующиму значению через “ $return_path ”. Оно является отправителем конверта сообщения, или адресом, установленным опцией роутера “ errors_to ”. Если раскрытие принудительно неудачно, замена не происходит; если неудача по другой причине, доставка задерживается. Эта опция может использоваться для поддержки VERP (Variable Envelope Return Paths) (переменные пути возврата конверта) - смотрите раздел 46.6.
   Отметтьте: Если ошибка доставки детектируется локально, включая случай, когда удалённый сервер отклоняет сообщение во время SMTP диалога, рикошет не посылается по значению этой опции. Он шлётся по ранее установленному адресу для ошибок. Это дефолтовое значение для входящих адресов отправителя, но оно может быть изменено путём опции “ errors_to ” в роутере.



   Если эта опция истинна, к сообщению добавляется заголовок “ Return-path: ”. Хотя пути возврата, обычно, доступны в строке преффикса BSD-майлбокса, обычно они не отображаются MUA, и таким образом, пользователь не имеет к ним лёгкого доступа.
   RFC2821 заявляет, что строка заголовка “ Return-path: ” добавляется к сообщению “когда доставляющий SMTP-сервер делает финальную доставку”. Это подразумевает, что этот заголовок не должен содержаться во входящих сообщениях. У exim`a есть конфигурационная опция, “ return_path_remove ”, которая запрашивает удаление этого заголовка из входящих сообщений, таким образом, доставленные сообщения, могут быть безопасно пересланы другим получателям.



   Смотрите ниже, опцию “ shadow_transport ”.



   Локальный транспорт может установить опцию “ shadow_transport ” в имя иного локального транспорта. Удалённые теневые доставки не поддерживаются.
   Каждый раз, когда доставка на главный транспорт успешна, и или незадана опция “ shadow_transport ”, или её раскрытие не приводит к пустой строке, или одной из строк “0” или “no” или “false”, сообщение, также передаётся теневому транспорту, с тем же самым адресом для доставки. Если раскрытие неудачно, никаких действий не предпринимается, исключая принудительное раскрытие, вызывающее запись в лог файл.
   Результат теневого транспорта отбрасывается, и не затрагивает последующую обработку сообщения. Предоставлен лишь один теневой уровень; опция “ shadow_transport ” игнорируется в любом транспорте, выполняемом как теневой. Опции, связянные с выводом из труб (pipe) также игнорируются. Строки логов для успешной доставки имеют в конце добавленный элемент, вида


ST=<shadow transport name>

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



   Эта опция устанавливает процесс фильтрации (в смысле UNIX-шелла) для сообщений, во время транспортировки. Это не должно быть спутано с почтовой фильтрацией устанавливаемой пользователями индивидуально, или через системный фильтр.
   Перед выходом сообщения из транспорта, команда, заданная в “ transport_filter ” запускается в отдельном, параллельном процессе, и всё сообщение целиком, включая строки заголовков, передаётся ему на стандартный ввод (фактически, это делается от третьего процесса, во избежание тупиков). Команда должна быть задана как абсолютный путь.
   Строки сообщения, записываемые в транспортный фильтр, завершаются символом новой строки (“\n”). Сообщение передаётся фильтру до любых SMTP-специфичных обработок, типа преобразования “\n” в “\r\n” и экранирования строк начинающихся с точки, и, также, до любой обработки подразумеваемой параметрами “ check_string ” и “ escape_string ” в транспортах “ appendfile ” или “ pipe ”.
   Стандартные ошибки для процесса фильтра устанавливается в то же самое местоназначение, что и стандартный вывод; они читаются и пишутся в окончательное местоназаначение сообщения. Процесс, который пишет сообщение в фильтр, сам фильтр, и оригинальный процесс, читающий результат и доставляюший его, работают параллельно, как передача через трубы (pipeline) шелла.
   Фильтр может выполнить любые преобразования, какие захочет, но, разумеется, необходимо позаботится о том, чтобы не нарушить синтаксис RFC2822. Демонстрационный скрипт на perl находится в “ util/transport-filter.pl ”; он делает несколько произольных модификаций, лишь для того, чтобы показать возможности. Exim не проверяет результат, кроме проверки заключительного символа новой строки, когда используется SMTP. Все сообщения, передаваемые через SMTP, должны завершаться символом новой строки, таким образом, exim подставляет его, при его отсутствии.
   Транспортный фильтр может использоваться для проведения контентного сканирования на основе пользователей (имеется ввиду, что в зависмости от пользователя можно делать разные действия - прим. lissyara) во время доставки, если единственный эффект от сканирования - модификация сообщения. Например, контентное  сканирование может вставлять новую строку заголовка, содержащую очки насчитанные за спам. Это могло бы быть интерпретировано фильром в пользовательском MUA. На данном этапе, невозможно отказаться от сообщения.
   Могут возникнуть проблемы, если фильтр увеличивает размер сообщения, пересылаемого по SMTP соединению. Если принимающий SMTP-сервер указал поддержку параметра SIZE, exim пошлёт размер сообщения в начале SMTP-сессии. Если то, что фактически посылается, значительно больше, сервер может отклонить сообщение. Это могло бы работать, путём установки опции “ size_addition ” в транспорте “ smtp ”, или учитывая дополнения к сообщению, или вообще отключив использование SIZE.
   Значение опции “ transport_filter ” - строка команды для запуска фильтра, веполняемого непосредственно из exim`a, а не из шелла. Строка парсится exim`ом точно таким же образом, как командная строка для транспорта “ pipe ”: exim разбирает её на аргументы, а затем раскрывает каждый параметр отдельно (смотрите раздел 29). Любой вид ошибки раскрытия, вызывает задержку доставки. Специальный параметр - “ $pipe_addresses ” заменяется аргументами, по одному на каждый доставляемый адрес. (Это не идеальное название для этой особенности, но, поскольку оно уже было реализовано для транспорта “ pipe ”, показалось разумным не изменять этого.)
   Когда хост удалённый, доступны переменные раскрытия “ $host ” и “ $host_address ”. Они содержат имя и IP-адрес хоста, на который посылается сообщение. например:


transport_filter = /some/directory/transport-filter.pl \
  $host $host_address $sender_address $pipe_addresses

   Если вы хотите использовать более сложные элементы раскрытия для создания команд транспортного фильтра, возникают две проблемы, обе - вследствие того, что команда разделяется до раскрытия.


transport_filter = '/bin/cmd${if eq{$host}{a.b.c}{1}{2}}'

transport_filter = ${lookup{
$host}lsearch{/some/file}\
                    {$value}{/bin/cat}}

transport_filter = /bin/sh -c ${lookup{
$host}lsearch{/some/file}\
                               {$value}{/bin/cat}}