Если аутентификация неудачна, клиент может отключиться, или может попробовать другой аутентификационный механизм, или может попробовать передать почту по неаутентифицированному соединению.
Если вы настраиваете клиента, и хотите знать, какие аутентификационные механизмы поддерживает сервер, вы можете использовать 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 для предотвращения их неверного восприятия. Например, команда типа:
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 (как клиент) пробует аутентифицироваться следующим образом: