|
www.lissyara.su
—> документация
—> EXIM
—> 4.62
—> часть 33
33. SMTP-аутентификация
Секция “authenticators ”, ребочей конфигурации exim`a, управляет SMTP-аутентификацией. Это средство - расширение протокола SMTP, описанное в RFC2554, которое разрешает клиентскому SMTP-хосту атентифицироваться на сервере. Это - обычный серверный способ распознавать клиентов, которым разрешено использовать его как релей. SMTP-аутентификация неуместна для передачи почты между серверами которые организационно никак не связаны друг с другом.
Вкратце, способ работы SMTP-аутентификации таков:
Сервер информирует число аутентифкационных механизмов (mechanisms) в ответе на клиентскую команду EHLO.
Клиент выдаёт команду AUTH, именуя специфический механизм. Команда может, опционально, содержать какие-либо аутентификационные данные.
Сервер может выдать один или более вызовов (challenges, может быть переведено как откликов - прим. lissyara), на которые клиент должен послать соответствующие ответы. В простых опознавательных механизмах, вызовы - просто запросы имён пользователей и паролей. Сервер не должен выдавать каких-либо вызовов - в некоторых механизмах, все уместные данные могут быть переданы с командой AUTH.
Сервер или принимает, или отклоняет аутентификацию.
Если аутентификация успешна, клиент, опционально, может использовать опцию AUTH в команде MAIL для передачи аутентифицированного (заверенного) отправителя в последующих почтовых транзакциях. Аутентификация остаётся до конца SMTP-соединения.
Если аутентификация неудачна, клиент может отключиться, или может попробовать другой аутентификационный механизм, или может попробовать передать почту по неаутентифицированному соединению.
Если вы настраиваете клиента, и хотите знать, какие аутентификационные механизмы поддерживает сервер, вы можете использовать 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 применяет следующие проверки, до приёма его как аутентифицированного отправителя сообщения:
Если соединение не использует расширенный SMTP (т.е. использовался HELO вместо EHLO), использование AUTH= - синтаксическая ошибка.
Если значение параметра AUTH= - “<> ”, оно игнорируется.
Если задана “acl_smtp_mailauth ”, запускается определённая ACL. Когда она работает, значение “$authenticated_sender ” устанавливается из параметра AUTH=. Если ACL не выносит “accept ”, значение “$authenticated_sender ” удаляется. ACL “acl_smtp_mailauth ” может не вернуть “drop ” или “discard ”. Если она задерживается, для команды MAIL выдаётся код временной ошибки (451).
Если “acl_smtp_mailauth ” не задана, значение параметра AUTH= принимается, и помещается в “$authenticated_sender ” лишь если клиент аутентифицировался.
Если значение 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, он сообщает публичные имена тех аутентификаторов, которые сконфигурированы как сервера, подчиняясь следующим условиям:
Клиентский хост должен совпадать с “auth_advertise_hosts ” (по умолчанию - *)
Если установлена опция “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. Так происходит если
Хост клиента не совпадает с “auth_advertise_hosts ”; или
Отсутствуют аутентификаторы сконфигурированные с серверной опцией; или
Раскрытие “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 (как клиент) пробует аутентифицироваться следующим образом:
Для каждого аутентификатора, который сконфигурирован как клиент, он ищет аутентификационные механизмы объявленные сервером для того, чьё имя совпадает с публичным именем аутентификатора.
Когда он находит соответствующий, он запускает клиентский код аутентификатора. Переменные “$host ” и “$host_address ” доступны для любых раскрытий строк которые мог бы сделать клиент. Они устанавливаются в имя и IP-адрес сервера. Если дюбое раскрытие принудительно неудачно, попытка аутентификации прекращается и exim движется к следующему аутентификатору. Иные ошибки раскрытия вызывают задержку доставки
Если результат попытки аутентификации - временная ошибка или таймаут, exim прекращает попытку послать сообщение к хосту в этот момент. Он пробует позднее. Если есть доступные резервные хосты, они испытываются обычным образом.
Если ответ на аутентификацию - постоянная ошибка (с кодом 5xx), exim продолжает поиск списка аутентификаторов и пробует иные, если возможно. Если все попытки аутентификации дают постоянную ошибку, или если нет попыток по причине отсутствия совпадающих механизмов (или раскрытие опции приводит к принудительной неудаче), происходящее зависит от того, совпадает ли хост с “hosts_require_auth ” или “hosts_try_auth ”. В первом случае, генерится временная ошибка, и доставка задерживается. Ошибка может быть детектирована в правилах повторов, и, таким образом, превращена в постоянную - если вам это необходимо. Во втором случае, exim пробует доставить сообщение неаутентифицированным.
Когда exim подтвердил свою подлинность удалённому хосту, он добавляет параметр AUTH к посылаемой команде MAIL, если он имеет аутентифицированного отправителя. Если сообщение пришло с удалённого хоста, аутентифицированный отправитель - тот, который получен во входящей команде MAIL, при условии, что входящее соединение аутентифицировано, и кондишен “server_mail_auth ” позволяет сохранять аутентифицированного отправителя. Если локальный процесс вызывает exim для отправки сообщения, адрес отправителя построенный из имени логина пользователя и “qualify_domain ” рассматривается как аутентифицированный. Однако, если для транспорта “smtp ” установлена опция “authenticated_sender ”, она перезадаёт аутентифицированного отправителя полученного с сообщением.
=============
translated by lissyara
|
|