$ telnet server.example 
25

Trying 
192
.
168
.
34
.
25
...
Connected to server.example.
Escape character is '^]'.

220
 server.example ESMTP Exim 
4
.
20
 ...
ehlo client.example

250
-server.example Hello client.example [
10
.
8
.
4
.
5
]

250
-SIZE 
52428800


250
-PIPELINING

250
-AUTH PLAIN

250
 HELP

   Предпоследняя линия этого примера, показывает, что сервер поддерживает аутентификацию с использованием механизма PLAIN. В exim`e, различные аутентификационные механизмы конфигурируются путём специфических дайверов “ authenticator ”. Как у роутеров и транспортов, то, какие аутентификаторы включены в бинарник, определяется при сборке. В настоящее время, доступны следующие установки:


AUTH_CRAM_MD5=yes
AUTH_CYRUS_SASL=yes
AUTH_PLAINTEXT=yes
AUTH_SPA=yes

в “ Local/Makefile ”, соответственно. Первая из этих поддержек аутентификационный механизм CRAM-MD5 (RFC2195), второй предоставляет интерфейс к аутентификационной библиотеке Cyrus SASL. Третий может быть сконфигурирован для поддержки аутентификационного механизма PLAIN (RFC2595), или механизма LOGIN, который формально не зарегистрирован, но используется несколькими MUA. Четвёртый аутентификатор поддерживает механизм Microsoft'овский “ Secure Password Authentication ”.
   Аутентификаторы конфигурируются с использованием того же синтаксиса, что и другие драйверы (смотрите раздел 6.21). Если аутентификаторы не требуются, аутентификационная секция в конфигурационном файле не требуется. Каждый аутентификатор, в принципе, может иметь и клиентские и серверные функции. Когда exim принимает почту по SMTP, он работает как сервер, когда он шлёт сообщения наружу через SMTP - он выступает в роли клиента. Конфигурационные опции аутентификатора предоставляют возможность использования обоих этих обстоятельств.
   Для прояснения, какая опция к какой ситуации применяется, в именах опций используются префиксы “ server_ ” и “ client_ ”, определяющие серверные или клиентские функции, соответственно. Серверные и клиентские функции отключены, если не установлен ни один из вариантов. Если аутентификатор должен использоваться для обоих, серверных и клиентских функций, в одном определении, требуется использование обоих установок опций. Например:


cram:
  driver = cram_md5
  public_name = CRAM-MD5
  server_secret = ${if eq{$auth1}{ph10}{secret1}fail}
  client_name = ph10
  client_secret = secret2

   Опция “ server_ ” используется когда exim выступает в роли сервера, и “ client_ ” - когда он выступает в роли клиента.
   Описания индивидуальных аутентификаторов даны в последующих главах. Оставшаяся часть этой главы охватывает общие опции для аутентификаторов, сопровождаемые общим обсуждением о способе работы аутентификации в exim`e.



   Эта опция всегда должна быть установлена. Она определяет, какой из доступных аутентификаторов должен использоваться.



   Эта опция определяет имя аутентификационного механизма, который принадлежит драйверу, и путём которого он известен внешнему миру. Эти имена должны содержать лишь буквы в прописном регистре (заглавные - прим. lissyara), цифры, подчёркиания, и дефисы (RFC2222), но exim фактически, соответствует им регистронезависимо. Если “ public_name ” не задана, по умолчанию используется имя драйвера.



   Когда сервер собирается информировать об аутентификационном механизме, условие раскрывается. Если оно приводит к пустой строке, “0”, “no”, или “false”, о механизм не информируется. Если ошибка не принудительная, и не вызывана путём задержки поиска, инцидент логгируется. Смотрите ниже, раздел 33.3 для дальнейшего обсуждения.



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



   Когда сервер exim успешно аутентифицируется как клиент, эта строка раскрывается, используя данные из аутентификации, и сохраняется для входящих сообщений в переменной “ $authenticated_id ”. Также, она включается в строку лога для входящих сообщений. Например, конфигурация аутентификатора user/password могла бы сохранять использовавшееся для аутентификации имя пользователя, и обращатся к нему впоследствии, в течение доставки сообщения. Если раскрытие неудачно, опция игнорируется.



   Эта опция позволяет серверу отказываться от аутентифицированных отправителей адресов, подаваемых как часть команды MAIL в SMTP-соединении, которое аутентифицировано путём драйвера, на котором установлена опция “ server_mail_auth_condition ”. Опция не используется как часть аутентификационного процесса; вместо этого её (нераскрытое) значение запоминается для дальнейшего использования. То, как оно используется, описано в следующей секции.



   Когда клиент предоставляет AUTH=элемент в команде MAIL, exim применяет следующие проверки, до приёма его как аутентифицированного отправителя сообщения:


   Когда exim передаёт команду EHLO, он сообщает публичные имена тех аутентификаторов, которые сконфигурированы как сервера, подчиняясь следующим условиям:


auth_advertise_hosts = ! 
10
.
9
.
8
.
0
/
24

чтобы не информировать их о аутентификационных механизмах.
   Опция “ server_advertise_condition ” контролирует информирование о отдельных аутентификационных механизмах. Например, она может быть использована для ограничения информирования о специфических механизмах в шифрованных соединениях, путём установки типа:


server_advertise_condition = ${if eq{$tls_cipher}{}{no}{yes}}

   Если сессия зашифрована, переменная “ $tls_cipher ” - не пуста, и таким образом, раскрытие приводит к “yes”, которое разрешает информирование.
   Когда exim как сервер получает от клиента команду AUTH, он немедленно её отклоняет, если о AUTH не сообщалось в более раннем ответе на команду EHLO. Так происходит если


   Опция “ -bh ”, командной строки exim`a, может быть полезной при тестировании серверной конфигурации аутентификации. Данные для команды AUTHнужно посылать используя кодирование base64. Быстрый способ делать такие данные для тестирования - следующий скрипт на perl:


use 
MIME
::
Base64
;


printf 
(
"%s"
, 
encode_base64
(eval 
"\"$ARGV[0]\""
));

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


encode '\0user\0password'

   Отметтьте использование одиночных кавычек, для предотвращения интерпретации шеллом обратных слэшей, чтобы они могли быть интерпретированы perl`ом в специфические символы, чьё кодовое значение - ноль.
   Предупреждение 1: Если строка пользователя или пароля начинается с восьмеричной цифры, вы должны использовать три нуля вместо одного, после начального обратного слэша. Если вы этого не сделаете, восьмеричная цифра, с которой начинается ваша строка будет некорректно интерпретирована как часть кода первого знака.
   Предупреждение 2: Если в строках есть символы которые perl интерпретирует особым образом, вы должны использовать экранирование perl`a для предотвращения их неверного восприятия. Например, команда типа:


encode '\0user@domain.com\0pas$$word'

даст некорректный ответ, поскольку неэкранированы символы “@” и “$”.
   Если у вас есть инсталлированная команда “ mimencode ”, то другой способ создать закодированную по base64 строку - запустить команду


echo -e -n `\0user\0password' | mimencode

   Опция “ -e ” команды “ echo ” включает интерпретацию экранирования обратных слэшей в аргументе, и опция “ -n ” определяет, что в конце вывода не нужно добавлять символ новой строки. Однако, не все версии “ echo ” распознают эти опции, следовательно, вы должны проверить вашу версию до того как полагаться на этот совет. (Надо заметить, что из перечисленных ключей в FreeBSD существует только ключ “ -n ”, остальных нет - прим. lissyara).



   Транспорт “ smtp ” имеет две опции, назваемые “ hosts_require_auth ” и “ hosts_try_auth ”. Когда транспорт “ smtp ” коннектится к серверу которые информировал о поддержке аутентификации, и хост совпадает с отдельной записью в любой из этих опций, exim (как клиент) пробует аутентифицироваться следующим образом: