WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Перевод выполнен Алексеем Паутовым в рамках некоммерческого проекта RussianLDP (http://www.rldp.ru/). Именно на этом сайте и надлежит искать новые версии, если таковые будут. 33. SMTP-аутентификация Секция authenticators рабочей конфигурации exim управляет SMTP-аутентификацией. Это средство расширение протокола SMTP, описанное в RFC 2554, которое разрешает клиентскому SMTP-хосту аутентифицироваться на сервере. Это обычный серверный способ распознавать клиентов, которым разрешено использовать его как релей. SMTP-аутентификация неуместна для передачи почты между серверами, которые организационно никак не связаны друг с другом. Вкратце, способ работы SMTP-аутентификации таков: Сервер информирует о числе аутентификационных механизмов (mechanisms) в ответе на клиентскую команду EHLO. Клиент выдаёт команду AUTH, именуя специфический механизм. Команда может опционально содержать какие-либо аутентификационные данные. Сервер может выдать один или более вызовов (challenges), на которые клиент должен послать соответствующие ответы. В простых опознавательных механизмах вызовы представляют собой просто запросы имён пользователей и паролей. Сервер не должен выдавать каких-либо вызовов: в некоторых механизмах все уместные данные могут быть переданы с командой 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 различные аутентификационные механизмы конфигурируются путём специфических драйверов authenticator. Как у роутеров и транспортов, то, какие аутентификаторы включены в двоичный файл, определяется при сборке. В настоящее время доступны следующие установки: AUTH_CRAM_MD5=yes AUTH_CYRUS_SASL=yes AUTH_PLAINTEXT=yes AUTH_SPA=yes AUTH_DOVECOT=yes AUTH_GSASL=yes AUTH_HEIMDAL_GSSAPI=yes в Local/Makefile. Первая из этих поддержек задает аутентификационный механизм CRAM-MD5 (RFC 2195), вторая предоставляет интерфейс к аутентификационной библиотеке Cyrus SASL. Третья может быть сконфигурирована для поддержки аутентификационного механизма PLAIN (RFC 2595) или механизма 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. 33.1. Общие опции для аутентификаторов Имя Использование Тип Значение по умолчанию client_condition authenticators string не задана Когда Exim выполняется как клиент, он пропускает аутентификаторы, раскрытие опции client_condition которых выдает 0, no или false. Это может использоваться, например, чтобы пропускать аутентификаторы plaintext, когда подключение не шифровано установкой типа: client_condition = ${if !eq{$tls_cipher}{}} Обратите внимание: документация на версию 4.67 заявляет, что переменная $tls_cipher содержит шифр, используемый для входящих сообщений. Фактически, в ходе доставки по SMTP это содержит шифр, используемый для всей доставки. То же самое верно и для переменной $tls_peerdn. Имя Использование Тип Значение по умолчанию driver authenticators string не задана Эта опция всегда должна быть установлена. Она определяет, какой из доступных аутентификаторов должен использоваться. Имя Использование Тип Значение по умолчанию public_name authenticators string не задана Эта опция определяет имя аутентификационного механизма, который принадлежит драйверу, и путём которого он известен внешнему миру. Эти имена должны содержать лишь буквы в прописном регистре, цифры, подчёркивания и дефисы (RFC 2222), но exim фактически соответствует им регистронезависимо. Если public_name не задана, по умолчанию используется имя драйвера. Имя Использование Тип Значение по умолчанию server_advertise_condition authenticators string† не задана Когда сервер собирается информировать об аутентификационном механизме, условие раскрывается. Если оно приводит к пустой строке, 0, no или false, о механизме не информируется. Если ошибка не принудительная и не вызывана путём задержки поиска, инцидент протоколируется. Смотрите ниже раздел 33.3 для дальнейшего обсуждения. Имя Использование Тип Значение по умолчанию server_condition authenticators string† не задана Эта опция должна быть установлена для аутентификатора plaintext, где она используется непосредственно, чтобы управлять аутентификацией. Для других аутентификаторов server_condition может использоваться в качестве дополнительного механизма аутентификации или авторизации, который применяется после того, как другие условия аутентификатора успешно выполняются. Если это устанавливается, строка раскрывается. Если раскрытие принудительно неудачно, происходит сбой аутентификации. Любая другая неудача раскрытия вернет код временной ошибки. Если результатом успешного раскрытия является пустая строка, 0, no или false, происходит сбой аутентификации. Если результатом раскрытия будет 1, yes или true, аутентификация успешна. Для любого другого результата возвращается код временной ошибки с расширенной строкой, содержащей текст ошибки. Для аутентификатора gsasl эта опция требуется для различных механизмов, подробнее см. главу 37.4. Имя Использование Тип Значение по умолчанию 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 может быть полезной при тестировании серверной конфигурации аутентификации. Данные для команды AUTH нужно посылать, используя кодирование base64. Быстрый способ делать такие данные для тестирования: следующий скрипт на perl: use MIME::Base64; printf ("%s", encode_base64(eval  "\"$ARGV[0]\"")); Он интерпретирует свои аргументы как строки perl а затем кодирует их. Интерпретация как строки perl позволяет бинарные нули, которые должны быть включены в некоторые виды аутентификационных данных. Например, командная строка для запуска этого скрипта с такими данными могла бы быть такой: encode '\0user\0password' Отметьте использование одиночных кавычек для предотвращения интерпретации обратных слэшей, чтобы они могли быть интерпретированы perl в специфические символы, чьё кодовое значение ноль. Предупреждение 1: если строка пользователя или пароля начинается с восьмеричной цифры, Вы должны использовать три нуля вместо одного после начального обратного слэша. Если Вы этого не сделаете, восьмеричная цифра, с которой начинается строка, будет некорректно интерпретирована как часть кода первого знака. Предупреждение 2: если в строках есть символы, которые perl интерпретирует особым образом, Вы должны использовать экранирование perl для предотвращения их неверного восприятия. Например, команда типа: encode '\0user@domain.com\0pas$$word' даст некорректный ответ, поскольку не экранированы символы @ и $. Если у Вас есть инсталлированная команда mimencode, то другой способ создать закодированную по base64 строку запустить команду: echo -e -n `\0user\0password' | mimencode Опция -e команды echo включает интерпретацию экранирования обратных слэшей в аргументе, а опция -n определяет, что в конце вывода не нужно добавлять символ новой строки. Однако, не все версии echo распознают эти опции, следовательно, Вы должны проверить версию до того, как полагаться на этот совет. Надо заметить, что из перечисленных ключей в FreeBSD существует только ключ -n, остальных нет. 33.5. Аутентификация exim как клиента Транспорт 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, она перезадаёт аутентифицированного отправителя, полученного с сообщением.

Поиск На сайте В Яндексе