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


domains = ${lookup{
$sender_host_address}lsearch{/some/file}}
domains = lsearch;/some/file

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


192
.
168
.
3
.
4
: domain1:domain2:...

192
.
168
.
1
.
9
: domain3:domain4:...

   Когда поиск успешен, результат раскрытия - список доменов (и, возможно, другие типы элементов, разрешённые в списке доменов).
   Во втором примере, ищется один элемент в списке доменов. Это вынуждает exim к использованию поиска, для того чтобы узнать, может ли обрабатываемый домен быть найден в файле. Файл может содержать строки как эти:


domain1:
domain2:

   Любые данные, сопровождаемые ключами, не уместны при проверке что домен совпадает с элементом списка.
   Их можно спутать, при использовании обоих видов поиска сразу. Рассмотрите файл, содержащий, например, такие строки:


192
.
168
.
5
.
6
: lsearch;/another/file

   Если значение “ $sender_host_address ” - 192.168.5.6, раскрытие первой установки “ domains ” генерит вторую установку, которая вызывает второй поиск.
   Оставшаяся часть этой главы описывает различные доступные типы поиска. Любой из них может использоваться в любой части конфигурации, где разрешены поиски.



   Реализованы два различных типа поиска:


LOOKUP_DBM=yes
LOOKUP_LSEARCH=yes

