Если аутентификация неудачна, клиент может отключиться, или может попробовать другой аутентификационный механизм, или может попробовать передать почту по неаутентифицированному соединению.
    Если вы настраиваете клиента, и хотите знать, какие аутентификационные механизмы поддерживает сервер, вы можете использовать telnet для соединения с 25 портом (порт SMTP) на сервере, и выдать команду EHLO. Ответ на неё включает список поддерживаемых механизмов. Например:
| 
$ 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.
33.1 Общие опции для аутентификаторов
	
		| 
			
				
					| Имя | Использование | Тип | Дефолтовое значение |  
					| driver | authenticators | string | незадана |  | 
    Эта опция всегда должна быть установлена. Она определяет, какой из доступных аутентификаторов должен использоваться.
	
		| 
			
				
					| Имя | Использование | Тип | Дефолтовое значение |  
					| public_name | authenticators | string | незадана |  | 
    Эта опция определяет имя аутентификационного механизма, который принадлежит драйверу, и путём которого он известен внешнему миру. Эти имена должны содержать лишь буквы в прописном регистре (заглавные - прим. lissyara), цифры, подчёркиания, и дефисы (RFC2222), но exim фактически, соответствует им регистронезависимо. Если “
public_name
” не задана, по умолчанию используется имя драйвера.
	
		| 
			
				
					| Имя | Использование | Тип | Дефолтовое значение |  
					| server_advertise_condition | authenticators | string† | незадана |  | 
    Когда сервер собирается информировать об аутентификационном механизме, условие раскрывается. Если оно приводит к пустой строке, “0”, “no”, или “false”, о механизм не информируется. Если ошибка не принудительная, и не вызывана путём задержки поиска, инцидент логгируется. Смотрите ниже, раздел 33.3 для дальнейшего обсуждения.
	
		| 
			
				
					| Имя | Использование | Тип | Дефолтовое значение |  
					| 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 применяет следующие проверки, до приёма его как аутентифицированного отправителя сообщения:
 Если значение AUTH= было принято любым из двух предыдущих правил, и клиент аутентифицировался, и аутентификатор имеет установку для “
server_mail_auth_condition
”, условие проверяется в этой точке. Значение, которое было сохранено из аутенификатора - раскрывается. Если раскрытие неудачно, или приводит к пустой строке, “0”, “no”, или “false”, значение “
$authenticated_sender
” удаляется. Если раскрытие приводит к другому значению, значение “
$authenticated_sender
” сохраняется, и передаётся с сообщением.
    Когда “
$authenticated_sender
” установлена для сообщения, оно передаётся к другим хостам, на которых exim аутентифицируется как клиент. Не путайте это значение с “
$authenticated_id
”, которое является строкой, полученной из аутентификационного процесса, и которое, обычно, неполный адрес электронной почты.
    Каждый раз, когда значение AUTH= игнорируется, инцидент логгируется. ACL для MAIL, если задана, запускается после того как AUTH= принята, или проигнорирвана. Поэтому, она может использовать “
$authenticated_sender
”. Обратное - неверно: значение “
$sender_address
” - ещё не установлено, когда работает “
acl_smtp_mailauth
” ACL.
33.3 Аутентификация на сервере exim
    Когда exim передаёт команду EHLO, он сообщает публичные имена тех аутентификаторов, которые сконфигурированы как сервера, подчиняясь следующим условиям:
 Если установлена опция “
server_advertise_condition
”, её раскрытие не должно привести к пустой строке, “0”, “no”, или “false”. 
    Порядок, в котором заданы аутентификаторы контролирует порядок, в котором информируется о механизмах.
    Некоторые почтовые клиенты (например, некоторые версии Netscape) требуют, чтобы пользователь предоставлял имя и пароль для аутентификации каждый раз, когда информируется о AUTH, даже при том, что аутентификация фактически, не необходима (например, exim может быть настроен для разрешения безоговорочного релея от клиентов, путём проверки IP-адреса). Вы можете сделать таких клиентов более дружественными, не сообщая им о AUTH. Например, если клентам сети 10.9.8.0/24 разрешено (путём ACL работающеё для RCPT) релеить почту без аутентификации, вы должны установить
| 
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. Так происходит если
 Раскрытие “
server_advertise_condition
” заблокировало информирование о всех серверных аутентификаторах.
    Иначе, exim запускает ACL определённую путём “
acl_smtp_auth
”, чтобы решить - принять ли команду. Если опция “
acl_smtp_auth
” не задана, AUTH принимается от любых клиентских хостов.
    Если AUTH не отклонена путём ACL, exim ищет свою конфигурацию для серверного аутентификационного механизма, о котором информировалось в ответе на EHLO, и который совпадает с именованным в команде AUTH. Если он его находит, он запускает соотвтетствующий аутентификационный протокол, и аутентификация успещна или неуспешна. Если нет соответствия с информировавшимся механизмом, команда AUTH отклоняется с ошибкой 504.
    Когда сообщение получено с аутентифицированного хоста, значение “
$received_protocol
” установлено в “esmtpa” или “esmtpsa” вместо “esmtp” или “esmtps”, и “
$sender_host_authenticated
” содержит имя (не публичное имя) драйвера аутентификации, который успешно аутентифицировал клиента, от которого было получено сообщение. Эта переменная пуста, если небыло успешной аутентификации.
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 для предотвращения их неверного восприятия. Например, команда типа:
даст некорректный ответ, поскольку неэкранированы символы “@” и “$”.
    Если у вас есть инсталлированная команда “
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 (как клиент) пробует аутентифицироваться следующим образом: