SMTP-аутентификация
SMTP-аутентификация , часто сокращенно SMTP AUTH , представляет собой расширение простого протокола передачи почты (SMTP), посредством которого клиент может войти в систему, используя любой механизм аутентификации, поддерживаемый сервером. В основном он используется серверами отправки , где аутентификация является обязательной. [1]
История
[ редактировать ]SMTP, как указано Джоном Постелом в 1970-х годах, не предусматривал использование паролей для отправки сообщений электронной почты; Каждый сервер по своей конструкции был открытым почтовым ретранслятором . В результате спам и черви , хотя изначально и не были проблемой, к концу 90-х годов стали чумой. [2] До SMTP AUTH клиент ретрансляции должен был идентифицироваться по IP-адресу , что практично только для служб электронной почты, предоставляемых тем же поставщиком услуг Интернета (ISP), который обеспечивает соединение, или же с использованием определенных хаков, таких как POP перед SMTP .
Джон Гардинер Майерс опубликовал первый проект SMTP AUTH в 1995 году. [3] и он последовательно разрабатывался и обсуждался в IETF вместе с протоколом отправки почты, расширенным SMTP (ESMTP) и простым уровнем аутентификации и безопасности (SASL). Более старым механизмом SASL для аутентификации ESMTP (ESMTPA) является CRAM-MD5 , и использование алгоритма MD5 в HMAC (кодах аутентификации сообщений на основе хэша) по-прежнему считается надежным. [4]
Консорциум Интернет-почты (IMC) сообщил, что в 1998 году 55% почтовых серверов были открытыми ретрансляторами. [5] но менее 1% в 2002 г. [6]
Роль в системе почтового транспорта
[ редактировать ]Использование агента отправки почты (MSA), обычно через порт 587, подразумевает SMTP AUTH. Использование MSA поддерживается большинством программного обеспечения. [7] и рекомендуется, особенно для поддержки кочующих пользователей, поскольку некоторые сетевые концентраторы либо блокируют порт 25, либо используют прокси-серверы SMTP . MSA отвечает за обеспечение того, чтобы конверт сообщения содержал правильные адреса, и может применять локальные политики для From поле заголовка. Проверка того, что отправитель конверта (он же Return-Path), используемый для SPF , и адрес отправителя соответствует идентификатору аутентифицированного пользователя, что особенно важно для доменов, подписывающих сообщения с использованием DKIM .
Ключевые слова, заканчивающиеся на «А», например ESMTPA и ESMTPSA, предусмотрены для with пункт Received поля заголовка, когда сообщения получены с SMTP AUTH. [8] «Ключевые слова предоставляются для статистических или диагностических целей» (RFC 3848); они проверяются некоторыми клиентами, например Spamassassin .
Подробности
[ редактировать ]Как и все расширения SMTP, SMTP AUTH объявляется в ответе EHLO вместе со списком поддерживаемых методов аутентификации. Эти методы могут измениться после выдачи STARTTLS , обычно разрешая использовать пароли в виде простого текста только в последнем случае. В RFC 4954 приведен следующий пример («C:» и «S:» не являются частью протокола, они обозначают строки, отправленные клиентом и сервером соответственно):
S: 220 smtp.example.com ESMTP Server
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250-AUTH GSSAPI DIGEST-MD5
S: 250-ENHANCEDSTATUSCODES
S: 250 STARTTLS
C: STARTTLS
S: 220 Ready to start TLS
... TLS negotiation proceeds.
Further commands protected by TLS layer ...
C: EHLO client.example.com
S: 250-smtp.example.com Hello client.example.com
S: 250 AUTH GSSAPI DIGEST-MD5 PLAIN
C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ=
S: 235 2.7.0 Authentication successful
SMTP AUTH также можно использовать на порту 25. Обычно серверы отклоняют команды RCPT TO, которые подразумевают ретрансляцию, если учетные данные аутентификации не были приняты. Спецификация рекомендует, чтобы серверы выдавали 530 5.7.0 Требуется аутентификация в ответ на большинство команд в том случае, если сервер настроен на требование аутентификации, а клиент еще не сделал этого. Таким образом следует настраивать только серверы, прослушивающие порт 587, или частные серверы, а не обмен сообщениями (MX). Однако историческая особенность, заключающаяся в том, что SMTP не аутентифицируется по умолчанию, в некоторых случаях приводит к различному поведению в отношении протоколов доступа; например, при использовании AUTH EXTERNAL после STARTTLS. [9]
Помимо команды AUTH , расширение также предоставляет параметр AUTH для команды MAIL FROM , чтобы можно было отличать аутентификацию от авторизации. Таким образом, отправитель может идентифицировать себя и передать несколько сообщений в течение одного сеанса. Хотя аутентификация не требует изменения, после ее установки разные сообщения могут отправляться в соответствии с разными соглашениями и, следовательно, требовать разной авторизации. Например, сообщения могут ретранслироваться от имени разных пользователей. Использование этого параметра гораздо менее популярно, чем использование команды для предоставления привилегий ретрансляции.
Аутентификация SMTP является «расширением» в терминах SMTP, поэтому она требует, чтобы сервер и клиент использовали глагол EHLO для приветствия, чтобы указать на поддержку расширений, в отличие от устаревшего приветствия HELO. [10] Для обратной совместимости приветствие HELO может быть принято, если расширение не используется .
Текст с заглавной буквы после команды AUTH представляет собой список типов авторизации, которые принимает SMTP-сервер.
Некоторые примеры протоколов авторизации включают в себя:
- ОБЫЧНЫЙ (использует кодировку Base64)
- ВХОД (использует кодировку Base64) [11] (устарело в пользу PLAIN)
- GSSAPI ( Общий программный интерфейс служб безопасности )
- DIGEST-MD5 ( Аутентификация доступа к дайджесту )
- MD5
- CRAM-MD5
- OAUTH10A ( токены OAuth 1.0a HMAC-SHA1, как определено в RFC 5849)
- OAUTHBEARER ( токены носителя OAuth 2.0, как определено в RFC 6750)
- XOAUTH2 [12]
Стандарты
[ редактировать ]- RFC 3207 , Расширение службы SMTP для защиты SMTP через безопасность транспортного уровня , Пол Хоффман, февраль 2002 г.
- RFC 3848 , Регистрация типов передачи ESMTP и LMTP , Крис Ньюман, июль 2004 г.
- RFC 6409 , Отправка сообщений по почте , Рэндалл Гелленс и Джон К. Кленсин , ноябрь 2011 г. (устаревает RFC 4409 от 2006 г., который, в свою очередь, заменил RFC 2476 от декабря 1998 г.).
- RFC 4422 , Простой уровень аутентификации и безопасности (SASL) , Алексей Мельников и Курт Д. Зейленга, июнь 2006 г.
- RFC 4616 , Механизм PLAIN SASL , К. Зейленга, ред., август 2006 г.
- RFC 4954 , Расширение службы SMTP для аутентификации , Роберт Симборски и Алексей Мельников, июль 2007 г.
- RFC 7628 , Набор механизмов простой аутентификации и уровня безопасности (SASL) для OAuth , У. Миллс, Т. Шоуолтер и Х. Чофениг, август 2015 г.
Другой
[ редактировать ]- Эрвин Хоффманн, Аутентификация SMTP [Учебник] , последнее редактирование 10 января 2017 г.
См. также
[ редактировать ]- Аутентификация по электронной почте
- Простой протокол передачи почты
- Агент отправки почты
- Номера портов почтового клиента
- Простая аутентификация и уровень безопасности
- Открытая ретрансляция почты
- POP перед SMTP
Ссылки
[ редактировать ]- ^ Соответствующие RFC для справки указаны в #Standards . разделе
- ^ Попечители Университета Индианы (01 апреля 2008 г.). «Что такое открытая ретрансляция почты в Unix?» . Университетские службы информационных технологий . Университет Индианы . Архивировано из оригинала 17 июня 2007 г. Проверено 7 апреля 2008 г.
- ^ Джон Гардинер Майерс (апрель 1995 г.). «Расширение службы SMTP для аутентификации» . IETF . Проверено 30 мая 2010 г.
- ^ Шон Тернер, Лили Чен (март 2011 г.). Обновленные соображения безопасности для дайджеста сообщений MD5 и алгоритмов HMAC-MD5 . IETF . дои : 10.17487/RFC6151 . RFC 6151 .
- ^ Пол Хоффман (1 февраля 1998 г.). «Разрешение ретрансляции в SMTP: опрос» . Консорциум Интернет-почты . Архивировано из оригинала 5 марта 2016 г. Проверено 30 мая 2010 г.
- ^ Пол Хоффман (август 2002 г.). «Разрешение ретрансляции в SMTP: серия опросов» . Консорциум Интернет-почты . Архивировано из оригинала 18 января 2007 г. Проверено 30 мая 2010 г.
- ^ Рэндалл Гелленс (19 января 2005 г.). «Отчет о совместимости отправки сообщений» . IETF . Проверено 5 июля 2019 г.
- ^ «Параметры почты» . IANA Реестр . Проверено 23 июля 2011 г.
- ^ Крис Ньюман (30 апреля 2010 г.). «Проблема взаимодействия: отправка SMTP, STARTTLS, ВНЕШНЯЯ АУТИЗАЦИЯ» . IETF . Проверено 30 мая 2010 г.
- ^ Простой протокол передачи почты . сек. 2.2.1. дои : 10.17487/RFC5321 . РФК 5321 .
Однако для совместимости со старыми соответствующими реализациями клиенты и серверы SMTP ДОЛЖНЫ поддерживать исходные механизмы HELO в качестве запасного варианта.
- ^ К. Мерчисон и М. Криспин, Механизм LOGIN SASL , 28 августа 2003 г., срок действия проекта истек. LOGIN описан как устаревший В документе SASL Mechanisms , но этот механизм все еще используется.
- ^ Протокол Gmail XOAuth2 SASL.