и означают, что лишь линейный поиск и поиск в DBM включены по дефолту. Для некоторых типов поисков (например, БД SQL), вам необходимо инсталлировать библиотеки и файлы заголовков, до сборки exim`a.



   Реализованы следующие одноключевые типы поиска:


1
.
2
.
3
.
4
:           data for 
1
.
2
.
3
.
4


192
.
168
.
0
.
0
/
16
     data for 
192
.
168
.
0
.
0
/
16

"abcd::cdab":      data for abcd::cdab
"abcd:abcd::/
32
"   data for abcd:abcd::/
32

   Ключ для “ iplsearch ” поиска  должен быть IP-адресом (без маски). Поиск по файлу линейный, с использованием масок CIDR, где они заданы, до нахождения соответствия ключу. Используется первый совпадающий ключ; дальнейших попыток найти “лучшее” совпадение, не предпринимается. Кроме совпадения ключей, обработка “ iplsearch ” - такая же как у “ lsearch ”.
   Предупреждение 1: В отличие от большинства других одноключевых поисков, файл данных для “ iplsearch ” не может быть превращён в DBM или cdb-файл, поскольку эти типы поиска поддерживают только буквальные ключи.
   Предупреждение 2: В списке хостов,вы всегда должны использовать “ net-iplsearch ”, таким образом, чтобы неявный ключ был IP-адресом, а не именем (смотрите раздел 10.12).


baduser:  :fail:

   Пустые строки, и строки начинающиеся с “#” игнорируются, даже если они встречаются в середине строки. Это - традиционный текстовый формат файла альясов. Обратите внимание, что ключи в файле “ lsearch ” - литеральные строки. Тут нету подстановки (“wildcarding”) какого бы то ни было вида.
   В большинстве “ lsearch ” файлов, ключи не могут содержать двоеточия, или символы “#”, или пустые пробелы. Однако, если вам необходима эта возможность, она доступна. Если ключ начинается с символа двойной кавычки, она завершается только соответствующей кавычкой (или концом строки), и, к её содержимому, применяются обычные правила экранирования (смотрите раздел 6.16). Опционально, двоеточие разрешено после ключа в кавычках (также как и для ключей без кавычек). Специальная обработка кавычек для части данных строки “ lsearch ” отсуствует.


^\N\d+\.a\.b\N    data for <digits>.a.

   Примечание - использование “\N” отключает раскрытие содержимого регулярного выражения. Если вы используете “ nwildlsearch ” там, где ключи не раскрываются, это эквиалентрно:


^\d+\.a\.b        data for <digits>.a.b

   Если регулярное выражение содержит пустое место, или символы двоеточия, вы должны поместить его в кавычки (смотрите “ lsearch ”, выше), или представить эти символы другим образом. Например, “\s” может быть использовано для обозначения пробела и “\x3A” - для двоеточия. Это может оказаться легче, чем использовать кавычки, поскольку при использовании кавычек, вы должны экранировать все обратные слэши внутри кавычек.
   Примечание: Невозможно зафиксировать подстроки в совпадении регулярного выражения, для дальнейшего использования, поскольку результаты всех поисков кэшируются. Если поиск повторяется, результат берётся из кэша, и нет фактического сопоставления с образцом. Значения всех цифровых переменных сбрасываются после совпадения “(n)wildlsearch ”.


cdb;/some/file  data for keys that match the file

   Данные, полученные из вложенного поиска, отвергаются.
   Ключи, которые не соответствуют ни одному из этих паттернов, интепретируются буквально. Правила продолжения для данных - точно ткие же как для “ lsearch ”, и ключи могут сопровождаться опциональными двоеточиями.
   Предупреждение: В отличие от большинства других одноключевых поисков, файл данных для “(n)wildlsearch ” не может быть превращён в DBM или cdb-файл, поскольку эти типы поиска поддреживают только буквальной соответствие.



   Поддерживаемые типы поиска в стиле запроса перечислены ниже. Дальнейшие детали, о многих из них, даны в дальнейших разделах.


require condition = \
  ${lookup whoson {$sender_host_address}{yes}{no}}

   Запрос состоит из единственного IP-адреса. Возвращённое значение - имя аутентифицированного пользователя, который сохранён в переменной “ $value ”. Однако, в этом примере, данные “ $value ” не используются; результат поиска - одна из фиксированных строк - “yes” or “no”.



   Функции поиска мошут вернуть коды временных ошибок, если поиск не может быть завершён. Например, БД SQL или LDAP могут быть недоступны. Поэтому не желательно использовать поиск, которыё мог бы сделать такое для критичных опций, например, списка локальных доменов.
   Когда поиск не может быть завершён в роутере или транспорте, доставка сообщения (к релевантному адресу) задерживается, как и для других временных ошибок. При других обстоятельствах, exim может предположить, что поиск был неудачен, или может вообще всё бросить.



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


data = ${lookup{
$local_part@$domain}lsearch*@{/etc/mix-aliases}}

   Предположим, обрабатываемый адрес - “ jane@eyre.example ”. Exim ищет эти ключи в таком порядке:


jane@eyre.example
*@eyre.example
*

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



   Нормальная операция одноключевого поиска - поиск в файле, точного соответствия заданному ключу. Однако, во множестве ситуаций в которых ищутся домены, было бы полезным частичное соответствие. В этом случае, информация в файле, которая начинается с “*.”, совпадает с любым доменом заканчивающимся компоненами, следующими за точкой. Например, если ключ в DBM-файле такой


*.dates.fict.example

тогда, когда частичное соответсвие включено, это совпадает (в том числе) “ 2001.dates.fict.example ” и “ 1984.dates.fict.example ”.  Также совпадает с “ dates.fict.example ”, если эта строка не появляется как отдельный ключ в файле.
   Примечание: Частичное соответствие не доступно для поисков в стиле запроса. Также оно недоступно для поиска любых элементов в списках адресов (смотрите раздел 10.18).
   Частичное соответствие реализовано путём отдельных поисков с использованием ключей сконструированных путём модификации оригинального ключа. Это означает, что он может использоваться с любым типом одноключевого поиска, при условии, что частично совпадающие ключи, начинающиеся со специального преффикса (по умолчанию - “*.”), включены в файл данных. Ключи в файле, которые не начинаются с преффикса, совпадают только с немодифицированными ключами, когда используется частичное соответствие.
   Частичное соответствие вызывают путём добавления строки “partial-” к началу имени одноключевого типа поиска, например, “ partial-dbm ”. Когда это происходит, вначале ищется немодифицированный объект ключа; если поиск неудачен, “*.” добавляется вначале ключа, и снова производится поиск. Если он неудачен, будущие поиски пробуют удалять разделённые точками компоненты, он начала ключа, один за одним, и добавляя “*.” к началу того, что осталось.
   Требуемое минимальное число не-* компонентов - два. Это может быть скорректировано включением числа до дефиса, в типе поиска. Например, “ partial3-lsearch ” задаёт минимум три не-* компонента в измененённых ключах. Отстутствие числа эквивалентно “partial2-”. Если ключ “ 2250.dates.fict.example ”, тогда следующие ключи ищутся, когда минимальное число не-* компонентов - два:


2250
.dates.fict.example
*.
2250
.dates.fict.example
*.dates.fict.example
*.fict.example

   Как только один ключ, в последовательности, успешно найден, поиск завершён.
   Использование “*.”, как дефолтового преффикса, может быть изменено. Мотивацией для этой возможности является разрешение exim`y работать с форматами файлов используемыми другими MTA. Иной префикс может быть предоставлен в круглых скобках, вместо дефиса, после “partial”. Например:


domains = partial(.)lsearch;/some/file

   В этом примере, если домен - “ a.b.c ”, последовательность поисков - “a.b.c”, “.a.b.c” и “.b.c” (при неизменённом дефолтовом минимуме в 2 компонента). Префикс может состоять из любых символов пунктуации, кроме закрывающей круглой скобки. Он может быть пустым, например:


domains = partial1()cdb;/some/file

   Для этого примера, если домен “ a.b.c ”, последовательность поиска будет “a.b.c”, “b.c” и “c”.
   Если задан “partial0”, что случается в конце (когда поиск, с лишь одним неподстановочным компонентом, неудачен и оригинальный ключ укорачиватся вправо на нулевую строку) зависимостей от префикса:


   Exim кэширует все результаты поисков, для избежания бесполезных повторений поисков. Однако, поскольку (кроме даемона) exim работает как коллекция независимых, короткоживущих процессов, это кэширование применяется только в пределах одного процесса exim`a. Средства для межпроцессного кэширования отсутсвуют.
   Для одноключевого поиска, exim оставляет релевантные файлы открытыми в случае, если есть другой поиск, нуждающийся в них. В некоторых типах конфигураций, это может привести к большому числу открытых файлов, сохраняемых открытыми, оставляемых открытыми для сообщений со многими получателями. Для избежания попадений под системные ограничения на число открытых файлов, exim закрывает последний использованный файл, когда необходимо открыть больше файлов чем позволяют его внутренние ограничения, которое можно изменить через опцию “ lookup_open_max ”.
   Файлы одноключевого поиска закрываются и сбрасывается кэш поиска в стратегических точках доставки - например, после завершения всех роутингов.



   Когда данные из входящего сообщения включаются в поиск типа запросов, возможно появление специальных символов в данных, нарушающих синтаксис запроса. Например, запрос NIS+ содержащий


[name=$local_part]

будет прерван, если локальная часть будет содержать правую квадратную скобку. Для данных NIS+, данные должны быть помещены в двойные кавычки, как в примере:


[name="$local_part"]

но это оставляет проблемы с кавычками в данных. Правила для NIS+ состоит в том, что двойные кавычки должны быть удвоены. Другие типы поиска имеют иные правила, и для решения этих требований существет оператор раскрытия такой формы:


${quote_<lookup-type>:<string>}

   Например, самый безопасный способ написания NIS+ запроса:


[name="${quote_nisplus:$local_part}"]

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



   Тип поиска “ dnsdb ” использует DNS как базу данных. Простой запрос содержит тип записи и имя домен, разделённые знаком равно (“=”). Например, строка раскрытия может содержать:


${lookup dnsdb{mx=a.b.example}{$value}fail}

   Если поиск успешен, результат помещается в “ $value ”, которая, в этом случае, используется как результат. Если поиск успешен, ключевое слово “fail” вызывает принудительную ошибку раскрытия (“ forced expansion failure ”) - смотрите раздел 11.4 для понимания, что это означает.
   Поддерживаемые типы DNS-записей - A, CNAME, MX, NS, PTR, SRV, and TXT, и когда exim скомпилен с поддержкой IPv6 - AAAA (и A6, если это тоже сконфигурено). Если тип не задан, предполагается TXT. Когда тип PTR, данные могут быть нормально записанным IP-адресом; инверсия и добавление “ in-addr.arpa ” или “ ip6.arpa ” происходят автоматически. Например:


${lookup dnsdb{ptr=
192
.
168
.
4
.5}{$value}fail}

   Если данные для PTR-записи не являются синтаксически допустимым IP-адресом, он не изменяется и ничего не добавляется.
   Для поиска MX, для каждой записи возвращаются оба привелигированных значения, и имя хоста, разделённые пробелом. Для поиска SRV, приоритет, вес, порт и имя хоста возвращаются для каждой записи, разделённые пробелами.
   Для любых типов записей, если найдено много записей (или, для поиска A6, если одна запись ведёт ко многим адресам), данные возвращаются как объединение, с символом новой строки, как дефолтовым разделителем. Порядок, разумеется, определяется DNS-резольвером. Вы можете задать иной разделитель символов, между несколькими записями, путём помещения в начале запроса правой угловой скобки, сопровождаемой (без пробелов) новым раделителем. Например:


${lookup dnsdb{>: a=host1.example}}

   Разрешается задать пробел, как символ разделителя. дальнейшее пустое пространство игнорируется.



   По-умолчанию, и предпочтительное значение, и имя хоста, возвращаются для каждой MX-записи, разделённые пробелами. Если вам нужны только имена хостов, вы можете использовать псевдо-тип MXH:


${lookup dnsdb{mxh=a.b.example}}

   В этом случае, предпочтительное значение опущено, и возвращаются только имена хостов.
   Другой псевдотип - ZNS (расшифровывается “zone NS”). Он выполянет поиск NS-записи для данного домена, но если она не наёдена, он удаляет первый компонент имени домена, и пробует снова. Этот процесс продолжанется пока не найдена NS-запись, или не останется компонентов имени (или произойдёт ошибка DNS). Другими словами, он может вернуть сервер имён домена верхнего уровня, но никогда не вернёт корневой сервер имён. Если нет NS-записей домена верхнего уровня, поиск неудачен. Рассмотрите эти примеры:


${lookup dnsdb{zns=xxx.quercite.com}}
${lookup dnsdb{zns=xxx.edu}}

   Предполагается, что в каждом случае тут нет NS-записей для полного доменного имени, в первом случае сервером имён возвращается значение для “ quercite.com ”, и во втором случае сервером имён возвращается значение для “ edu ”.
   Вы должны быть внимательны при использовании этого типа поиска, поскольку, если домен верхнего уровня не существует, поиск всегда вернёт какое-то имя домена. Это могло бы использоваться для того, чтобы видеть, находится ли сервер имён данного домена в чёрном списке. Вероятно, вы можете предполагать, что сервреа имён для доменов верхнего уровня, таких как “ su ” или “ co.uk ” не собиираются находиться в таких списках.
   Третий псевдо-тип - CSA (Client SMTP Authorization). Он ищет SRV-записи для правил CSA, которые описаны в разделе 39.37. Хотя “ dnsdb ” непосредственно поддерживает поиски SRV, этого недостаточно, из-за дополнительного режима поиска родительских доменов CSA. Результат успешного поиска, например:


${lookup dnsdb {csa=$sender_helo_name}}

имеет два разделённых пробелами поля: код авторизации и имя целевого хоста. Авторизационный код может быть “Y” для yes, “N” для no, “X” для явно требуемой, но отсутствующей авторизации, или “?” для неизвестного.



   В предыдущих разделах описаны поиски для одиночного домена. Однако, вы можете задать список доменов или адресов в отдельном “ dnsdb ” поиске. Список задаётся в нормальном виде exim`a, с двоеточием в качестве дефолтового разделителя, но с возможностью изменить его. Например:


${lookup dnsdb{one.domain.com:two.domain.com}}
${lookup dnsdb{a=one.host.com:two.host.com}}
${lookup dnsdb{ptr = <; 
1
.
2
.
3
.
4
 ; 
4
.
5
.
6
.8}}

   Для сохранения обратной совместимости, есть один специальный случай: если тип поиска PTR и не указано изменение разделителя, exim смотрит, не является ли остаток строки одним IPv6 адресом. В этом случае, он не обрабатывает её как список.
   Данные каждого поиска объединены, с символом новой строки в качестве дефолтового разделителя, таким образом обрабатываются множественные DNS-записи для одного элемента. Может быть задан иной разделитель, как указано выше.
   Поиск “ dnsdb ” неудачен, лишь если неудачны все все DNS-поиски. Если для любого из них происходит временная ошибка DNS, то поведением управляет опциональное ключевой слово, с последующей запятой, могущей появиться перед типом записи. Возможные ключевые слова - “defer_strict”, “defer_never”, и “defer_lax”. С “strict” поведением, любая временная ошибка DNS вызывает задержку всего поиска. С “never” поведением, временные ошибки DNS игнорируются, и поведение такое, будто поиск в DNS не привёл ни к чему. С “lax” поведением, предпринимаются все запросы, но временые ошибки DNS вызывают задержку лишь в случае, если если остальные поиски были безуспешны. Дафолт - “lax”, таким образом, следующие поиски эквивалентны:


