Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Аутентификация 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]

Почты Интернета Консорциум (ИМК) сообщил , что 55% почтовых серверов были открытые ретрансляторы в 1998 году, [5] , но менее чем на 1% в 2002 году [6]

Роль в системе транспорта почты [ править ]

Использование агента отправки почты (MSA), обычно на порту 587, подразумевает SMTP AUTH. Использование MSA поддерживается большинством программного обеспечения [7] и рекомендуется, особенно для поддержки кочующих пользователей, поскольку несколько сетевых концентраторов либо блокируют порт 25, либо используют прокси-серверы SMTP . MSA отвечает за то, чтобы конверт сообщения содержал правильные адреса, и может применять локальные политики для Fromполя заголовка. Проверка того, что отправитель конверта (он же Return-Path) , используемая для SPF и от адреса согласен с аутентификацией идентификатором пользователя является особенно важным для доменов, знаковые сообщения с помощью DKIM .

Ключевые слова, оканчивающиеся на «A», такие как 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-серверC: EHLO client.example.comS: 250-smtp.example.com Привет client.example.comS: 250-АУТ. ДАЙДЖЕСТ GSSAPI-MD5S: 250-РАСШИРЕННЫЕ КОДЫ СТАТУСОВS: 250 STARTTLSC: STARTTLSS: 220 Готов к запуску TLS ... Согласование TLS продолжается.  Другие команды, защищенные слоем TLS ...C: EHLO client.example.comS: 250-smtp.example.com Привет client.example.comS: 250 AUTH GSSAPI DIGEST-MD5 PLAIN C: AUTH PLAIN dGVzdAB0ZXN0ADEyMzQ =S: 235 2.7.0 Аутентификация прошла успешно

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-сервер.

Некоторые примеры протоколов авторизации включают:

Стандарты [ править ]

  • RFC 3207 , SMTP Service Extension for Secure SMTP over Transport Layer Security , Пол Хоффман, февраль 2002 г.
  • RFC 3848 , Регистрация типов передачи ESMTP и LMTP , Крис Ньюман, июль 2004 г.
  • RFC 6409 , Отправка сообщений для почты , Рэндалл Гелленс и Джон К. Кленсин , ноябрь 2011 г. (устарел RFC 4409 с 2006 г., который, в свою очередь, заменил RFC 2476 от декабря 1998 г.).
  • RFC 4422 , Simple Authentication and Security Layer (SASL) , Алексей Мельников и Курт Д. Зейленга, июнь 2006 г.
  • RFC 4616 , The PLAIN SASL Mechanism , K. Zeilenga, Ed., Август 2006 г.
  • RFC 4954 , Расширение службы SMTP для аутентификации , Роберт Симборски и Алексей Мельников, июль 2007 г.
  • RFC 7628 , Набор механизмов уровня простой аутентификации и безопасности (SASL) для OAuth , У. Миллс, Т. Шоуолтер и Х. Чофениг, август 2015 г.

Другое [ править ]

  • Эрвин Хоффманн, Проверка подлинности SMTP [Учебное пособие] , последнее изменение 10 января 2017 г.

См. Также [ править ]

  • E-mail аутентификация
  • Простой протокол передачи почты
  • Агент отправки почты
  • Номера портов почтового клиента
  • Уровень простой аутентификации и безопасности
  • Открытый почтовый ретранслятор
  • POP перед SMTP

Ссылки [ править ]

  1. ^ Соответствующий РЛК для справки указаны в #Standards разделе
  2. ^ Попечители Университета Индианы (2008-04-01). «Что такое открытый почтовый ретранслятор в Unix?» . Услуги университетских информационных технологий . Университет Индианы . Архивировано из оригинала на 2007-06-17 . Проверено 7 апреля 2008 .
  3. ↑ Джон Гардинер Майерс (апрель 1995 г.). «Расширение службы SMTP для аутентификации» . IETF . Проверено 30 мая 2010 .
  4. ↑ Шон Тернер, Лили Чен (март 2011 г.). «Обновленные соображения безопасности для алгоритмов MD5 Message-Digest и HMAC-MD5» . IETF .
  5. ↑ Пол Хоффман (1 февраля 1998 г.). «Разрешение ретрансляции в SMTP: обзор» . Консорциум Интернет-почты . Проверено 30 мая 2010 .
  6. ↑ Пол Хоффман (август 2002 г.). «Разрешение ретрансляции в SMTP: серия обзоров» . Консорциум Интернет-почты . Архивировано из оригинала на 2007-01-18 . Проверено 30 мая 2010 .
  7. ^ Randall Gellens (19 января 2005). «Отчет о совместимости отправки сообщений» . IETF . Проверено 5 июля 2019 .
  8. ^ "Параметры почты" . Реестр IANA . Проверено 23 июля 2011 .
  9. ↑ Крис Ньюман (30 апреля 2010 г.). «Проблема взаимодействия: отправка SMTP, STARTTLS, AUTH EXTERNAL» . IETF . Проверено 30 мая 2010 .
  10. ^ https://tools.ietf.org/html/rfc5321 ; Однако для совместимости со старыми соответствующими реализациями клиенты и серверы SMTP ДОЛЖНЫ поддерживать исходные механизмы HELO в качестве запасного варианта.
  11. ^ К. Мерчисон и М. Криспин, Механизм LOGIN SASL , 28 августа 2003 г., просроченный черновик. LOGIN описан как устаревший вдокументе « Механизмы SASL», но этот механизм все еще используется.