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 , она перезадаёт аутентифицированного отправителя полученного с сообщением.




    =============
    Автор перевода: lissyara, оригинал: http://www.lissyara.su/?id=1200