not
#comment@x.y.z   # but this is a comment

   Указывая имя файла в списке имеет такой эффект как вставка каждой строки файла в качестве элемента в список (пустые строки и комментарии исключаются). Тем не менее есть одно важное отличие: файл читается при каждой обработке списка, таким образом если его содержимое периодически меняется, изменяется и поведение Exim.
   Если имени файла предшествует восклицательный знак значение любых совпадений с файлом инвертируется. Например, если


hold_domains = !/etc/nohold-domains

и файл содержит строки


!a.b.c *.b.c

тогда “a.b.c” будет находится в списке доменов определенных в “hold_domains”, в то время как любой домен совпадающий с “*.b.c” - нет.



   Как будет описанов следующих секциях, поиски могут использоваться в списках, для обеспечения индексированных методов проверки списка членов. Было некоторое количество путанницы о способе работы “lsearch” со списками. Поскольку файл “lsearch” содержит простой текст и сканируется последовательно, то некоторые думают, что в него можно ставить групповые символы и другие переменные шаблоны. Это не так. Ключи в файле “lsearch”, всегда фиксированные строки, также как и для любого другого одноключевого поиска.
   Если вы хотите использовать файл содержащий подстановочные паттерны являющиеся частью списка, просто дайте самостоятельное имя файла, без типа поиска, как описано в предыдущей секции.



   Списоку доменов, хостов, e-mail адресов или локальных частей адреса можно дать название, которое используется для обращения к списку в другом месте конфигурации. Это особенно удобно, если один и тот же список нужно использовать в нескольких различных местах. Например, часто задают спосок доменов называемый “ local_domains ” для всех локальных доменов, обрабатываемых на этой машине, с использованием конфигурационной строки типа:


domainlist local_domains = localhost:my.dom.example

   На именованный список можно ссылаться, давая его имя с предшествующим ему знаком “+”, например, роутер предназначенный для обработки локальных доменов, был бы сконфигурен со строкой:


domains = +local_domains

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


dnslookup: driver = dnslookup domains = ! +local_domains transport = remote_smtp no_more

   Четыре вида именованных списков создаются конфигурационными строками, начинающимися со слов “domainlist”, “hostlist”, “addresslist” или “localpartlist” соответственно. Задаваемые вами списки помещайте после них. Например:


hostlist relay_hosts = 192 . 168 . 23 . 0 / 24 : my.friend.example addresslist bad_senders = cdb;/etc/badsenders

   Именованный список может обращаться к другим именованным спискам:


domainlist dom1 = first.example : second.example domainlist dom2 = +dom1 : third.example domainlist dom3 = fourth.example : +dom2 : fifth.example

   Внимание: Если последний элемент, в списке на который ссылаются, отрицательный (инвертированный), то может быть вовсе не тот эфект, который вы ожидали, поскольку отрицание не передаётся на следующий (болеек высокий) уровень. Например, рассмотрите:


domainlist dom1 = !a.b domainlist dom2 = +dom1 : *.b

   Второй список задан: “или в списке dom1 или *.b”. Первый список задаёт только “не a.b”, таким образом домен “x.y” совпадает с ним. Это означает, что он также соответствует и второму списку. Эффект не такой же как:


domainlist dom2 = !a.b : *.b

что не соответствует “x.y”. Вообще, по возможности, лучше избегать отрицания в списках.
   Именованные списки могут быть выгодны в плане производительности. Когда exim роутит адрес или проверяет входящее сообщение, он кэширует результаты теста именованного списка. Так, если у вас есть такой пункт:


domains = +local_domains

в нескольких маршрутизаторах или нескольких ACL, то фактически, тестируется только в первом. Однако, кэширование работает, лишь если в пределах списка, или любых подсписков, нет раскрытий. Другими словами, кэширование происходит только для списков, про которые известно, что они будут одинаковыми при каждом обращении.
   По умолчанию, могут быть до 16 именованных списков каждого типа. Этот предел может быть увеличен изменением компиляционной переменной. Использование списков хостов и доменов рекомендуется для концепции типа локальных доменов, релейных доменов и релейных хостов. В дефолтовом конфиге так и установлено.



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