${lookup dnsdb{defer_lax,a=one.host.com:two.host.com}}
${lookup dnsdb{a=one.host.com:two.host.com}}

   Следовательно, в дефолтовом случае, поиск успешен до тех пор, пока хоть один поиск в DNS привёл к каким-то данным.



   Оригинальная реализация LDAP была сделана в University of Michigan; она стала “Open LDAP”, и сейчас существует два различных релиза. Другая реализация происходит из Netscape, Solaris 7 и последующие релизы содержат встроенную поддержку LDAP. К сожалению, хотя все они совместимы на уровне функционирования запросов, обработка их ошибок различна. По этой причине необходимо установить переменную, во время компиляции exim`a с LDAP, для указания, какая библиотека LDAP используется. Одна из следующих строк должна быть в вашем “ Local/Makefile ”:


LDAP_LIB_TYPE=UMICHIGAN
LDAP_LIB_TYPE=OPENLDAP1
LDAP_LIB_TYPE=OPENLDAP2
LDAP_LIB_TYPE=NETSCAPE
LDAP_LIB_TYPE=SOLARIS

   Если “LDAP_LIB_TYPE” не задана, exim предполагает “OPENLDAP1”, имеющий такой же интерфейс, как и версия University of Michigan.
   Есть три типа поиска LDAP в exim. Они ведут себя по-разному, когда обрабатывают результаты запроса:


   Запрос к LDAP имеет форму URL, как определено в RFC2255. Например, в конфигурации роутера “ redirect ”, могла бы быть такая установка:


data = ${lookup ldap \
  {ldap:///cn=$local_part,o=University%20of%20Cambridge,\
  c=UK?mailbox?base?}}

   URL может начинаться с “ldap” или “ldaps”, если ваша библиотека LDAP поддерживает безопасные (шифрованные) LDAP-соединения. Второй из них гарантирует, что используются шифрованные подключения TLS.



   В запросах LDAP требуются два уровня квотирования, первый - непосредвственно для LDAP, и второй, поскольку запрос LDAP представлен как URL. Кроме того, внутри LDAP-запроса, требуются два различных вида квотирования. Поэтому есть два различных, LDAP-специфичных, оператора квотирования.
   Оператор “ quote_ldap ” спроектирован для использования на строках, являющихся частью спецификации фильтра. Концептуально, он, вначале, производит следующие преобразования строки:


*   =>   \2A
(   =>   \28
)   =>   \29
\   =>   \5C

в соответствии с RFC2254. Результирующая строка квотируется согласно правилам для URL, т.е. все не алфавитно-цифровые символы, кроме:


! $ ' - . _ ( ) * +

конвертируются в их шастнадцатеричные значения, с предшествующим им символом процента. Например:


${quote_ldap: a(bc)*, a<yz>; }

превращается в


%20a%5C28bc%5C29%5C2A%2C%20a%3Cyz%3E%3B%20

   Удалив квотирование URL, это (с начальным и конечным пустым пространством):


a\28bc\29\2A, a<yz>;

   Оператор “ quote_ldap_dn ” спроектирован для использования на строках, являющихся частью базовых спецификаций DN, в запросех. Концептуально, вначале он конвертирует строку, вставляя обратный слэш перед любым из следующих символов:


, + " \ < > ;

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


${quote_ldap_dn: a(bc)*, a<yz>; }

будет


%5C%20a(bc)*%5C%2C%20a%5C%3Cyz%5C%3E%5C%3B%5C%20

   Удалив квотирование URL, получится (с конечными пробелами)


\ a(bc)*\, a\<yz\>\;\ 

   Есть некоторые дальнейшие комментарии о квотировании в секции о аутентификации LDAP, ниже.



   Подключение к серверу LDAP может быть через TCP/IP, или, когда используется OpenLDAP, через сокет UNIX. Пример, данный выше, не определяет сервер LDAP. Сервер, который доступен по TCP/IP, может быть задан в запросе, запуская его так:


ldap://<hostname>:<port>/...

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


ldap_default_servers = ldap1.example.com::
145
:ldap2.example.com

   Если “ ldap_default_servers ” незадана, библиотеке LDAP передаётся URL безбез имени сервера, и используется дефолтовое значение библиотеки (обычно - локальный компьютер).
   Если вы используете библиотеку OpenLDAP, вы можете соединится с LDAP-сервером используя сокет UNIX, вместо подключения через TCP/IP. Это задаётся использованием “ldapi” вместо “ldap” в LDAP-запросах. Нижеследующее (имеется ввиду - про “ldapi” - прим. lissyara), применяется только в OpenLDAP. Если exim скомпилен с поддержкой различных LDAP-библиотек, эта возможность недоступна.
   Для этого типа соединения, вместо имени хоста, требуется имя-путь сокета, и номер порта неуместен. Имя-путь может быть указано как элемент в “ ldap_default_servers ”, или встроено в запрос. В первом случае, вы будете иметь настройки типа таких:


ldap_default_servers = /tmp/ldap.sock : backup.ldap.your.domain

   Когда путь с именем указываются в запросе, вы должны заменить прямые слэши последовательностью “%2F” для соблюдения синтаксиса LDAP URL. Например:


${lookup ldap {ldapi://%2Ftmp%2Fldap.sock/o=...

   Когда exim производит поиск LDAP, и находит, что “имя хоста” (“hostname”) - реальный путь к сокету, он использует код сокета UNIX, даже если запрос задаёт использование “ldap” или “ldaps”. В частности, для соединения с сокетом не используется шифрование. Это поведение означает, что вы можете использовать настройки, например, “ ldap_default_servers ”, в примере выше, с традиционными  “ldap” или “ldaps”, и эо будет работать. Вначале, exim пробует соединиться через через сокет UNIX; если это не удаётся, он пробует подключиться по TCP/IP к резервному хосту.
   Если в запросе задаётся явный тип “ldapi”, при указанном имени хоста, диагностируется ошибка. Однако, если есть другие элементы в “ ldap_default_servers ”, пробуются они. Другими словами:


   Синтаксис LDAP URL не предоставляет пути передачи аутентификационной и иной управляющей информации на сервер. Чтобы сделать это возможным, URL в запросе LDAP может предшествоваться любым числом установок “ <name>=<value> ”, разделённых пробелами. Если значение содержит пробелы, они должны быть помещены в двойные кавычки, и, когда используются двойные кавычки, надо использовать обратный слэш, как обычно. Распознаются следующие имена:



   Значение параметра “DEREFERENCE” должно быть одним из слов “never”, “searching”, “finding”, или “always”.
   Имя “CONNECT” - устаревшее имя “NETTIME”, сохраненноё для обратной совместимости. Этот таймаут (заданный как число секунд) устанавливатся с клиентской стороны, для операций, который могут быть выполнены по сети. Специально, это применяется к сетевым соединениям и вызовам функции “ ldap_result() ”. Если значение больше чем ноль, используется LDAP_OPT_NETWORK_TIMEOUT, если задано в заголовках LDAP (OpenLDAP), или, если в заголовках LDAP (Netscape SDK 4.1) задано LDAP_X_OPT_CONNECT_TIMEOUT. Нулевое значение вызывает явную установку “no timeout” для Netscape SDK; для OpenLDAP никакого действия не происходит.
   Параметр TIME (также число секунд) передаётся на сервер для установки серверных ограничений на время потраченное на поиск.
   Вот пример запроса LDAP в поиске exim`a, использующем некотрые из этих значений. Это - одна строка, перенесённая, чтобы поместиться на странице:


${lookup ldap
  {user="cn=manager,o=University of Cambridge,c=UK" pass=secret
  ldap:///o=University%20of%20Cambridge,c=UK?sn?sub?(cn=foo)}
  {$value}fail}

   Кодирование пробелов, как “%20” - из URL, его нелььзя делать для каких-либо вспомогательных данных. Конфигурационные настройки exim`a, включающие поиски содержащие информацию о пароле, необходимо предварять “hide”, чтобы предотвратить возможность увидеть эти значения не-административными пользователями, при использовании опции “ -bP ”.
   Вспомогательные данные могут быть даны в любом порядке. По умолчанию - таймаут отсутсвует (используется системный таймаут), нет пользователя или пароля, нет ограничений на число возвращённых значений, и нет ограничений по времени запроса.
   Когда DN квотирован в USER= setting для LDAP аутентификации, exim удаляет любое URL-квотирование, которое может быть до LDAP. Очевидно, некоторые библиотеки делают это для себя, но некоторые нет. Удаление URL-квотирование даёт два преимущества:


USER=cn=${quote_ldap_dn:$1}

должна работать, даже если “ $1 ” содержит пробелы.
   Раскрытые данные для PASS= value должны быть квотированы с использованием оператора раскрытия “ quote ”, а не оператора квотирования LDAP.  Единственная причина, по которой это поле нуждается в квотировании, состоит в том, чтобы гарантировать его соответствие синтаксису exim`a, который не разрешает пробелы вне кавычек. Например:


PASS=${quote:$3}

   Аутентификационный механизм LDAP может использоваться для прокерки паролей, как часть SMTP-аутентификации. Смотрите условие ракрытия строки “ ldapauth ” в разделе 11.



   Типы поиска “ ldapdn ” возвращают Distinguished Name (отличительное имя) из единственного элемента, как последовательность значений, например:


cn=manager, o=University of Cambridge, c=UK

   Тип поиска “ ldap ” генерит ошибку, если более одного элемента соответствует фильтру поиска, тогда как “ ldapm ” разрешает этот случай, и вставляет новую строку в результат, до данных от различных входов. Это возможно для многочисленных значений возвращённых для обоих “ ldap ” и “ ldapm ”, но в первом случае вы знаете, что независимо от возвращённого значения, исходили из одиночного вхождения в директории.
   В общем случае, где вы задаёте один аттрибут в вашем LDAP-запросе, результат не квотируется, и не содержит имя атрибута. Если атрибут имеет множественные значения, они разделются запятыми.
   Если вы определяете множественные тарибуты, результат содержит разделённые пробелами, квотированные строки, каждая с предшествующим именем атрибута и символом равно. В пределах кавычек, символ двойной кавычки, обратного слэша и новой строки экранируется обратным слэшем, и запятые используются для разделения многочисленных значений атрибута. В части для экранирования, строка внутри кавычекпринимает такую же форму как вывод, когда запрашивается единственный атрибут. Если никакие атрибуты не заданы, это тоже самое, что и задание всех атрибутов.
   Это - некотрые примеры формата вывода. Превая строка каждой пары - запрос LDAP, и вторая - возвращённые данные. Атрибут называемый “ attr1 ” имеет два занчения, тогда как “ attr2 ” - лишь одно:


ldap:///o=base?attr1?sub?(uid=fred)
value1.
1
, value1.
2


ldap:///o=base?attr2?sub?(uid=fred)
value two

ldap:///o=base?attr1,attr2?sub?(uid=fred)
attr1="value1.
1
, value1.
2
" attr2="value two"

ldap:///o=base??sub?(uid=fred)
objectClass="top" attr1="value1.
1
, value1.
2
" attr2="value two"

   Оператор “ extract ” в раскытиях строки может быть использован для выбора индивидуальных полей из данных, состоящих из пар “ key=value ”. Вы модете использовать опцию exim`a “ -be ”, для хапуска теста раскрытия и таким образом проверить результаты поиска в LDAP.



   Запросы NIS+ состоят из “ индексного имени ” (“ indexed name ”) NIS+, сопровождаемого опциональным двоеточием и именем поля. Если это дано, разультат успешного запроса - содержимое именованного поля; иначе - результат состоит из объединённых пар “ field-name=field-value ”, разделённых пробелами. пустые значения и значения содержащие пробелы помещаются в двойные кавычки. Например, запрос


[name=mg1456],passwd.org_dir

мог бы вернуть строку


name=mg1456 passwd="" uid=
999
 gid=
999
 gcos="Martin Guerre"
home=/home/mg1456 shell=/bin/bash shadow=""

(разбито на две строки чтобы пометиться на странице), тогда как


[name=mg1456],passwd.org_dir:gcos

вернул бы лишь


Martin Guerre

без кавычек. Поиск NIS+ неудачен если NIS+ возвращает больше одного элемента таблицы для данного индексного ключа. Эффект оператора раскрытия “ quote_nisplus ” удваивает любые символы кавычек внутри текста.



   Exim может поддерживать поиски в Interbase, MySQL, Oracle, PostgreSQL, и SQLite базах данных. Запросы для этих БД содержат SQL-выражения, таким образом, пример мог бы быть таким


${lookup mysql{select mailbox from users where id='userx'}\
  {$value}fail}

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


${lookup pgsql{select home,name from users where id='userx'}\
  {$value}}

мог бы быть


home=/home/userx name="Mister X"

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


Mister X

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



   Если используются какие-либо поиски в MySQL, PostgreSQL, Oracle, или Interbase, должна быть установлена опция “ mysql_servers ”, “ pgsql_servers ”, “ oracle_servers ” или “ ibase_servers ” (соответственно) в виде списка информации о сервере, разделённого двоеточиями. Каждый элемент в списке - разделённый слэшами список четырёх пунктов: имя хоста, имя БД, имя пользователя и пароль. В случае Oracle, поле имени хоста используется для “имени сервиса” (“service name”), поле имени базы данных не используется, и должно быть пустым. Например:


hide oracle_servers = oracle.plc.example//userx/abcdwxyz

   Поскольку данные пароля секретны, вы всегда должны предшествовать настройку словом “hide”, для предотвращения просмотра установки неадминистративными пользователями при использовании опции “ -bP ”. Вот пример, где перечислены два сервера MySQL:


hide mysql_servers = localhost/users/root/secret:\
                     otherhost/users/root/othersecret

   Для MySQL и PostgreSQL, хост может быть задан как “ <name>:<port> ”, но т.к. это список значений разделённых двоеточиями, то оно должно быть удвоено. Для каждого запроса, эти параметры групп проверяются, в порядке успешности соединенией и запросов.
   Операторы раскрытия “ quote_mysql ”, “ quote_pgsql ” и “ quote_oracle ” конвертируют новую строку, таб, возврат каретки и обратный слэш в “\n”, “\t”, “\r” и “\b” соответственно, и символы одиночной кавычки, двойной кавычки и обратного слэша экранируются обратным слэшем. Оператор раскрытия “ quote_pgsql ”, кроме того, экранирует символы процента и подчёркивания. Это нельзя делать для MySQL, поскольку эти символы экранирования не распознаются в контексте, где они они не экранируют специальные символы.
   


   Для MySQL, пустое имя хоста, или использование “localhost” в “ mysql_servers ” вызывает соединение с сервером на локальном хосте через сокет UNIX. Альтернативный сокет может быть указан в круглых скобках. полный синтаксис каждого элемента в “ mysql_servers ” таков:


<hostname>::<port>(<socket name>)/<database>/<user>/<password>

   Любая из трёх частей первого поля может быть опущена. Для нормального использования на локальном хосте можно отсавить пробел, или установить лишь “localhost”.
   Нет необходимости в указании БД, - если она тут отсутсвует, то должна быть дана в запросах.
   Если запрос MySQL не возвращает никаких данных (команды insert, update, или delete), результат поиска - число затронутых строк.
   Внимание: Это может ввести в заблуждение. Если обновление ничего, фактически, не меняет (например, устанаваливая поле на то же самое значение), результат - ноль, поскольку нет затронутых строк.



   Поиски в PostgreSQL также могут использовать сокет UNIX для соединения с БД. Обычно, это быстрей, и стоит меньше процессорного времени, чем подключение по TCP/IP. Однако он может использоваться лишь в случае, если сервер БД работает на той же самой машине, что и почтовый сервер. Конфигурационная строка для PostgreSQL, через сокет UNIX, выглядит так:


hide pgsql_servers = (/tmp/.s.PGSQL.
5432
)/db/user/password : ...

   Другими словами, вместо имени хоста даётся путь к сокету. путь заключён в круглые скобки так, чтобы его прямые слэши не были визуально перепутаны с разделителями других параметров сервера.
   Если запрос PostgreSQL не возвращает никаких данных (команды insert, update, или delete), результат поиска - число затронутых строк.



   SQLite отличается от других поисков SQL, поскольку требуется имя файла, в дополнение к SQL-запросу. БД SQLite - один файл, и нет демона, как в других БД. Интерфейс exim`a требует чтобы имя файла, как абсолютный путь, было задано в начале запроса. Оно отделяется от запроса пустым пространством. Это означает что путь и имя файла не могут содержать пустые символы. Вот пример раскрытия поиска:


${lookup sqlite {/some/thing/sqlitedb \
  select name from aliases where id='userx';}}

   В списке, похожий синтаксис. Например:


domainlist relay_domains = sqlite;/some/thing/sqlitedb \
   select * from relays where ip='$sender_host_address';

   Единственный символ, затрагиваемый оператором “ quote_sqlite ” - символ одиночной кавычки, которую он удваивает.
   Библиотека SQLite обрабатывает множественные одновременные доступы к БД внутренне. Множественные чтения разрешены, но лишь один процесс может производить обновление. Попытки обращения к БД, во время обновления, отклоняются после таймаута ожидания, в течение которого библиотека SQLite ждёт освобождения блокировки. В exim, дефолтовый таймаут установлен в 5 секунд, но это может быть изменено с помощью опции “ sqlite_lock_timeout ”.




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