$ 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.22). Если аутентификаторы не требуются, аутентификационная секция в конфигурационном файле не требуется. Каждый аутентификатор, в принципе, может иметь и клиентские и серверные функции. Когда 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.



33.1 Общие опции для аутентификаторов

Имя Использование Тип Дефолтовое значение client_condition authenticators string† незадана

   Когда exim аутентифицируется как клиент, он пропускает любые аутентификаторы чьё раскрытие приводит к “0” или “false”. Это может быть использовано, например, для пропуска аутентификатора с открытым текстом, когда соединение незашифровано, путём такой установки:


client_condition = ${if !eq{$tls_cipher}{}}

   (Старая документация некорректно указывает, что “$tls_cipher” содержит шифрование используемое для входящих сообщений. Фактически, в процессе SMTP доставки, она содержит шифр используемый для доставки.)



Имя Использование Тип Дефолтовое значение driver authenticators string незадана

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



Имя Использование Тип Дефолтовое значение public_name authenticators string незадана

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



Имя Использование Тип Дефолтовое значение server_advertise_condition authenticators string† незадана

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



Имя Использование Тип Дефолтовое значение server_condition authenticators string† незадана

   Эта опция должна быть задана для серверного аутентификатора “plaintext”, где он используется для прямого контроля аутентификации. Для дополнительных деталей, смотрите секцию 34.2.
   Для других аутентификаторов “server_condition” может быть использована как дополнительный механизм аутентификации или авторизации, который применяется после успеха других условий аутентификаторов. Если она задана, она раскрывается, когда аутентификатор должен вернуть код успеха. Если раскрытие принудительно неудачно, аутентификация неудачна. Любые другие ошибки раскрытия вызывают возврат кода временной ошибки. Если результат успешного раскытия пустая строка, “0”, “no”, или “false” - аутентификация неуспешна. Если результат раскрытия “1”, “yes”, или “true” - аутентификация успешна. Для любых других результатов возвращается код временной ошибки, с текстом ошибки в виде результата раскрытия.



Имя Использование Тип Дефолтовое значение server_debug_print authenticators string† незадана

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



Имя Использование Тип Дефолтовое значение server_set_id authenticators string† незадана

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



Имя Использование Тип Дефолтовое значение server_mail_auth_condition authenticators string† незадана

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



33.2 Параметр AUTH в команде MAIL

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


33.3 Аутентификация на сервере 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. Так происходит если


33.4 Проверка серверной аутентификации

   Опция “-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).



33.5 Аутентификация exim`a как клиента

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