ALIST = host1 : host2 auth_advertise_hosts = !ALIST

то оно, вероятно, не будет делать то, что вы хотите, потому что это, то же самое что и


auth_advertise_hosts = !host1 : host2

   Заметтьте, что второе имя хоста не инвертировано. Однако, если вы используете список хостов, и напишете


hostlist alist = host1 : host2 auth_advertise_hosts = ! +alist

то отрицание применяется ко всему списку, и в итоге это эквивалентно


auth_advertise_hosts = !host1 : !host2

   При обработке сообщения exim кэширует результат проверки именованного списка, если есть уверенность, что список статический. Практически, это означает, что кэширование работает только если список не содержит символов “$”, что гарантирует, что список не будет изменяться при раскрытии. Однако, иногда, вы можете иметь раскрываемый список, про который вы знаете, что это в пределах одного сообщения это будет тот же самый список при кажой проверке. Например:


domainlist special_domains = \ ${lookup{ $sender_host_address}cdb{/some/file}}

   Это обеспечивает список доменов, который зависит лишь от IP-адреса хоста отправителя. Если этот список доменов используется неоднократно (например в нескольких строках ACL, или в нескольких роутерах), по дефолту, результат не кэшируется, поскольку exim не знает, что каждую проверку это будет один и тот же список.
   Добавив “_cache” к “domainlist” вы можете сказать exim`y что результат можно кэшировать. Например:


domainlist_cache special_domains = ${lookup{...

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



   Списки доменов содержат паттерны, не совпадающие с почтовыми доменами. Следующие типы элементов могут использоваться в списках доменов:


domains = @mx_any/ignore=
127
.
0
.
0
.
1

   Этот пример совпадает с любым доменом имеющим MX-запись указывающую на один из IP-адресов локальной машины, за исключением 127.0.0.1.
   Список IP-адресов обрабатывается тем же самым кодом, который обрабатывает список хостов, таким образом тут можно писать сети в виде CIDR, и также тут могут находится негативные элементы.
   Поскольку список IP-адресов является подсписком внутри списка доменов, вы должны быть осторожны, при использовании разделителей если тут больше одного адреса. Как и в любом другом списке, дефолтовый разделитель может быть заменён. Таким образом, можно сделать так:


domains = @mx_any/ignore=<; 127 . 0 . 0 . 1 ; 0 . 0 . 0 . 0 : \ an.other.domain : ...

чтобы подсписок использовал в качесте разделителя точку с запятой (“;”). При использовании адресов IPv6, полезно поменять разделитель и для главного списка:


domains = <? @mx_any/ignore=<; 127 . 0 . 0 . 1 ;:: 1 ? \ an.other.domain ? ...

domains = cdb;/etc/mail/local_domains.cdb

   Соответсвующий тип поиска производится по файлу, с использованием доменного имени как ключа. В большинстве случаев, данные которые ищутся не нужны, exim`а интересует лишь есть или нет ключ в файле. Однако, при использовании поиска для опции “domains” в роутере или “domains” кондишене ACL, данные сохраняются в переменной “ $domain_data ” и могут быть использованы в других опциях роутера или в утверждениях, в той же самой ACL.


domains = partial-dbm;/partial/domains

   Это вызывает частично-соответсвующую логику; описание как это работает, дано в секции 9.7.


hold_domains = mysql;select domain from holdlist \
		where domain = '$domain';

   В большинстве случаев, данные поиска не используются (так, для SQL-запроса, к примеру, не имеет значения выбираемое поле). Exim интересуется лишь тем, успешен запрос или нет. Однако, при использовании поиска в опции “domains” в роутере, данные содраняются в переменной “ $domain_data ” и могут быть использованы в других опциях.


domainlist funny_domains = \
		@ : \
		lib.unseen.edu : \
		*.foundation.fict.example : \
		\N^[
1
-
2
]\d{3}\.fict\.example$\N : \
		partial-dbm;/opt/data/penguin/book : \
		nis;domains.byname : \
		nisplus;[name=$domain,status=local],domains.org_dir

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



   Списки хостов используются для контроля, что можно делать удалённым хостам. Например, некоторым хостам можно разрешить релей через локальную машину, и некоторым может быть разрешено использовать команду SMTP ETRN. Хосты могут быть идентифицированы двумя различными путями, по имени или по IP-адресу. В списке хостов некторые типы паттернов совпадают с именем хоста, и некоторые совпадают с IP-адресом. Вы должны быть особенно осторожны при использовании одноключевых поисков, и гарантировать что используется правильный ключ.



   Если элемент списока хостов - пустая строка, то она совпадает только когда не используется удалённый хост. Так происходит при получении сообщения от локального процесса используя SMTP на стандартном вводе, т.е. когда не используется соединение TCP/IP.
   Специальный паттерн “*” в списке хостов совпадает с любым хостом, или ни с каким хостом (наверное, имеется ввиду то самое подключение без TCP/IP, от локальных процессов). Фактически, ни имя ни Ip-адрес не просматриваются.



   Если хост IPv4 соединяется с хостом IPv6 и запрос принимается на сокет IPv6, входящий адресна хосте IPv6 фигурирует как “::ffff:<v4address> ”. Когда такой адрес проверяется в списке хостов, он сначала преобразуется в традиционный адрес IPv4. (Не все операционные системы принимают вызовы IPv4 на сокеты IPv6, поскольку были проблемы с безопасностью.)
   Следующие типы паттернов в списках хостов проверяют удалённый хост, просматривая его IP-адрес:


192
.
168
.
23
.
236
/
31

совпадает лишь с двумя адресами, 192.168.23.236 и 192.168.23.237. Маска со значением 32 для адреса IPv6 - тоже самое что её отсутствие; такому элементу соответствует единственный адрес.
   Вот другой пример, показывающий сети IPv4 и IPv6:


recipient_unqualified_hosts = 192 . 168 . 0 . 0 / 16 : \ 3ffe::ffff::836f::::/ 48

   Удвоение разделителей списка применяется лишь в случае когда эти элементы использубтся внутри строки списка хостов. Это не требуется при задании их внутри файла. Например:


recipient_unqualified_hosts = /opt/exim/unqualnets

может использовать файл содержащий


172 . 16 . 0 . 0 / 12 3ffe:ffff:836f::/ 48

и будет иметь точно такой же эффект как и предыдущий пример. При использовании адресов IPv6 внутри строки, обычно более удобно использовать изменение символа разделителя. Такой список содержит теже самые две сети:


recipient_unqualified_hosts = <; 172 . 16 . 0 . 0 / 12 ; \ 3ffe:ffff:836f::/ 48

   Разделитель изменён на точку запятой использованием “<;” в начале списка.



   Когда хост идентифицируется по одноключевому поиску его полного IP-адреса, паттерн принимает такой вид:


net-<single-key-search-type>;<search-data>

   Например:


hosts_lookup = net-cdb;/hosts-by-ip.db

   Текстовая форма Ip-адреса хоста используется как ключ поиска. Адреса IPv6 конвертируются к несокращённой форме, с использованием строчных букв, с точками в качестве разделителей, поскольку двоеточие - ограничитель ключа в файлах “lsearch”. [Двоеточия могут использоваться в внутри ключа в файлах “lsearch”, если пометить ключ в кавычки, но это было добавлено позже.] Данные возвращённые поиском не используются.
   Одноключевые поиски также могут выполняться с использованием IP-адресов с маской, используя паттерн такой формы:


net<number>-<single-key-search-type>;<search-data>

   Например:


net24-dbm;/networks.db

   Ip-адрес хоста замаскирован используя “ <number> ” в качестве длинны маски. Текстовая строка создаётся из скрытого маской значения, сопровождаемого маской, и это иcпользуется как ключ поиска. Например, если у хоста IP-адрес 192.168.34.6, то ключ для вышеупомянутого примера - “192.168.34.0/24”. Адреса IPv6 конвертируются в текстовый вид, с использованием строчных букв, и точек, вместо двоеточия, в качестве разделителей, поскольку двоеточие - признак конца ключа в файлах “lsearch”. Всегда используются полные адреса IPv6, а не аббревиатуры.
   Внимание: Специфические “net32-”(для адреса IPv4) или “net128-”(для адреса IPv6), не тоже самое что и специфическое “net-” без номера. В предыдущем случае ключевые строки включают значение маски, тогда как в последнем IP-адрес используется самостоятельно.



   Существует несколько типов паттернов, требующих, чтобы exim знал имя удалённого хоста. Они являются подстановочными паттернами или поиском по имени. (Если полное имя хоста даётся без какого-либо подстановочного знака, оно используется для поиска соответствующего IP-адреса, как описано выше, в секции 10.11.)
   Если при столкновении exim`a с одним из этих паттернов, удалённое имя хоста неизвестно, оно будет найдено по IP-адресу. Хотя многие сервера интернета являются вполне добросовестными, и имеют обратные DNS-записи, есть много хостов у которых её нет (прим. lissyara: иногда очень проблематично добиться от провайдера обратной записи, обусловлено это, по моему, тем что там работают люди понятия не имеющие как её прописать). Следовательно, имя не всегда может быть найдено, и это может привети к нежелательным эффектам. Позаботтьтесь об этом при конфигурировании списков хостов с подстановочными паттернами.Рассмотрите варант, если имя не может быть найдено.
   Из-за проблем с разрешением имён хостов по IP-адресам, соответствие имён хостов не такое же как совпадение IP-адресов.
   По-умолчанию, для нахождения имени хоста, exim делает обратный DNS-поиск; если в DNS имя не найдено, пробуются системные функции “ gethostbyaddr() ” или “ getipnodebyaddr() ” - какая доступна. Порядок, в котором производится поиск, может быть изменён установками опции “host_lookup_order”.
   Есть несколько опций управляющих поведением в случае, если имя хоста не найдено. Они описаны ниже, в разделе 10.14.
   В результате альясинга, хосты могут иметь более одного имени. При обработке любого из следующих типов паттернов, все имена хостов проверяются:


^(a|b)\.c\.d$

является регулярным выражением, совпадающим с двумя хостами “ a.c.d ” или “ b.c.d ”.Когда регулярное выражение используется в списке хостов, вы должны позаботится о том, чтобы обратный слэш (“\”) и символ доллара (“$”) не были неверно восприняты как часть раскрытия строки. Самый простой способ избежать этого - использовать “\N” для того чтобы отметить нужную часть строки как нераскрываемую.


sender_unqualified_hosts = \N^(a|b)\.c\.d$\N : ....

   Предупреждение: Если вы хотите соответствия полному имени хоста, то вы должны включить символ “$” - закрывающий метасимвол в регулярном выражении, как в вышеупомянутом примере. Без этого, будет подходить всё, с совпадаюшим имененм хоста.



   Когда обрабатывается список хостов, exim`y может понадобиться найти IP-адрес по имени (смотрите секцию 10.11), или имя хоста по IP-адресу (смотрите секцию 10.13). В любом случае, при невозможности найти информацию поведение одинаковое.
   По-умолчанию, exim ведёт себя так, будто хост не совпадает со списком. Это не всегда совпадает с тем, что вам нужно. Для изменения поведения exim`a есть специальные элементы - “+include_unknown” или “+ignore_unknown” которые могут появляться в списке (на верхнем уровне, они не признаются в списках файлов).


host_reject_connection = +include_unknown:*.enemy.ex

отклоняет подключения от любых хостов, чьи имена совпадают с “*.enemy.ex”, и от тех хостов, чьи имена не могут быть найдены.


accept hosts = +ignore_unknown : friend.example : \
               
192
.
168
.
4
.
5

принимает (почту, видимо :))) от любого хоста, имя которого “ friend.example ”, и от “192.168.4.5”, независимо найдено или нет его имя. Без “+ignore_unknown”, если имя “192.168.4.5” не найжено, почта отклоняется.
   Оба элемента, “+include_unknown” и “+ignore_unknown” могут появляться в одном списке. Эффект от каждого длиться до следующего или до конца списка.
   Заметтьте: Эта секция применяется к постоянным ошибкам поиска. Она не применяется к временным ошибкам DNS. Они всегда вызывают задержку сообщения (кроме тех случаев, когда “dns_again_means_nonexist” преобразовывает их в постоянные ошибки).



   Если паттерн имеет форму


<single-key-search-type>;<search-data>

например


dbm;/host/accept/list

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



   Если паттерн имеет форму


<query-style-search-type>;<query>

то выполняются запросы, если они успешны, имя хоста совпадает с элементом. Данные, которые искались, не используются. Переменные “ $sender_host_address ” и “ $sender_host_name ” могут использоваться в запросе. Например:


hosts_lookup = pgsql;\ select ip from hostlist where ip='$sender_host_address'

   Значение переменной “ $sender_host_address ” для адреса IPv6 содержит двоеточия. Если вам необходимо, вы можете использовать элемент раскрытия “sg” для изменения этого. Если хотите использовать адреса с маской, то можете использовать оператор раскрытия “mask”.
   Если запрос содержит ссылку на “ $sender_host_name ”, exim автоматически ищет имя хоста, если это не было сделано раньше. (Смотрите секцию 10.13, для подробностей о поиске имён хостов.)
   Историческое примечание: до релиза 4.30, exim всегда пытался найти имя хоста перез выполнением запроса, если типу поиска не предшествовало “net-”. Сейчас это не так. Для обратной совместимости, “net-” распознаётся при поиске в стиле запроса, но его присутствие или отсутствие не имеет никакого эффекта. (Разумеется, для одноключевых поисков, “net-” является важным. Смотрите секцию 10.12.)



   Если вы используете поиск имени или безразличного имени хоста и IP-адреса в одном списке хостов, то вы должны размещать IP-адреса вначале. Например, в ACL вы могли бы иметь:


accept hosts = 10 . 9 . 8 . 7 : *.friend.example

   Причина этого, в том, что exim обрабатывает списки слева направо. Это позволяет проверить IP-адрес без запроса DNS, а при достижении элемента требующего разрешения имени в адрес происходит ошибка, если невозможно найти имя хоста для сравениея с паттерном. Если вышеупомянутый список был бы в обратном порядке, утверждение “accept” было бы неудачно для хоста имя которого найти невозможно, даже если его IP адрес 10.9.8.7.
   Если же вам действительно необходимо проверять первыми имена, и продолжить проверять IP-адреса, то вы можете переписать эту ACL таким образом:


accept hosts = *.friend.example accept hosts = 10 . 9 . 8 . 7

   Если первый “accept” неудачен, exim продолжает проверять второе утверждение. Смотрите секцию 39, для получения подробной информации о ACL.



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


senders = :

   Присутствие двоеточия означает пустой элемент. Если никаких данных нет (в смысле, не было бы даже двоеточия - прим. lissyara), то список пуст и не соответствует вообще ничему. Пустой отправитель также может быть обнаружен регулярным выражением, соответствующим пустой строке, и поиском в стиле запросов, успешному в случае если переменная “ $sender_address ” пуста.
   Непустые элементы списка адресов могут быть прямыми адресами электронной почты. Например:


senders = jbc@askone.example : hs@anacreon.example

   Разрешается некоторое число безразличий (т.е. шаблонов). Если паттерн содержит символ “@”, но он не регулярное выражение, и не начинается с типа поиска заканчивающегося точкой с запятой (описано ниже), локальная часть адреса сравнивается с локальной частью паттерна, которая может начинатсья со звёздочки. Если локальная часть совпадает, проверяется точно таким же образом для шаблона спика доменов. Например, домен может быть безразличным, обращаясь к именованному списку, или быть поиском:


deny senders = *@*.spamming.site:\ *@+hostile_domains:\ bozo@partial-lsearch;/list/of/dodgy/sites:\ *@dbm;/bad/domains.db

   Если локальная часть начинается с восклицательного знака, требуется чтобы это было определно как регулярное выражение, поскольку в противном случае восклицательный знак, как обычно в списках, будет воспринят как символ отрицания.
   Если непустой паттерн не регулярное выражение, или поиск не содержит символ “@”, это сравнивается с доменной частью адреса. Так понимаются только два формата - литеральный домен (домен в виде IP-адреса) или шаблон домена начинающийся со звёздочки. В обоих случаях, эффект точно такой же, как будто “*@” предшествовала паттерну. Например:


deny senders = enemy.domain : *.enemy.domain

   Следующие виды более сложных видов паттернов списков адресов могут совпадать с любым адресом, включая пустой адрес, являющийся характеристикой (видимо, признаком - прим. lissyara) отправителей рикошета:


deny senders = \N^.*this.*@example\.com$\N : \
               \N^\d{8}.+@spamhaus.example$\N : ...

   Последовательность “\N” удаляется при раскрытии, таким образом элементы действительно начинаются с крышки (“^”), к тому времени как они интерпретируются как паттерн адреса.


deny senders = cdb;/etc/blocked.senders : \
               mysql;select address from blocked where \
               address='${quote_mysql:$sender_address}'

   Могут использоваться и одноключевой стиль, и стиль запросов. Для одноключевого типа, exim использует полный адрес как ключ. Однако, пустые ключи не поддерживаются одноключевым поиском, таким образом, сравнение с пустым адресом всегда будет неудачно. Это ограничение не применяется к поиску в стиле запросов.
   Частичное соответствие для одноключевых поисков (раздел 9.7) не может использоваться, и игнорируется, если задано, с записью в журнал событий (paniclog). Однако, вы можете сконфигурить дефолтовые параметры поиска, как описано в секции 9.6, но это полезно лишь для значений по-умолчанию типа “*@”. Например, с этим поиском:


accept senders = lsearch*@;/some/file

файл может содержать строки типа таких:


user1@domain1.example *@domain2.example

и для адреса отправителя “ nimrod@jaeger.example ” последовательность пробуемых ключей будет:


nimrod@jaeger.example *@jaeger.example *

   Предупреждение 1: Не включайте строку “*” в ключевой файл, поскольку это означало бы что соответсвие любому адресу, делая эту проверку бесполезной.
   Предупреждение 2: Не путайте эти два вида элементов:


deny recipients = dbm*@;/some/file deny recipients = *@dbm;/some/file

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


deny senders = @@dbm;/etc/reject-by-domain

данные из DBM файла, могли бы содержать строки:


baddomain.com: !postmaster : *

для отклонения всех отправителей, кроме “postmaster” из этого домена.
   Если требуется, чтобы локальная часть, начиналась с восклицательного знака, это должно быть определено с использованием регулярного выражения. В файлах “lsearch”, отдельные записи могут быть разбиты на несколько строк, для выравнивания, но разделяющие двоеточия всё ещё могут включаться в перевод строки. Пустое место вокруг двоеточий игнорируется. Например:


aol.com: spammer1 : spammer2 : ^[ 0 - 9 ]+$ : spammer3 : spammer4

   Как и во всех списках exim`a, разделённых двоеточиями, двоеточие может быть включено в элемент, путём его (двоеточия) удвоения.
   Если последний элемент списка начинается с правй угловой скобки (“>”), остаток элемента берётся как новый ключ поиска для получения списка продолжения локальных частей. Новый ключ может быть последовательностью символов. Таким образом омжно иметь такие вхождения в файле


aol.com: spammer1 : spammer 2 : >* xyz.com: spammer3 : >* *: ^\d{8}$

в файле который ищется с “@@dbm*”, для задания совпадения с 8-цифровой локальной частью для всех доменов, в дополнение к специфическим локальным частям перечисленным для каждого домена. Конечно, использование этой особенности стоит другого поиска каждый раз когда цепочка сопровождается (видимо, символом “>” - прим. lissyara), но целью было уменьшить нагрузку.
   При использовании этого средства, возможно создание петель, и для того чтобы их выявить, цепочки не могут содержать более пятидесяти элементов.


senders = +my_list
senders = *@+my_list

   В первом, “my_list” является именованым списком адресов, тогда как во втором примере - именованный список доменов.



   Домены в e-mail адресах всегда обрабатываются регистронезависимо, но для локальных частей, на некоторых системах, это может быть существенно (смотрите “caseful_local_part” для разъяснения того, как exim работает с этими адресами при роутинге). Однако, RFC 2505 (“ Anti-Spam Recommendations for SMTP MTAs ” - антиспамовые рекомендации для SMTP MTA) предлагает чтобы соответствие адресов спискам заблокированных было сделано в регистронезависимой маненре. Так как большинство списков адресов в exim`e используется для этого вида управления, exim пытается сделать это (регистронезависимый поиск, видимо - прим. lissyara) по-умолчанию.
   Доменная часть адреса всегда переводится в нижний регистр до сравнения её со списком адресов. Локальная часть, по дефолту, переводится в нижний регистр, и любые производимые сравнения строки делаются регистронезависимо. Это значит, что данные могут быть непосредственно в списках адресов, в файлах включаемых простые имена файлов, и в любых файлах в которых производится поиск с использованием механизма “@@”, могут быть в любом регистре. Однако, ключи в файлах, поиск в которых производится по типу отличному от “lsearch” (который выполняется регистронезависимо), должны быть в строчных буквах, поскольку в них поиск регистрозависим.
   Для разрешения регистрозависимого совпадения в списках адресов, если элемент списка адресов является строкой “+caseful”, оригинальный регистр локальной части восстанавливается для любого проводимого сравнения, и сравнения строк становятся регистрозависимы. Это не затрагивает домен, остающийся в нижнем регистре. Однако, хотя независимые сравнения доменов остаются регистронезависимы, регулярные выражения производящие сравнение со всем адресом, становятся  регистрозависимыми после того, как был обнаружен пункт “+caseful”.



   Чувствтительность к регистру в списках локальных частей обрабатывается таким же образом для списков адресов, как только что описано. Элемент “+caseful” может использоваться, по необходимости. В установке опции “local_parts” в роутере с установленным в “false” пунктом “caseful_local_part” адрес в строчных буквах и изначально сравнивается регистронезависмо. В этом случае, “+caseful” восстановит регистрозависимое сравнение в списках локальных частей, но не в других местах роутера. Если в роутере опция “caseful_local_part” установлена в “true”, сравнение в опции “local_parts” регистрозависимо с начала маршрутизатора.
   Если список локальных частей расположен в файле (смотрите секцию 10.3), комментарии обрабатываются также как и списки адресов - они распознаются лишь в случае, если символу “#” предшествует пустой символ, или символ начала новой строки. Иначе, списки локальных частей сравниваются точно также как и списки доменов, за исключением специальных элементов относящихся к локальному хосту (“@”, “@[]”, “@mx_any”, “@mx_primary” и “@mx_secondary”) которые не распознаются. Обратитесь к секции 10.8 для получения дополнительных деталей о других доступных типах элементов.


begin translation by http://exim.org.ua/mailman/listinfo/exim-doc-translation
edit, verification and complete translation by lissyara




Партнёры:

Хостинг: