[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Электронная почта" / Оглавление документа

46. Некоторые общие конфигурационые опции

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



   Если вы хотите отсылать всю почту для нелокальных доменов на “умный хост” (“smart host”), вы должны заменить дефолтовый роутер “ dnslookup ”, на роутер явно задающий роутинг:


send_to_smart_host: driver = manualroute route_list = !+local_domains smart.host.name transport = remote_smtp

   Если необходимо, вы можете использовать IP адрес умного хоста, вместо имени. Если вы используете exim лишь для передачи сообщений на умный хост, а не для получения входящих сообщений, вы должны принять меры для синхронизации подачи, путём установки опции “ mua_wrapper ” (смотрите главу 47).



   Exim может быть использован для запуска простого списка рассылки, но для больших и/или сложных требований, рекомендуется использование дополнительного ПО для управления списками рассылки, типа Majordomo или Mailman.
   Роутер “ redirect ” может быть использован для обработки списков рассылки, где каждый список поддерживается в отдельном файле, который, поэтому, может управляться независмыми манагерами. Опция “ domains ”, роутера, может использоваться для запуска этих списков в отдельных доменах, от нормальной почты. Например:


lists: driver = redirect domains = lists.example file = /usr/lists/$local_part forbid_pipe forbid_file errors_to = $local_part[email protected] no_more

   Этот роутер пропущен для доменов, иных нежели “ lists.example ”. Для адресов в этих доменах, он ищет файл, совпадающий с локальной частью. Если файла нет, роутер не выполняется, но, поскольку установлена “ no_more ”, последующие роутеры не проверяются, и вся доставка заканчивается неудачей.
   Опции “ forbid_pipe ” и “ forbid_file ” предотвращают раскрытие локальной части в доставку в трубу или файл, которая, обычно, неуместна в списках рассылки.
   Опция “ errors_to ” задаёт, что любые ошибки доставки, вызыванные адресами взятыми из списка рассылки, должны быть отосланы на заданный адрес, а не оригинальному отправителю сообщения. Однако, до этого действия, exim проверяет ошибочный адрес, и игнорирует, если его проверка неудачна.
   Например, используя конфигурацию выше, почта посланная на “ [email protected] ” - передаётся на адреса содержащиеся в “ /usr/lists/dicts ”, с направлением сообщений о ошибках на  “ [email protected] ”, при условии, что этот адрес может быть проверен. Также возможно, что тут мог бы быть файл с именем “ /usr/lists/dicts-request ”, содержащий адрес(а) манагер(a|ов) данного специфического списка, но иным подходом, типа установки более раннего роутера (возможно, использующего опции “ local_part_prefix ” или “ local_part_suffix ”) для обработки адресов в форме “ owner-xxx ” или “ xxx-request ”.



   Если вхождение в данных перенаправления содержит синтаксическую ошибку, exim, обычно, задерживает доставку оригинального адреса. Это означает, что ошибка синтаксиса, в списке рассылки, задержит все доставки на этот список. Это может быть неподходящим, когда список обслуживается автоматически, из данных предоставленных пользователями, и адреса не проверены строго.
   Если установлена опция “ skip_syntax_errors ”, роутер “ redirect ” просто пропускает вхождения, которые неможет распарсить, отмечая инцидент в логах. Если, дополнительно, “ syntax_errors_to ” установлена в адрес который можно проверить, сообщение посылается на него при каждом пропуске битого адреса. Обычно, “ syntax_errors_to ” устнавливается в тот же адрес, что и “ errors_to ”.



   Exim запоминает каждый индивидуальный адрес, на который было доставлено сообщение, для избежания дублирования, но, обычно, он сохраняет лишь оригинальный адрес получателя, сообщения. Если все доставки на список рассылки не могут быть завершены в первую попытку, список рассылки раскрывается повторно, когда происходит следующая попытка доставки. Это означает, что изменения списка примаются во внимание при каждой попытке доставки, таким образом, адреса, которые были добавлены к списку с того времени как пришло сообщение, также получат копию сообщения, несмотря на то, что оно предшествовало их подписке.
   Если такое поведение - нежелательно, в роутере “ redirect ” может быть установлена опция “ one_time ”. Если это сделано, любые сгенерированные роутером адреса, которые не удалось доставить при первой попытке, добавляются к сообщению как “верхний уровень” (“top level”) адресов, и, сгенеривший их родительский адрес, помечается как “доставленный” (“delivered”). Таким образом, раскрытие списков рассылки не происходит заново, в последующие попытки доставки. Неудобство этого, в том, что если любой неудачный адрес - некоректен, его исправление в файле не имеет эффекта для предыдущих сообщений.
   Оригинальный адрес высшего уровня запоминается с каждым сгенерированным адресом, и выводится в логах. Однако, любые промежуточные родительские адреса - не записываются. Это делает различие для логов лишь если установлен селектор “ all_parents ”, но, так или иначе, для списков рассылки обычен лишь один уровень раскрытия.



   Примеры, пока, предполагали открытые списки рассылки, в которые любой может послать почту. Также возможно настроить закрытые списки, где почта принимается лишь от специфических отправителей. Это производится путём использования общей опции “ senders ”, для ограничения роутера обрабатывающего список.
   Следующий пример использует один и тот же файл как список получателей, и как список разрешённых отправителей. Он требует трёх роутеров:


lists_request: driver = redirect domains = lists.example local_part_suffix = -request file = /usr/lists/$local_part $local_part_suffix no_more lists_post: driver = redirect domains = lists.example senders = ${if exists {/usr/lists/$local_part}\ {lsearch;/usr/lists/$local_part}{*}} file = /usr/lists/$local_part forbid_pipe forbid_file errors_to = $local_part[email protected] no_more lists_closed: driver = redirect domains = lists.example allow_fail data = :fail: $local_part@lists.example is a closed mailing list

   Все три роутера имеют одну и ту же установку “ domains ”, таким образом, для любых других доменов, они пропущены. Первый роутер запускается лишь если локальная часть завершается на “ -request ”. Он обрабатывает сообщения к манагер(у|ам) списка, путём открытого списка рассылки.
   Второй роутер запускается лишь если удовлетворено предварительное условие “ senders ”. Он проверяет существование списка соответствующего локальной части, и, затем, с помошью линейного поиска проверяет, что отправитель находится в списке. До попытки поиска по файлу, необходимо проверить его существование, поскольку иначе exim подумает, что произошла конфигурационная ошибка. Если файл не существует, раскрытие “ senders ” приводит к “*”, что соответствует всем отправителям. Это означает, что роутер работает, но, поскольку нет списка, от него отказываются, и “ no_more ” гарантирует, что дальнейшие роутеры  не запускаются. Адрес неудачен с ошибкой “unrouteable address”.
   Третий роутер запускатся лишь если второй роутер пропущен, что происходит когда список рассылки существует, но отправитель не в нём. Этот роутер принудительно создаёт неудачу адреса, давая подходящее сообщение о ошибке.



   Variable Envelope Return Paths - смотрите http://cr.yp.to/proto/verp.txt - являются способом помочь администраторам списков рассылок обнаружить, какой адрес подписки является причиной специфической неудачи доставки. Идея - в кодировании оригинального получателя адреса в исходящем адресе отправителя конверта, таким образом, если сообщение форвардится путём другого хоста, и, впоследствии, создаётся рикошет, оригинальный получатель может быть извлечён из адреса получателя рикошета.
   Адрес отправителя конверта может быть модифицирован exim`ом используя два различных средства: опцию “ errors_to ” в роутере (как показано в предыдущих примерах списков рассылки), или транспортную опцию “ return_path ”. Второй из них эффективен лишь если сообщение успешно доставлено не иной хост; она не используется, для ошибок детектируемых на локальном хосте (смотрите описание “ return_path ”в части 24). Вот - пример использования “ return_path ” для осуществления VERP в транспорте “ smtp ”:


verp_smtp: driver = smtp max_rcpt = 1 return_path = \ ${if match {$return_path}{^(.+?)[email protected]\$}\ {$1-request=$local_part%$domain@your.dom.example}fail}

   Он имеет эффект перезаписи обратного пути (отправителя конверта) в исходящих SMTP сообщениях, если локальная часть оригинального получателя завершается на “-request”, и домен - “ your.dom.example ”. Перезапись вставляет локальную часть и домен получателя в путь возврата. Предположим, например, что сообщение, чей путь возврата установлен в “ [email protected] ” - посылается на “ [email protected] ”. В транспорте, путь возврата переписывается как:


somelist-request=subscriber%[email protected]

   Чтобы это работало, вы, также, должны сделать, чтобы исходящие сообщения, которые имеют в своём пути возврата “-request”, имели лишь одного получателя. Это достигается путём установки “ max_rcpt ” в 1. Без этого, одна копия сообщения может быть послана нескольким различным получателям в одном домене, когда “ $local_part ” недоступна в транспорте, поскольку она не уникальна.
   Если ваш хост не только производит доставки списков рассылки, вы, вероятно, должны использовать отдельный транспорт для доставок VERP, чтобы не использовать дополнительные ресурсы для других. Это легко может быть сделано путём раскрытия опции “ transport ” в роутере:


dnslookup: driver = dnslookup domains = ! +local_domains transport = \ ${if match {$return_path}{^(.+?)[email protected]\$}\ {verp_smtp}{remote_smtp}} no_more

   Если вы хотите изменить путь возврата используя “ errors_to ” в роутере, вместо использования “ return_path ” в транспорте, вам необходимо установить “ errors_to ” во всех роутерах которые обрабатывают адреса списков рассылок. Это будет гарантировать, что все ошибки доставки, включая детектируемые на локальном хосте, посылаются на адреса VERP.
   На хосте, который не делает локальных доставок, и не имет ручного роутинга, в изменении нуждается лишь роутер “ dnslookup ”. Для доставко SMTP не нужен специальный транспорт. Каждый получатель списка рассылки имеет свой собственный путь возврата, и, таким образом, exim должен передать их транспорту по одному. Вот - пример роутера “ dnslookup ”, который осуществляет VERP:


verp_dnslookup: driver = dnslookup domains = ! +local_domains transport = remote_smtp errors_to = \ ${if match {$return_path}{^(.+?)[email protected]\$}} {$1-request=$local_part%$domain@your.dom.example}fail} no_more

   До того, как вы начнёте рассылать сообщения с VERP путём возврата, вы, также, должны сконфигурировать exim на приём рикошетов, которые возвращаются с таким путём. Обычно, это производится путём установки опции “ local_part_suffix ” для роутера, и использования этого для роутинга сообщения туда, где вы его хотели бы обработать.
   Накладные расходы, при использовании VERP, очень сильно зависят от размера сообщения, числа получателей адресов, которые резольвятся на один и тот же удалённый хост, и скорости соединения, через которое посылается сообщение. Если много адресов резольвятся на один и тот же хост, и соединение медленное, посылка отдельной копии сообщения для каждого адреса может быть существенно дольше, чем посылка одной копии сообщения с многими получателями (что не может быть использоваться с VERP).



   Фраза “ virtual domain ”, к сожалению, используется для двух различных смыслов:


virtual:
  driver = redirect
  domains = dsearch;/etc/mail/virtual
  data = ${lookup{
$local_part}lsearch{/etc/mail/virtual/$domain}}
  no_more

spqr, vacation-spqr

Общая опция роутеров, “ require_files ”, может использоваться для вызова доставки отпуска (:) - прим. lissyara), путём проверки существования определённого файла в домашнем каталоге пользователя. Также должна использоваться общая опция “ unseen ”, для гарантии, что произойдёт оригинальная доставка. В этом случае, все использующие это пользователи, должны создать файл, называемый, скажем “ .vacation ”, содержащий сообщение о отпуске.
   Другое преимущество обоих этих методов состоит в том, что они оба работают даже когда пользователям запрещено использование произвольных труб.

46.10 Отбор копий сообщений

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



46.11 Периодически подключенные хосты

   Для хостов, стало весьма обычным (опскольку дешевле), подключаться к интернету периодически, а не всё время быть подключенными. Обычная настройка для таких хостов - что поста для них накапливается на системе постоянно соединенённой с интернетом.
   Exim был разработан для использованя на постоянно подключенных хостах, и, таким образом, не особенно подходит для использования на периодически подключаемых хостах. Однако, есть особенности, которые могут использоваться.



46.12 Exim на вышестоящих серверных хостах

   Exim принимает меры, чтобы входящая почта для периодически подключаемых хостов оставалася в очереди exim`a, пока клиент не подключится. Однако, этот подход не очень хорошо масштабируется. Два различных вида ожидания сообщения смешиваются в одной очереди - те, которые нельзя доставить из-за каких-то вреемнных проблем, и тех, которые ждут соединения их хоста предназначения. Это делает тяжёлым управление очередью, так же как и растрату ресурсов, поскольку каждый обработчик очереди сканирует всю очередь.
   Лучший подход состоит в отделении тех сообщений, которые ждут временно подключаемых хостов. Это может быть сделано путём доставки этих сообщений в локальные файлы пакетного SMTP, “mailstore”, или иной формат сохраняющий конверт, из которого они передаются путём иного программного обеспечения к их месту назначения. Это облегчает сборку всей почты для одного хоста в одной директории, и применения правил локального таймаута на основании сообщений, если требуется.
   Для очень небольшого масштаба, можно сделать чтобы exim оставлял почту в очереди. Если вы это делаете, вы должны сконфигурировать exim с длинным периодом повтора для временно подключенных хостов. Например:


cheshire.wonderland.fict.example * F,5d,24h

   Этим останавливается множество неудачных попыток доставки, но exim запоминает какие сообщения находились в очереди для этого хоста. Как только непостоянный хост появляется в сети, принудительная доставка одного сообщения (или используя опции “ -M ” или “ -R ”, или путём использования команды ETRN SMTP (смотрите раздел 44.8)) вызывает доставку всех находящихся в очереди сообщений, часто - по одному соединению. Когда хост остаётся на связи, любые новые сообщения доставляются немедленно.
   Если подключающиеся хосты не имеют фиксированного IP-адреса, т.е. хост появляется каждый раз с различным IP-адресом, механизмы повтора на хосте-владельце (почты - прим. lissyara) запутываются, поскольку IP-адрес, обычно, используется как часть ключевой строки для информации повторов. Этого можно избежать, путём сброса “ retry_include_ip_address ” в “ smtp ” транспорте. Так как это неудобно для хостов постоянно связанных с интернет, для периодически связанных хостов лучше организовать отдельный транспорт.



46.13 Exim на периодически подключаемом клиентском хосте

   Значение “ smtp_accept_queue_per_connection ”, вероятно, должно быть увеличено, или даже установленов  ноль (т.е. отключено) на периодически подключаемых хостах, для того, чтобы все входящие сообщения немедленно отсылались по одному соединению.
   Почта ожидающая отсылки с периодически подключаемого хоста, вероятно, не будет роутится, поскольку без соединения с DNS, поиски невозможны. Это означает, что нормальная обработка очереди завершаетс за время соединения, каждое сообщение, вероятно, будет отправлено в отдельной SMTP-сессии. Этого можно избежать, путём запуска обработки очереди с опциями командной строки, начинающимися с “ -qq ” вместо “ -q ”. В этом случае, очередь сканируется дважды. В первый проход, завершается роутинг, но доставки не происходит. Во второй проход - нормальная обработка очереди; так как все сообщения предварительно были сроучены, то предназначенные для одного и того же хоста, вероятно, будут отосланы в одном SMTP соединении.




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




Партнёры:

Хостинг:

Закладки на сайте Проследить за страницей

Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру