4. Команда AUTH
AUTH mechanism [initial-response]
Аргументы
Строка, идентифицирующая механизм аутентификации SASL. В строку может также включаться необязательный отклик, представленный в формате base64.
Ограничения
После успешного выполнения команды AUTH в той же сессии не могут вводиться дополнительные команды AUTH. После успешного выполнения команды AUTH сервер должен отвергать любые последующие команды AUTH с возвратом кода 503. Команды AUTH не допускаются в процессе выполнения почтовых транзакций.
Обсуждение
Команда AUTH показывает серверу механизм аутентификации. Если сервер поддерживает запрошенный механизм, он выполняет обмен данными протокола аутентификации и идентифицирует пользователя. В дополнение к этому может согласовываться уровень защиты для последующих транзакций протокола. Если запрошенный механизм аутентификации не поддерживается, сервер отвергает команду AUTH с возвратом кода 504.
Обмен данными протокола аутентификации состоит из последовательности запросов (challenge) сервера и откликов (answer) клиента, определяемых используемым механизмом аутентификации. Запрос сервера (server challenge), называемый также индикацией готовности (ready response) представляет собой код 334 с текстом, содержащим строку в коде BASE64. Ответ клиента состоит из строки в коде BASE64. Если клиент отказывается от аутентификационного обмена, он возвращает строку, содержащую только символ *. Если сервер получает такой отклик, он должен отвергнуть команду AUTH и возвратить код 501.
Необязательный аргумент initial-response в команде AUTH служит для «замыкания круга» (round trip) при использовании механизмов аутентификации, которые не передают данных в начальном запросе (initial challenge). При использовании аргумента initial-response с таким механизмом клиенту не передается пустой изначальный запрос и вместо этого сервер передает данные, указанные параметром initial-response, как будто он шлет их в ответ на пустой запрос. В отличие от пустого (zero-length) ответа клиента на код 334 пустой изначальный отклик передается в виде одного символа — знака равенства (=).
Если клиент использует в команде AUTH параметр initial-response для механизма, который передает данные в изначальном запросе, сервер отвергает команду AUTH с возвратом кода 535.
Если сервер не может декодировать аргумент BASE64, он отвергает команду AUTH с возвратом кода 501. Если сервер отвергает аутентификационные данные, ему следует отвергнуть и команду AUTH с возвратом кода 535, если нет подходящего более специфичного кода из числа перечисленных в главе 6. Для успешного завершения клиентом процесса обмена аутентификационными данными, сервер SMTP возвращает код 235.
Имя сервиса, задаваемое данным вариантом SASL, — smtp.
Если в процессе аутентификационного обмена SASL согласуется уровень защиты, он вступает в силу сразу же после последовательности CRLF, завершающей аутентификационный обмен для клиента и CRLF в отклике о позитивном результате для сервера. После вступления в силу уровня защиты протокол SMTP сбрасывается в начальное состояние (состояние SMTP после возврата сервером кода готовности 220). Сервер должен отбрасывать любые полученные от клиента данные (такие, как аргументы команды EHLO), которые не были получены непосредственно из согласования SASL. Клиент должен отбрасывать любую полученную от сервера информацию (такую, как список расширений сервиса SMTP), которая не была получена непосредственно из согласования SASL (исключением является возможность клиента сравнивать список анонсируемых механизмов SASL до и после аутентификации для детектирования активных атак по срыву согласования). Клиенту следует передавать EHLO в качестве первой команды после успешного завершения SASL-согласования, которое приводит к включению уровня защиты.
От сервера не требуется поддержки любого конкретного механизма аутентификации или механизмов аутентификации, требуемых для поддержки любых уровней защиты. При отказе, полученном в ответ на команду AUTH, клиент может попытаться использовать другой механизм аутентификации с помощью новой команды AUTH.
При отказе от выполнения команды AUTH сервер должен вести себя так, как будто клиент не вводил команду AUTH совсем.
Строка BASE64 в общем случае может иметь произвольную длину. Клиенты и серверы должны поддерживать строки запросов и откликов такого размера, который использует поддерживаемый ими механизм аутентификации, независимо от всех прочих ограничений на размер, которые могут вносить другие компоненты реализации протокола для сервера или клиента.
Примеры:
S: 220 smtp.example.com ESMTP server ready C: EHLO jgm.example.com S: 250-smtp.example.com S: 250 AUTH CRAM-MD5 DIGEST-MD5 C: AUTH FOOBAR S: 504 Unrecognized authentication type. C: AUTH CRAM-MD5 S: 334 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== S: 235 Authentication successful.