Простой протокол передачи почты - Simple Mail Transfer Protocol

"SMTP" перенаправляется сюда. Информацию о компании по доставке электронной почты см. SMTP (компания). Для протокола передачи коротких сообщений см. GSM 03.40.

Набор интернет-протоколов
Уровень приложения
Транспортный уровень
Интернет-уровень
Связующий слой

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

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

История

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

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

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

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

SMTP стал широко использоваться в начале 1980-х годов. В то время это было дополнением к Программа копирования Unix в Unix (UUCP) mail, который лучше подходил для передачи электронной почты между машинами, которые периодически подключались. SMTP, с другой стороны, работает лучше всего, когда и отправляющая, и принимающая машины все время подключены к сети. Оба используют хранить и пересылать механизм и являются примерами толкать технологии. Хотя Usenet группы новостей по-прежнему распространяются с помощью UUCP между серверами,[9] UUCP как почтовый транспорт практически исчез[10] вместе с "взрыва пути "он используется в качестве заголовков маршрутизации сообщений.[11]

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

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

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

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

Модель обработки почты

Синие стрелки показывают реализацию вариантов SMTP.

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

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

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

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

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

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

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

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

  1. ПОЧТА команда, чтобы установить обратный адрес, также называемый обратным путем,[15] обратный путь,[16] адрес возврата, mfrom или отправитель конверта.
  2. RCPT команда, чтобы установить получателя сообщения. Эту команду можно вводить несколько раз, по одной для каждого получателя. Эти адреса также являются частью конверта.
  3. ДАННЫЕ сигнализировать о начале текст сообщения; содержание сообщения, а не его конверт. Он состоит из Заголовок сообщения и тело сообщения разделенные пустой строкой. DATA на самом деле представляет собой группу команд, и сервер отвечает дважды: один раз на Команда DATA сам, чтобы подтвердить, что он готов принять текст, и во второй раз после последовательности конца данных, принять или отклонить все сообщение.

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

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

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

SMTP против получения почты

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

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

Запуск удаленной очереди сообщений позволяет удаленному узлу начать обработку очереди почты на сервере, чтобы он мог получать предназначенные ему сообщения, отправив соответствующую команду. Оригинал ПОВЕРНУТЬ команда была признана небезопасной[17] и был расширен в RFC  1985 с ETRN команда, которая работает более безопасно с помощью аутентификация метод, основанный на система доменных имен Информация.[18]

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

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

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

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

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

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

В рамках этой системы Интернет-провайдер SMTP-сервер не разрешает доступ пользователям, находящимся за пределами сети провайдера. Точнее, сервер может разрешать доступ только пользователям с 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 от своих клиентов в качестве меры защиты от спама.[19]По той же причине предприятия обычно настраивают свой брандмауэр так, чтобы разрешать исходящий трафик порта 25 только с назначенных почтовых серверов.

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

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

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

S: 220 smtp.example.com ESMTP PostfixC: HELO relay.example.comS: 250 smtp.example.com, рад знакомствуC: ПОЧТА ОТ: S: 250 ХорошоC: RCPT Кому: S: 250 ХорошоC: RCPT Кому: S: 250 ХорошоC: ДАННЫЕS: 354 Завершите данные с помощью . C: От: "Пример Боба"  C: Кому: Пример Алисы  C: Копия: [email protected] C: Дата: Вт, 15 января 2008 г. 16:02:43 -0500C: Тема: Тестовое сообщение C: C: Привет, Алиса. C: Это тестовое сообщение с 5 полями заголовка и 4 строками в теле сообщения. C: Ваш друг, C: BobC:.S: 250 Ok: в очереди как 12345C: ВЫЙТИS: 221 Пока{Сервер закрывает соединение}

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

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

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

В ПОКИДАТЬ команда завершает сеанс. Если у электронного письма есть другие получатели, расположенные в другом месте, клиент ПОКИДАТЬ и подключиться к соответствующему серверу SMTP для последующих получателей после того, как текущий адресат был поставлен в очередь. Информация, которую клиент отправляет в HELO и ПОЧТА ОТ команды добавляются (не показаны в примере кода) в качестве дополнительных полей заголовка сообщения принимающим сервером. Он добавляет Получила и Обратный путь поле заголовка соответственно.

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

Расширенный простой протокол передачи почты

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

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

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

Современные клиенты могут использовать ключевое слово расширения ESMTP. РАЗМЕР чтобы запросить у сервера максимальный размер сообщения, которое будет принято. Старые клиенты и серверы могут пытаться передать сообщения чрезмерного размера, которые будут отклонены после использования сетевых ресурсов, включая время подключения к сетевым ссылкам, которое оплачивается поминутно.[24]

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

S: 220 smtp2.example.com ESMTP PostfixC: EHLO bob.example.comS: 250-smtp2.example.com Привет, bob.example.org [192.0.2.201]S: 250-РАЗМЕР 14680064S: 250-ТРУБОПРОВОДS: 250 ПОМОЩЬ

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

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

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

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

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

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

Ретранслятор почты по запросу

Основная статья: Ретранслятор почты по запросу

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

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

Основная статья: Международная электронная почта

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

Текущая поддержка ограничена, но есть большой интерес к широкому внедрению 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 или же ПОКИДАТЬ.

Каждое расширение службы определяется в утвержденном формате в последующих RFC и регистрируется в Управление по присвоению номеров в Интернете (IANA). Первыми определениями были RFC 821 дополнительные услуги: ОТПРАВИТЬ, SOML (Отправить или по почте), SAML (Отправить и отправить по почте), EXPN, ПОМОЩЬ, и ПОВЕРНУТЬ. Был установлен формат дополнительных SMTP-глаголов и для новых параметров в ПОЧТА и RCPT.

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

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

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

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

8BITMIME

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

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

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

SMTP-AUTH

Основная статья: SMTP аутентификация

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

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

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

SMTPUTF8

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

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

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

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

Основная статья: SMTP аутентификация

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

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

Основные статьи: Оппортунистический TLS и Шифрование электронной почты

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

Фонд электронных рубежей ведет список "STARTTLS Everywhere", аналогично "HTTPS везде «список позволяет проверяющим сторонам обнаруживать других, поддерживающих безопасную связь, без предварительного взаимодействия.[41]

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

Строгая транспортная безопасность SMTP MTA

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

В апреле 2019 года Google Mail объявила о поддержке MTA-STS.[42]

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

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

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

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

Основные статьи: Методы защиты от спама и Email аутентификация

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

Время от времени вносятся предложения по обширному изменению SMTP или его полной замене. Одним из примеров этого является Интернет-почта 2000, but neither it, nor any other has made much headway in the face of the network effect of the huge installed base of classic SMTP. Instead, mail servers now use a range of techniques, including Почта, идентифицированная с помощью DomainKeys, Sender Policy Framework и DMARC, DNSBLs и greylisting to reject or quarantine suspicious emails.

Реализации

There is also SMTP proxy implementation as for example nginx.[43]

Основные статьи: Список программного обеспечения почтового сервера и Сравнение почтовых серверов

Related requests for comments

  • RFC  1123 – Requirements for Internet Hosts—Application and Support (STD 3)
  • RFC  1870 – SMTP Service Extension for Message Size Declaration (оbsoletes: RFC  1653 )
  • RFC  2505 – Anti-Spam Recommendations for SMTP MTAs (BCP 30)
  • RFC  2821 – Simple Mail Transfer Protocol
  • RFC  2920 – SMTP Service Extension for Command Pipelining (STD 60)
  • RFC  3030 – SMTP Service Extensions for Transmission of Large and Binary MIME Messages
  • RFC  3207 – SMTP Service Extension for Secure SMTP over Transport Layer Security (obsoletes RFC  2487 )
  • RFC  3461 – SMTP Service Extension for Delivery Status Notifications (obsoletes RFC  1891 )
  • RFC  3463 – Enhanced Status Codes for SMTP (obsoletes RFC  1893, updated by RFC  5248 )
  • RFC  3464 – An Extensible Message Format for Delivery Status Notifications (obsoletes RFC  1894 )
  • RFC  3798 – Message Disposition Notification (updates RFC  3461 )
  • RFC  3834 – Recommendations for Automatic Responses to Electronic Mail
  • RFC  3974 – SMTP Operational Experience in Mixed IPv4/v6 Environments
  • RFC  4952 – Overview and Framework for Internationalized Email (updated by RFC  5336 )
  • RFC  4954 – SMTP Service Extension for Authentication (obsoletes RFC  2554, updates RFC  3463, updated by RFC  5248 )
  • RFC  5068 – Email Submission Operations: Access and Accountability Requirements (BCP 134)
  • RFC  5248 – A Registry for SMTP Enhanced Mail System Status Codes (BCP 138) (updates RFC  3463 )
  • RFC  5321 – The Simple Mail Transfer Protocol (obsoletes RFC  821 aka STD 10, RFC  974, RFC  1869, RFC  2821, updates RFC  1123 )
  • RFC  5322 – Internet Message Format (obsoletes RFC  822 aka STD 11, and RFC  2822 )
  • RFC  5504 – Downgrading Mechanism for Email Address Internationalization
  • RFC  6409 – Message Submission for Mail (STD 72) (obsoletes RFC  4409, RFC  2476 )
  • RFC  6522 – The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (obsoletes RFC  3462, и, в свою очередь RFC  1892 )
  • RFC  6531 – SMTP Extension for Internationalized Email Addresses (updates RFC  2821, RFC  2822, RFC  4952, и RFC  5336 )
  • RFC  8314 – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access

List of supporting servers

List of supporting clients

List of supporting content filters

Смотрите также

Примечания

  1. ^ История электронной почты, Том Ван Влек: "It is not clear this protocol was ever implemented"
  2. ^ The First Network Email, Рэй Томлинсон, BBN
  3. ^ Picture of "The First Email Computer " by Dan Murphy, a PDP-10
  4. ^ Dan Murphy's TENEX and TOPS-20 Papers В архиве 18 ноября 2007 г. Wayback Machine
  5. ^ RFC  2235
  6. ^ RFC  469 – Network Mail Meeting Summary
  7. ^ RFC  524 – A Proposed Mail Protocol
  8. ^ RFC  772 – Mail Transfer Protocol
  9. ^ Tldp.org
  10. ^ draft-barber-uucp-project-conclusion-05 – The Conclusion of the UUCP Mapping Project
  11. ^ The article about sender rewriting contains technical background info about the early SMTP history and source routing before RFC  1123.
  12. ^ Eric Allman (1983), Sendmail – An Internetwork Mail Router (PDF), BSD UNIX documentation set, Berkeley: University of California, получено 29 июня, 2012
  13. ^ Craig Partridge (2008), The Technical Development of Internet Email (PDF), IEEE Annals of the History of Computing, 30, IEEE Computer Society, pp. 3–29, Дои:10.1109/MAHC.2008.32, S2CID  206442868, заархивировано из оригинал (PDF) 12 мая 2011 г.
  14. ^ Джон Кленсин (Октябрь 2008 г.). "Basic Structure". Простой протокол передачи почты. IETF. сек. 2.1. Дои:10.17487 / RFC5321. RFC 5321. Получено 16 января, 2016.
  15. ^ "The MAIL, RCPT, and DATA verbs", [D. J. Bernstein]
  16. ^ RFC  5321 Section-7.2
  17. ^ RFC  1985, SMTP Service Extension for Remote Message Queue Starting, J. De Winter, The Internet Society (August 1996)
  18. ^ Systems, Message. "Message Systems Introduces Latest Version Of Momentum With New API-Driven Capabilities". www.prnewswire.com. Получено 19 июля, 2020.
  19. ^ Cara Garretson (2005). "ISPs Pitch In to Stop Spam". Компьютерный мир. Получено 18 января, 2016. Last month, the Anti-Spam Technical Alliance, formed last year by Yahoo, America Online, EarthLink, and Microsoft, issued a list of antispam recommendations that includes filtering Port 25.
  20. ^ RFC  5321, Простой протокол передачи почты, J. Klensin, The Internet Society (October 2008)
  21. ^ RFC  1047
  22. ^ rfc5321#section-4.5.3.2.6
  23. ^ John Klensin; Ned Freed; Marshall T. Rose; Einar A. Stefferud; Dave Crocker (November 1995). SMTP Service Extensions. IETF. Дои:10.17487/RFC1869. RFC 1869.
  24. ^ "MAIL Parameters". IANA. Получено 3 апреля, 2016.
  25. ^ Which was obsoleted in 2011 by RFC  6152 corresponding to the then new ЗППП 71
  26. ^ "MAIL Parameters". 15 ноября 2018.
  27. ^ Jiankang Yao (December 19, 2014). "Chinese email address". EAI (Список рассылки). IETF. Получено 24 мая, 2016.
  28. ^ "SMTP Service Extension Parameters". IANA. Получено 5 ноября, 2013.
  29. ^ James Server - ChangeLog. James.apache.org. Проверено 17 июля 2013.
  30. ^ 8BITMIME service advertised in response to EHLO on gmail-smtp-in.l.google.com port 25, checked 23 November 2011
  31. ^ Qmail bugs and wishlist. Home.pages.de. Проверено 17 июля 2013.
  32. ^ The 8BITMIME extension. Cr.yp.to. Проверено 17 июля 2013.
  33. ^ "Postfix SMTPUTF8 support is enabled by default", February 8, 2015, postfix.org
  34. ^ а б c "Message Systems Introduces Latest Version Of Momentum With New API-Driven Capabilities" (Пресс-релиз). Ошибка цитирования: указанная ссылка ": 0" была определена несколько раз с разным содержанием (см. страница помощи).
  35. ^ "Version 6.2 Revision History". CommuniGate.com.
  36. ^ Sam Varshavchik (September 18, 2018). "New releases of Courier packages". courier-announce (Список рассылки).
  37. ^ changelog
  38. ^ "MS-OXSMTP: Simple Mail Transfer Protocol (SMTP) Extensions". 24 июля 2018.
  39. ^ "EAI Readiness in TLDs" (PDF). 12 февраля 2019.
  40. ^ "Communications Messaging Server Release Notes". oracle.com. Октябрь 2017 г.
  41. ^ "STARTTLS Everywhere". EFF. Получено 15 августа, 2019.
  42. ^ а б Cimpanu, Catalin. "Gmail becomes first major email provider to support MTA-STS and TLS Reporting". ZDNet. Получено 25 апреля, 2019.
  43. ^ "NGINX Docs | Configuring NGINX as a Mail Proxy Server".
  44. ^ https://bugzilla.mozilla.org/show_bug.cgi?id=1563891
  45. ^ Martinec, Mark. "ANNOUNCE: amavisd-new-2.10.0 has been released". Получено 1 октября, 2019.

Рекомендации


внешняя ссылка