Альфапедия

Простой протокол передачи почты

редактировать
Интернет-протокол, используемый для ретрансляции электронной почты

Простой протокол передачи почты (SMTP ) - это протокол связи для передачи электронной почты. Как Интернет-стандарт, SMTP был впервые определен в 1982 году в RFC 821 и обновлен в 2008 году в RFC <68.>5321 - Расширенные дополнения SMTP, которые являются разновидностью протоколов, широко используемых сегодня. Почтовые серверы и другие агенты передачи сообщений используют SMTP для отправки и получения почтовых сообщений. Серверы SMTP обычно используют протокол управления передачей на порту с номером 25.

Уровень пользователя почтовые клиенты обычно используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции и обычно отправляют исходящую электронную почту на почтовый сервер через порт 587 или 465 согласно RFC 8314. Для получения сообщений стандартными являются IMAP и POP3, но проприетарные серверы также часто реализуют проприетарные протоколы, например, Exchange ActiveSync.

Содержание
  • 1 История
  • 2 Модель обработки почты
  • 3 Обзор протокола
    • 3.1 SMTP и получение почты
    • 3.2 Запуск удаленной очереди сообщений
  • 4 SMTP-сервер исходящей почты
    • 4.1 Ограничения доступа к серверу исходящей почты
      • 4.1.1 Ограничение доступ по местоположению
      • 4.1.2 Аутентификация клиента
      • 4.1.3 Открытое реле
    • 4.2 Порты
  • 5 Пример транспорта SMTP
  • 6 Расширенный простой протокол передачи почты
    • 6.1 Обнаружение дополнительных расширений
    • 6.2 Передача двоичных данных
    • 6.3 Расширения механизма доставки почты
    • 6.4 Ретранслятор почты по запросу
    • 6.5 Расширение интернационализации
    • 6.6 Расширения
      • 6.6.1 8BITMIME
      • 6.6.2 SMTP-AUTH
      • 6.6.3 SMTPUTF8
    • 6.7 Расширения безопасности
      • 6.7.1 Аутентификация SMTP
      • 6.7.2 STARTTLS или «Оппортунистический TLS»
      • 6.7.3 SMTP MTA Strict Transport Security
      • 6.7.4 SMTP TLSОтчетность
  • 7 Спуфинг и рассылка спама
  • 8 Реализации
  • 9 Связанные запросы комментариев
  • 10 Список поддерживаемых серверов
  • 11 Список поддерживаемых клиентов
  • 12 Список поддерживаемых фильтров содержимого
  • 13 См. Также
  • 14 Примечания
  • 15 Ссылки
  • 16 Внешние ссылки
История

В 1960-х годах использовались различные формы индивидуального обмена электронными сообщениями. Пользователи общались с помощью систем, разработанных для конкретных мэйнфреймов. По мере того как все больше компьютеров были связаны между собой, особенно в ARPANET правительства США, были разработаны стандарты, позволяющие обмениваться сообщениями между различными операционными системами. SMTP вырос из этих стандартов, разработанных в 1970-х годах.

SMTP уходит своими корнями в две реализации, описанные в 1971 году: протокол почтового ящика, реализация которого оспаривается, но обсуждается в RFC 196 и другие RFC и программа SNDMSG, которая, согласно RFC 2235, Рэй Томлинсон из BBN изобрела для TENEX компьютеры для отправки почтовых сообщений через ARPANET. В то время к ARPANET было подключено менее 50 хостов.

Дальнейшие реализации включают FTP Mail и почтовый протокол, оба с 1973 года. Разработка продолжалась на протяжении 1970-х годов, пока ARPANET не превратился в современный Интернет примерно в 1980 году. Джон Постел затем предложил протокол передачи почты в 1980 году, который начал устранять зависимость почты от FTP. SMTP был опубликован как RFC 788 в ноябре 1981 года, также Postel.

Стандарт SMTP был разработан примерно в то же время, что и Usenet, сеть связи «один-ко-многим» с некоторым сходством.

SMTP стал широко использоваться в начале 1980-х годов. В то время это было дополнение к почте Unix to Unix Copy Program (UUCP), которая лучше подходила для передачи электронной почты между машинами, которые были периодически соединены. SMTP, с другой стороны, работает лучше всего, когда и отправляющая, и принимающая машины все время подключены к сети. Оба используют механизм store and forward и являются примерами технологии push. Хотя группы новостей Usenet по-прежнему распространяются с помощью UUCP между серверами, UUCP как почтовый транспорт практически исчез вместе с «bang paths », которые он использовал в качестве заголовков маршрутизации сообщений.

Sendmail, выпущенный вместе с 4.1cBSD в 1982 г., вскоре после публикации RFC 788 в ноябре 1981 г., был одним из первых агентов пересылки почты, реализовать SMTP. Со временем, когда BSD Unix стала самой популярной операционной системой в Интернете, Sendmail стал наиболее распространенным MTA (агент передачи почты). Некоторые другие популярные серверные программы SMTP включают Postfix, qmail, Novell GroupWise, Exim, Novell NetMail, Microsoft Exchange Server и Oracle Communications Messaging Server.

Отправка сообщений (RFC 2476 ) и SMTP-AUTH (RFC 2554 ) были представлены в 1998 и 1999 годах, и оба описывают новые тенденции в доставке электронной почты. Первоначально серверы SMTP обычно были внутренними по отношению к организации, принимали почту для организации извне и ретранслировали сообщения из организации извне. Но со временем SMTP-серверы (агенты передачи почты) на практике расширили свои роли и стали агентами отправки сообщений для почтовых пользовательских агентов, некоторые из которых теперь ретранслировали почту. извне организации. (например, руководитель компании желает отправить электронную почту во время поездки с помощью корпоративного SMTP-сервера.) Эта проблема, являющаяся следствием быстрого распространения и популярности World Wide Web, означала, что SMTP должен был включать определенные правила и методы для ретрансляции почты и аутентификации пользователей для предотвращения злоупотреблений, таких как ретрансляция нежелательной электронной почты (спам ). Работа по отправке сообщений (RFC 2476 ) изначально была начата, потому что популярные почтовые серверы часто переписывали почту, пытаясь исправить в ней проблемы, например, добавляя доменное имя. на неквалифицированный адрес. Такое поведение полезно, когда исправляемое сообщение является первоначальной отправкой, но опасно и вредно, когда сообщение отправлено из другого источника и ретранслируется. Четкое разделение почты на отправку и ретрансляцию рассматривалось как способ разрешить и поощрить переписывание отправлений, запретив при этом переписывать ретрансляцию. По мере того, как спам становился все более распространенным, он также рассматривался как способ авторизации почты, отправляемой из организации, а также отслеживаемость. Это разделение ретрансляции и отправки быстро стало основой современных методов защиты электронной почты.

Поскольку этот протокол начинался исключительно на основе текста ASCII, он плохо справлялся с двоичными файлами или символами во многих неанглийских языках. Такие стандарты, как многоцелевые расширения почты Интернета (MIME ), были разработаны для кодирования двоичных файлов для передачи через SMTP. Агенты передачи почты (MTA), разработанные после Sendmail, также имели тенденцию быть реализованными 8-bit-clean, так что для передачи произвольных текстовых данных можно было использовать альтернативную стратегию «просто отправить восемь». (в любой 8-битной кодировке символов, подобной ASCII) через SMTP. Mojibake по-прежнему оставался проблемой из-за различий в отображении наборов символов между поставщиками, хотя сами адреса электронной почты по-прежнему допускали только ASCII. 8-битные MTA сегодня, как правило, поддерживают расширение 8BITMIME, что позволяет передавать некоторые двоичные файлы почти так же легко, как обычный текст (все еще применяются ограничения на длину строки и допустимые значения октетов, так что кодирование MIME требуется для большинства нетекстовых данных и некоторых текстовых форматов). Недавно было создано расширение SMTPUTF8 для поддержки текста UTF-8, позволяющее использовать международный контент и адреса в шрифтах, отличных от Latin, таких как Cyrillic или Китайский.

Многие люди внесли свой вклад в основные спецификации SMTP, среди них Джон Постел, Эрик Аллман, Дэйв Крокер, Нед Фрид, Рэндалл Гелленс, Джон Кленсин и Кейт Мур.

Модель обработки почты
Синие стрелки показывают реализацию вариантов SMTP.

Электронная почта отправляется почтовым клиентом (почтовый агент пользователя, MUA) на почтовый сервер (агент отправки почты, MSA) с использованием SMTP на TCP порт 587. Большинство провайдеров почтовых ящиков по-прежнему разрешают отправку на традиционных порт 25. MSA доставляет почту своему агенту передачи почты (агент передачи почты, MTA). Часто эти два агента являются экземплярами одного и того же программного обеспечения, запущенного с разными параметрами на одной машине. Локальная обработка может выполняться либо на одной машине, либо разделяться между несколькими машинами; Процессы почтового агента на одной машине могут совместно использовать файлы, но если обработка осуществляется на нескольких машинах, они передают сообщения между собой с помощью SMTP, где каждая машина настроена на использование следующей машины в качестве промежуточного хоста. Каждый процесс сам по себе является MTA (SMTP-сервером).

Граничный MTA использует DNS для поиска записи MX (почтового обменника) для домена получателя (часть адреса электронной почты справа от @). Запись MX содержит имя целевого MTA. На основе целевого хоста и других факторов отправляющий MTA выбирает сервер-получатель и подключается к нему для завершения почтового обмена.

Передача сообщения может происходить в одном соединении между двумя MTA или в серии переходов через промежуточные системы. Принимающий SMTP-сервер может быть конечным пунктом назначения, промежуточным «ретранслятором» (то есть он хранит и пересылает сообщение) или «шлюзом» (то есть он может пересылать сообщение, используя какой-либо протокол, отличный от SMTP). Каждый переход - это формальная передача ответственности за сообщение, при которой принимающий сервер должен либо доставить сообщение, либо должным образом сообщить о невозможности сделать это.

Как только последний переход принимает входящее сообщение, он передает его агент доставки почты (MDA) для локальной доставки. MDA сохраняет сообщения в соответствующем формате почтового ящика. Как и в случае с отправкой, этот прием может осуществляться с использованием одного или нескольких компьютеров, но на схеме выше MDA изображен в виде одного ящика рядом с ящиком почтового обменника. MDA может доставлять сообщения непосредственно в хранилище или пересылать их по сети с использованием SMTP или другого протокола, такого как Local Mail Transfer Protocol (LMTP), производного от SMTP, разработанного для этой цели..

После доставки на локальный почтовый сервер почта сохраняется для пакетного извлечения аутентифицированными почтовыми клиентами (MUA). Почта извлекается приложениями конечных пользователей, называемыми почтовыми клиентами, с использованием протокола доступа к сообщениям в Интернете (IMAP), протокола, который одновременно облегчает доступ к почте и управляет сохраненной почтой, или протокол почтового отделения (POP), который обычно использует традиционный формат почтового файла t_dv или проприетарную систему, такую ​​как Microsoft Exchange / Outlook или Lotus Notes / Domino. Webmail клиенты могут использовать любой метод, но протокол поиска часто не является формальным стандартом.

SMTP определяет транспорт сообщений, а не содержимое сообщения. Таким образом, он определяет почтовый конверт и его параметры, такие как отправитель конверта, но не заголовок (за исключением информации трассировки) или тело самого сообщения. STD 10 и RFC 5321 определяют SMTP (конверт), а STD 11 и RFC 5322 определяют сообщение (заголовок и тело), ​​формально называемое форматом Интернет-сообщений.

Обзор протокола

SMTP - это ориентированный на соединение, текстовый протокол, в котором отправитель почты связывается с получателем почты путем выдачи командных строк и предоставления необходимых данных по надежному каналу упорядоченного потока данных, обычно через соединение Протокол управления передачей (TCP). Сеанс SMTP состоит из команд, исходящих от SMTP -клиента (инициирующего агента, отправителя или передатчика) и соответствующих ответов от SMTP сервера (прослушивающего агента, или получатель), чтобы открыть сеанс и обменяться параметрами сеанса. Сеанс может включать в себя ноль или более транзакций SMTP. Транзакция SMTP состоит из трех последовательностей команд / ответов:

  1. MAIL команда, чтобы установить адрес возврата, также называемый обратным путем, обратным путем, адрес возврата, mfrom или отправитель конверта.
  2. RCPT команда, чтобы установить получателя сообщения. Эту команду можно вводить несколько раз, по одной для каждого получателя. Эти адреса также являются частью конверта.
  3. DATA для обозначения начала текста сообщения; содержание сообщения, а не его конверт. Он состоит из заголовка сообщения и тела сообщения, разделенных пустой строкой. DATA на самом деле представляет собой группу команд, и сервер отвечает дважды: один раз на саму команду DATA, чтобы подтвердить, что он готов принять текст, и второй раз после последовательности конца данных, чтобы принять или отклонить все сообщение.

Помимо промежуточного ответа для DATA, ответ каждого сервера может быть положительным (коды ответов 2xx) или отрицательным. Отрицательные ответы могут быть постоянными (коды 5xx) или временными (коды 4xx). reject - это постоянный сбой, и клиент должен отправить сообщение о недоставке на сервер, с которого он его получил. drop - это положительный ответ, за которым следует сброс сообщения, а не доставка.

Инициирующий хост, SMTP-клиент, может быть либо почтовым клиентом конечного пользователя, функционально идентифицированным как почтовый пользовательский агент (MUA), либо ретранслятором. агент передачи почты сервера (MTA), то есть SMTP-сервер, действующий в качестве SMTP-клиента в соответствующем сеансе для ретрансляции почты. Полнофункциональные серверы SMTP поддерживают очереди сообщений для повторных попыток передачи сообщений, которые привели к временным сбоям.

MUA знает SMTP-сервер исходящей почты из его конфигурации. Сервер ретрансляции обычно определяет, к какому серверу подключаться, просматривая запись ресурса MX (Mail eXchange) DNS для каждого доменного имени получателя. Если запись MX не найдена, соответствующий сервер ретрансляции (не все) вместо этого ищет запись A. Серверы ретрансляции также можно настроить для использования интеллектуального хоста. Сервер ретрансляции инициирует соединение TCP с сервером на «широко известном порту » для SMTP: порт 25 или для подключения к MSA, порту 587. Основное различие между MTA и MSA состоит в том, что для подключения к MSA требуется аутентификация SMTP.

SMTP и получение почты

SMTP - это только протокол доставки. При обычном использовании почта "проталкивается" на целевой почтовый сервер (или почтовый сервер следующего перехода) по мере ее поступления. Почта маршрутизируется на основе целевого сервера, а не отдельных пользователей, которым она адресована. Другие протоколы, такие как Post Office Protocol (POP) и Internet Message Access Protocol (IMAP), специально разработаны для использования отдельными пользователями, получающими сообщения и управляющими почтовыми ящиками.. Чтобы разрешить периодически подключенному почтовому серверу получать сообщения с удаленного сервера по запросу, в SMTP есть возможность инициировать обработку очереди сообщений на удаленном сервере (см. Запуск удаленной очереди сообщений ниже). POP и IMAP - неподходящие протоколы для ретрансляции почты периодически подключенными машинами; они предназначены для работы после окончательной доставки, когда информация, важная для правильной работы почтового ретранслятора («почтовый конверт»), была удалена.

Запуск удаленной очереди сообщений

Запуск удаленной очереди сообщений позволяет удаленному узлу начать обработку очереди почты на сервере, чтобы он мог получать предназначенные ему сообщения, отправив соответствующую команду. Исходная команда TURNбыла сочтена небезопасной и была расширена в RFC 1985 с помощью команды ETRN, которая работает более безопасно с использованием метод аутентификации на основе информации системы доменных имен.

SMTP-сервер исходящей почты

почтовый клиент должен знать IP-адрес его исходного SMTP-сервера, который должен быть указан как часть его конфигурации (обычно указывается как имя DNS ). Этот сервер будет доставлять исходящие сообщения от имени пользователя.

Ограничения доступа к серверу исходящей почты

Администраторы сервера должны установить некоторый контроль над тем, какие клиенты могут использовать сервер. Это позволяет им бороться со злоупотреблениями, например, спамом. Обычно используются два решения:

  • В прошлом многие системы налагали ограничения на использование в зависимости от местоположения клиента, разрешая использование только клиентам, чей IP-адрес является тем, который контролируется администраторами сервера. Использование с любого другого IP-адреса клиента запрещено.
  • Современные SMTP-серверы обычно предлагают альтернативную систему, которая требует аутентификации клиентов по учетным данным перед разрешением доступа.

Ограничение доступа по местоположению

В этой системе SMTP-сервер ISP не разрешает доступ пользователям, находящимся за пределами сети ISP. Точнее, сервер может разрешать доступ только пользователям с IP-адресом, предоставленным интернет-провайдером, что эквивалентно требованию, чтобы они были подключены к Интернету с использованием того же самого провайдера. Мобильный пользователь может часто находиться в сети, отличной от сети своего обычного интернет-провайдера, и затем обнаруживает, что отправка электронной почты не выполняется, поскольку настроенный выбор сервера SMTP больше недоступен.

У этой системы есть несколько вариантов. Например, SMTP-сервер организации может предоставлять услуги только пользователям в той же сети, обеспечивая это с помощью брандмауэра, чтобы заблокировать доступ пользователей в более широком Интернете. Или сервер может выполнять проверку диапазона IP-адреса клиента. Эти методы обычно использовались корпорациями и учреждениями, такими как университеты, которые предоставляли SMTP-сервер для исходящей почты только для использования внутри организации. Однако большинство этих органов теперь используют методы аутентификации клиентов, как описано ниже.

Если пользователь является мобильным и может использовать других поставщиков услуг Интернета для подключения к Интернету, такое ограничение использования обременительно, а изменение настроенного адреса SMTP-сервера исходящей электронной почты нецелесообразно. Крайне желательно иметь возможность использовать информацию о конфигурации почтового клиента, которую не нужно изменять.

Аутентификация клиента

Современные серверы SMTP обычно требуют аутентификации клиентов по учетным данным перед разрешением доступа, а не ограничивают доступ по местоположению, как описано ранее. Эта более гибкая система удобна для мобильных пользователей и позволяет им иметь фиксированный выбор настроенного SMTP-сервера исходящей почты. Аутентификация SMTP, часто сокращенно SMTP AUTH, является расширением SMTP для входа в систему с использованием механизма аутентификации.

Открытый ретранслятор

Сервер, который доступен в более широком Интернете и не применяет такого рода ограничения доступа, известен как открытый ретранслятор. В настоящее время это считается плохой практикой, достойной занесения в черный список.

портов

Для связи между почтовыми серверами обычно используется стандартный TCP порт 25, предназначенный для SMTP.

Почтовые клиенты, однако, обычно не используют это, вместо этого используют определенные порты «отправки». Почтовые службы обычно принимают сообщения электронной почты от клиентов по одному из:

  • 587 (Отправка), как это формализовано в RFC 6409 (ранее RFC 2476 )
  • 465 Этот порт объявлен устаревшим после RFC 2487, до выпуска RFC 8314.

Порт 2525 и других использоваться отдельными провайдерами, но никогда официально не поддерживались.

Большинство интернет-провайдеров теперь блокируют весь исходящий трафик через порт 25 своих клиентов в качестве меры защиты от спама. По этой причине предприятия обычно настраивают свой брандмауэр так, чтобы разрешать исходящий трафик порта 25 только со своих назначенных почтовых серверов.

Пример транспорта SMTP

Типичный пример отправки сообщения через SMTP в два почтовых ящика (alice и theboss) расположенный в том же почтовом домене (example.com или localhost.com), воспроизводится в следующем сеансе обмена. (В этом примере части разговора имеют префиксы S: и C :, для server и клиент соответственно; эти метки не являются частью обмена.)

После того, как отправитель сообщения (клиент SMTP) устанавливает надежный канал связи с получателем сообщения (сервер SMTP), сеанс открывается с приветствием сервера, обычно содержащее его полное доменное имя (FQDN), в данном случае smtp.example.com. Клиент инициирует свой диалог, отвечая командой HELO, идентифицируя себя в параметре команды своим полным доменным именем (или адресным литералом, если такового нет).

S: 220smtp.example. com ESMTP Postfix C: HELO relay.example.com S: 250 smtp.example.com, я рад встрече с вами C: MAIL FROM: S: 250 Ok C: RCPT TO: S: 250 Ok C : RCPT TO: S: 250 Ok C: DATA S: 354 Завершить данные с помощью .C: From: "Bob Example" C: To: Alice Example C: Cc: theboss @ example.com C: Дата: Вт, 15 января 2008 г. 16:02:43 -0500 C: Тема: Тестовое сообщение C: C: Привет, Алиса. C: Это тестовое сообщение с 5 полями заголовка и 4 строками в теле сообщения. C: Ваш друг, C: Боб C :. S: 250 Ok: поставлено в очередь как 12345 C: QUIT S: 221 Bye {Сервер закрывает соединение}

Клиент уведомляет получателя исходного адреса электронной почты в MAIL FROMкоманда. Это также адрес возврата или адрес возврата в случае, если сообщение не может быть доставлено. В этом примере сообщение электронной почты отправляется в два почтовых ящика на одном сервере SMTP: по одному для каждого в полях заголовка Комуи Копия. Соответствующая команда SMTP - RCPT TO. Каждый успешный прием и выполнение команды подтвержден сервером с помощью кода результата и ответного сообщения (например, 250 Ok).

Передача тела почтового сообщения с команды ДАННЫЕ, после чего оно передается дословно построчно и завершается последовательность конца данных. Эта последовательность состоит из новой строки (), единственной точки (точка), за которой следует еще одна новая строка. Сообщение может каждый период установить с точкой как часть текста, когда строка отправляет с точки; соответственно, сервер заменяет каждую последовательность из двух точек в начале строки на одну. Такой метод экранирования называется вставкой точек.

Положительный ответ сервера на конец данных, как показано в примере, означает, что сервер взял на себя ответственность за доставку сообщений. Сообщение может быть дублировано, если в это время произошел сбой связи, например из-за нехватки питания: пока отправитель не получит ответ 250, он должен предположить, что сообщение не было доставлено. С другой стороны, после того, как получатель решил принять сообщение. Таким образом, в течение этого промежутка времени у обоих агентов есть активные копии, которые попытаются доставить. Вероятность того, что сбой системы защиты происходит на этом этапе, прямо пропорциональна объему нагрузки, которая выполняет функции в теле сообщения, чаще всего в режиме защиты от спама. Ограничение тайм-аута установлено равным 10 минутам.

Команда QUITзавершает сеанс. Если у электронного письма есть другие получатели, расположенные в другом месте, клиент ВЫЙТИи подключится к соответствующему SMTP-серверу для первого получателя, как текущий адресат был поставлен в очереди. Информация, которую клиент отправляет в командух HELOи MAIL FROM, добавляется (не отображается в примере кода) в качестве дополнительных заголовков сообщений принимающим сервером. Он столб поля заголовка Receivedи Return-Pathсоответственно.

В некоторых клиентах реализовано закрытие соединения после того, как сообщение принято (250 Ok: поставлено в очередь как 12345), поэтому последние две строки могут быть опущены. Это вызывает ошибку на сервере при попытке отправить ответ 221.

Extended Simple Mail Transfer Protocol

Extended SMTP (ESMTP ), иногда называемый Enhanced SMTP, является определением расширений протокола для Стандарт простого протокола передачи почты (SMTP). ESMTP был определен в ноябре 1995 г. в публикации IETF RFC 1869, которая установила общую структуру для всех существующих и будущих расширений. ESMTP определяет согласованные и управляемые средства, с помощью которых могут быть идентифицированы клиенты и серверы ESMTP, а серверы могут указывать поддерживаемые расширения. Исходный протокол SMTP поддерживал только неаутентифицированные незашифрованные текстовые сообщения ASCII, восприимчивые к атакам человек посередине, спуфингу и спама, и требуя, чтобы любые двоичные данные были закодированы в читаемый текст передей передач. В ряде дополнительных расширений указаны механизмы решения этих проблем.

Обнаружение дополнительных расширений

Клиенты изучают поддерживаемые сервером параметры с помощью приветствия EHLO, как показано ниже, вместо исходного HELO(пример над). Клиенты возвращаются к HELO, только если сервер не поддерживает SMTP.

Современные клиенты могут использовать слово расширения ESMTP SIZE, чтобы запросить сервер максимального количества сообщений. размер, который будет принят. Старые клиенты и серверы могут пытаться вызвать чрезмерно большого размера, которые могут быть отклонены после использования сетевых ресурсов, включая подключение к сетевым ссылкам, оплачиваемое поминутно.

Пользователи могут заранее вручную определить максимальный размер, принимаемый ESMTP-серверы. Клиент заменяет команду HELOна команду EHLO.

S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.com S: 250-smtp2.example.com Здравствуйте, bob.example.org [192.0.2.201] S: 250-РАЗМЕР 14680064 S: 250-ТРУБОПРОВОД S: 250 HELP

Таким образом, smtp2.example.com заявляет, что он может принимать фиксированный максимальный размер сообщения, не превышающий 14 680 064 октетов (8- битных байтов).

В простейшем сервере ESMTP объявляет максимальный размер сразу SIZEпосле получения EHLO. Однако в соответствии с RFC 1870 числовой параметр расширения SIZEв ответе EHLOявляется необязательным. Вместо этого клиенты могут при выполнении команды ПОЧТА ОТ: включенная числовая оценка размера передаваемых сообщений, чтобы сервер мог отказаться от передачи сообщений слишком большого размера.

Передача двоичных данных

Исходный SMTP поддерживает только одно тело текста ASCII, поэтому любые двоичные данные необходимо закодировать как текст в этом теле сообщения перед передачей, а декодировать с помощью получателя. Двоичное кодирование текста, такое как uuencode и BinHex, обычно использовалось.

Для решения этой проблемы была предоставлена ​​команда 8BITMIME. Он был стандартизирован в 1994 году как RFC 1652. Он обеспечивает прозрачный обмен сообщениями электронной почты, содержитими октеты за пределами семи -bit ASCII набор символов путем кодирования их как частей содержимого MIME, обычно закодированных с помощью Base64.

расширений механизма доставки почты

ретрансляции почты по требованию

Почтовый ретранслятор по запросу (ODMR ) - это расширение SMTP, стандартизованное в RFC 2645, которое позволяет SMTP-серверу с периодическим подключением получать сообщения электронной почты, помещенные в очередь для него, когда он подключен.

Расширение интернационализации

Исходный SMTP поддерживает адрес электронной почты, состоящий только из символов ASCII, что неудобно для пользователей, используя собственный скрипт не основан на латинице или использовать диакритический знак отсутствует в наборе символов ASCII. Это ограничение было снято с помощью расширений, позволяющих использовать UTF-8 в именах адресов. RFC 5336 представила экспериментальную команду UTF8SMTP, а позже была заменена на RFC 6531, которая введена команда SMTPUTF8. Эти расширения поддержки многобайтовых символов и символов, отличных от ASCII, в адресах электронной почты, например, с диакритическими знаками и другими языковыми символами, такими как греческий и китайский.

Текущая поддержка ограничена, но есть проявляет большой интерес к широкому внедрению RFC 6531 и связанных с ним RFC в таких странах, как Китай с большой базой пользователей, где латиницей (ASCII) является иностранным сценарием.

Расширения

Подобно SMTP, ESMTP - это протокол, используемый для передачи почты Интернета. Он используется как межсерверный транспортный протокол и (с принудительным ограниченным поведением) как протокол отправки почты.

Основная функция идентификации клиентов ESMTP является открытием передачи с помощью команды EHLO(Extended HELLO), а не HELO(привет, исходный RFC 821 стандарт). Сервер ответит успешно (код 250), отказом (код 550) или ошибкой (код 500, 501, 502, 504 или 421), в зависимости от его конфигурации. Сервер ESMTP возвращает код 250 OK в многострочном ответе со своим доменом и списком ключевых слов для обозначения поддерживаемых расширенных. Сервер, соответствующий RFC 821, возвращает код ошибки 500, позволяя клиентам ESMTP попробовать либо HELO, либо QUIT.

Каждое расширение службы определено в утвержденном формате в RFC и зарегистрирован в Управление по присвоению номеров Интернета (IANA). Первыми определениями были дополнительные услуги RFC 821 : SEND, SOML(отправка или почта), SAML(отправка и почта), EXPN, HELPи TURN. Был установлен формат дополнительных SMTP-команд и для новых параметров в MAILи RCPT.

. Некоторые относительно ключевые ключевые слова (не все из них соответствуют командам), используемое сегодня:

Формат ESMTP был изменен в RFC 2821 (заменяющий RFC 821 ) и обновлено до последнего определения в RFC 5321 в 2008 году. Поддержка команды EHLOна серверах стала обязательной, а HELOобозначил требуемый запасной вариант.

Нестандартные, незарегистрированные расширения услуг могут использоваться по двустороннему соглашению, эти услуги обозначаются ключевым словом сообщения EHLO, начинающимся с «X», и любыми дополнительными параметрами или глаголами аналогичным образом. отмечен.

В командах SMTP регистр не учитывается. Они представлены здесь заглавными буквами только для акцента. SMTP-сервер, для которого требуется особый метод использования заглавных букв, является нарушением стандарта.

8BITMIME

По крайней мере следующие серверы объявляют расширение 8BITMIME:

Следующие серверы могут быть настроены для объявления 8BITMIME, но не выполняют преобразование 8-битных данных в 7-битные при подключении к реле, отличным от 8BITMIME:

  • Exim и qmail не преобразует восьмибитные сообщения в семибитные при попытке ретранслировать 8-битные данные партнерам, отличным от 8BITMIME, как того требует RFC. На практике это не вызывает проблем, так как практически все современные почтовые ретрансляторы 8-битные чистые.
  • Microsoft Exchange Server 2003 по умолчанию объявляет 8BITMIME, но ретрансляция на одноранговый узел, отличный от 8BITMIME, приводит к отказу. Это разрешено RFC 6152 раздел 3.

SMTP-AUTH

Расширение SMTP-AUTH обеспечивает механизм управления доступом. Он состоит из этапа аутентификации, через который клиент фактически входит на почтовый сервер в процессе отправки почты. Серверы, поддерживающие SMTP-AUTH, обычно могут быть настроены так, чтобы требовать от клиентов использования этого расширения, гарантируя, что истинная личность отправителя известна. Расширение SMTP-AUTH определено в RFC 4954.

SMTP-AUTH может использоваться, чтобы разрешить легитимным пользователям ретранслировать почту при отказе в обслуживании ретрансляции неавторизованным пользователям, таким как спамеры. Это не обязательно гарантирует подлинность отправителя конверта SMTP или заголовка RFC 2822 «From:». Например, спуфинг, при котором один отправитель маскируется под кого-то другого, по-прежнему возможен с SMTP-AUTH, если только сервер не настроен на ограничение адресов отправителя сообщений адресами, на которые авторизован этот авторизованный пользователь.

Расширение SMTP-AUTH также позволяет одному почтовому серверу указывать другому, что отправитель был аутентифицирован при ретрансляции почты. Обычно для этого требуется, чтобы сервер-получатель доверял серверу-отправителю, а это означает, что этот аспект SMTP-AUTH редко используется в Интернете.

SMTPUTF8

Поддерживающие серверы включают:

Расширения безопасности

Доставка почты может происходить как по простой текстовые и зашифрованные соединения, однако взаимодействующие стороны могут не знать заранее о возможности другой стороны использовать безопасный канал.

Аутентификация SMTP

Аутентификация SMTP, часто сокращенно SMTP AUTH, описывает механизм для клиентского входа в систему, используя любой механизм аутентификации, поддерживаемый сервер. Он в основном используется серверами отправки, где аутентификация является обязательной. Существует несколько RFC, которые предоставляют разные варианты механизмов и обновляют друг друга.

STARTTLS или «Оппортунистический TLS»

Расширения SMTP описывают команду STARTTLS, которая позволяет серверу сообщить клиенту, что он поддерживает шифрованную связь, а клиент - запросить обновление до безопасного канала. STARTTLS эффективен только против атак пассивного наблюдения, поскольку согласование STARTTLS происходит в виде обычного текста, и активный злоумышленник может тривиально удалить команду STARTTLS, такая атака иногда называется STRIPTLS (клиент может подумать, что сервер не отправил заголовок STARTTLS, поэтому не поддерживает STARTTLS, в то время как сервер может подумать, что клиент не ответил на заголовок STARTTLS и, следовательно, не поддерживает STARTTLS). Обратите внимание, что STARTTLS также определен для IMAP и POP3 в других RFC, но эти протоколы по другим целям: SMTP используется для связи между агентами передачи сообщений, а IMAP и POP3 - для завершения. клиенты и агенты передачи сообщений.

Electronic Frontier Foundation ведет список «STARTTLS Everywhere», который, как и список «HTTPS Everywhere », позволяет проверяющим сторонам обнаруживать других, поддерживающих безопасную связь, без предварительного взаимодействия.

RFC 8314 официально объявил обычный текст устаревшим и всегда использовать TLS, добавляя порты с неявным TLS.

SMTP MTA Strict Transport Security

Более новая версия 2018 RFC 8461 под названием «SMTP MTA Strict Transport Security (MTA-STS) »Направлена ​​на решение проблемы активного злоумышленника путем определения протокола для почтовых серверов, декларирующего их способность использовать защищенные каналы в определенных файлах сервера и определенных типов DNS TXT. Проверяющая сторона будет регулярно проверять наличие таких записей и кэшировать ее на время, указанное в записи, и никогда не обмениваться данными по незащищенным каналам до истечения срока действия записи. Обратите внимание, что записи MTA-STS применяются только к SMTP-трафику между почтовыми серверами, в то время как связь между конечным клиентом и почтовым сервером защищена с помощью HTTPS, HTTP Strict Transport Security.

В апреле 2019 года было объявлено о Google Mail. поддержка МТА-СТС.

Отчетность SMTP TLS

Ряд протоколов безопасную доставку сообщений позволяет выйти из строя из-за неправильной конфигурации или преднамеренного активного вмешательства, что приведет к недоставленным сообщениям или доставке через незашифрованные или неаутентифицированные каналы. RFC 8460 «Отчетность по протоколу SMTP TLS» представленный механизм и формат отчетов для обмена статистикой и конкретной информацией о выбранных сбоях с доменами получателя. Затем домены-получатели могут использовать эту информацию как для обнаружения атак, так и для диагностики непреднамеренных ошибок конфигурации.

В апреле 2019 года Google Mail объявила о поддержке SMTP TLS Reporting.

Спуфинг и рассылка спама

В исходной конструкции SMTP не было возможности аутентифицировать отправителей или проверять, что серверы уполномочены отправлять от их имени, в результате чего подмена электронной почты возможна и обычно используется в спаме электронной почты и фишинге.

. Иногда вносятся предложения по значительному изменению SMTP или полностью заменить. Одним из примеров этого является Internet Mail 2000, но ни он, ни какой-либо другой не добились больших успехов перед лицом сетевого эффекта огромной установленной базы классического SMTP. Вместо этого почтовые серверы теперь используйте ряды, включая DomainKeys Identified Mail, Sender Policy Framework и DMARC, DNSBL и <241.>серый список для отклонения или помещения в карантин подозрительных писем.

Реализации

Существует также реализация SMTP-прокси, например, nginx.

Связанные запросы комментариев
  • RFC 1123 - Требования для Интернет -хосты - приложение и поддержка (STD 3)
  • RFC 1870 - Расширение службы SMTP для объявления размера сообщения (устарело: RFC 1653 )
  • RFC 2505 - Рекомендации по защите от спама для MTA SMTP (BCP 30)
  • RFC 2821 - Простой протокол передачи почты
  • RFC 2920 - Расширение службы SMTP для конвейерной обработки команд (STD 60)
  • RFC 3030 - Расширения службы SMTP для передачи больших и двоичных сообщений MIME
  • RFC 3207 - Расширение службы SMTP для безопасного SMTP через безопасность транспортного уровня (устарело RFC 2487 )
  • RFC 3461 - Расширение службы SMTP для уведомлений о состоянии доставки (устарело RFC 1891 )
  • RFC 3463 - Расширенные коды состояния для SMTP (устарело RFC 1893, обновленный с помощью RFC 5248 )
  • RFC 3464 - расширяемый Формат сообщения для уведомлений о статусе доставки (устарел RFC 1894 )
  • RFC 3798 - Уведомление об отправке сообщений (обновления RFC 3461 )
  • RFC 3834 - Рекомендации по автоматическим ответам на электронную почту
  • RFC 4952 - Обзор и структура для интернационализированной электронной почты ( обновлено RFC 5336 )
  • RFC 4954 - Расширение службы SMTP для аутентификации (устарело RFC 2554, обновляет RFC 3463, обновляет RFC 5248 )
  • RFC 5068 - Операции отправки электронной почты: требования к доступу и отчетности (BCP 134)
  • RFC 5248 - Реестр для кодов состояния расширенной почтовой системы SMTP (B CP 138) (обновления RFC 3463 )
  • RFC 5321 - Простой протокол передачи почты (устарел s RFC 821 иначе STD 10, RFC 974, RFC 1869, RFC 2821, обновляет RFC 1123 )
  • RFC 5322 - формат интернет-сообщений (устарело RFC 822 aka STD 11, и RFC 2822 )
  • RFC 5504 - механизм понижения версии для интернационализации адресов электронной почты
  • RFC 6409 - отправка сообщений для почты (STD 72) (устарело RFC 4409, RFC 2476 )
  • RFC 6522 - Тип содержимого Multipart / Report для создания отчетов об административных сообщениях почтовой системы (устарел RFC 3462, и, в свою очередь, RFC 1892 )
  • RFC 6531 - Расширение SMTP для интернационализированных адресов электронной почты (обновления RFC 2821, RFC 2822, RFC 4952 и RFC 5336 )
  • RFC 8314 - Открытый текст считается устаревшим: использование безопасности транспортного уровня (TLS) для отправки и доступа по электронной почте
Список поддерживаемых серверов
  • IceWarp
  • Postfix - для RFC 6531.. RFC 6533.
  • Sendmail патчи не требуются - патч исходного кода, необходимый для поддержки SMTPUTF8
  • HMailServer - бесплатный почтовый сервер для Windows
  • Exim
  • MailEnable - поддержка только в Enterprise Edition
  • MagicMail - конвейерная обработка намеренно не поддерживается
Список поддерживаемых клиентов
Список поддерживаемых фильтров содержимого
  • Amavis (SMTP и LMTP), начиная с версии 2.10.0
См. Также
Примечания
Ссылки
  • Hughes, L (1998). Электронная почта в Интернете: протоколы, стандарты и реализация. Издательство Artech House. ISBN 978-0-89006-939-4.
  • Хант, К. (2003). sendmail Кулинарная книга. O'Reilly Media. ISBN 978-0-596-00471-2.
  • Джонсон, К. (2000). Протоколы электронной почты в Интернете: Руководство разработчика. Эддисон-Уэсли Профессионал. ISBN 978-0-201-43288-6.
  • Лошин, П (1999). Основные стандарты электронной почты: RFC и протоколы стали практичными. Джон Вили и сыновья. ISBN 978-0-471-34597-8.
  • Ротон, Дж. (1999). Руководство программиста по интернет-почте: SMTP, POP, IMAP и LDAP. Эльзевир. ISBN 978-1-55558-212-8.
  • Вуд, Д. (1999). Программирование интернет-почты. О'Рейли. ISBN 978-1-56592-479-6.

.

Внешние ссылки
Последняя правка сделана 2021-06-08 02:04:27
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте