Простой протокол передачи почты ( SMTP ) — это стандартный протокол связи Интернета для передачи электронной почты . Почтовые серверы и другие агенты передачи сообщений используют SMTP для отправки и получения почтовых сообщений. Почтовые клиенты пользовательского уровня обычно используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции и обычно отправляют исходящую электронную почту на почтовый сервер через порт 587 или 465 в соответствии с RFC 8314. Для получения сообщений используется IMAP (который заменил старый POP3 ). стандарт, но проприетарные серверы также часто реализуют проприетарные протоколы, например Exchange ActiveSync .
Истоки SMTP начались в 1980 году и основывались на концепциях, реализованных в ARPANET с 1971 года. Он неоднократно обновлялся, изменялся и расширялся. Широко используемая сегодня версия протокола имеет расширяемую структуру с различными расширениями для аутентификации , шифрования , передачи двоичных данных и интернационализированных адресов электронной почты . Серверы SMTP обычно используют протокол управления передачей через порты 25 (для открытого текста) и 587 (для зашифрованной связи).
В 1960-х годах использовались различные формы индивидуального электронного обмена сообщениями . Пользователи общались с помощью систем, разработанных для конкретных мэйнфреймов . Поскольку все больше компьютеров были соединены между собой, особенно в сети ARPANET правительства США , были разработаны стандарты, позволяющие обмениваться сообщениями между различными операционными системами.
Почта в ARPANET берет свое начало в 1971 году: протокол почтового ящика, который не был реализован [1] , но обсуждается в RFC 196; и программу SNDMSG , которую в том же году Рэй Томлинсон из BBN адаптировал для отправки сообщений на два компьютера в сети ARPANET. [2] [3] [4] Дальнейшее предложение по почтовому протоколу было сделано в RFC 524 в июне 1973 года, [5] которое не было реализовано. [6]
Использование протокола передачи файлов (FTP) для «сетевой почты» в ARPANET было предложено в RFC 469 в марте 1973 года. [7] Через RFC 561, RFC 680, RFC 724 и, наконец, RFC 733 в ноябре 1977 года стандартизированный Разработана система «электронной почты» с использованием почтовых FTP-серверов. [8]
SMTP вырос из этих стандартов, разработанных в 1970-х годах.
В 1980 году Джон Постел и Сюзанна Слейзер опубликовали RFC 772, в котором предлагался протокол передачи почты в качестве замены использования FTP для почты. RFC 780 от мая 1981 года удалил все ссылки на FTP и выделил порт 57 для TCP и UDP , [ требуется цитирование ] и с тех пор IANA удалила этот порт . В ноябре 1981 года Postel опубликовала RFC 788 «Простой протокол передачи почты».
Стандарт SMTP был разработан примерно в то же время, что и Usenet , сеть связи «один ко многим», имеющая некоторые сходства. [ нужна цитата ]
SMTP стал широко использоваться в начале 1980-х годов. В то время это было дополнением к программе копирования Unix в Unix (UUCP), которая лучше подходила для обработки передачи электронной почты между компьютерами, которые периодически подключались. SMTP, с другой стороны, работает лучше всего, когда и отправляющая, и принимающая машины постоянно подключены к сети. Оба использовали механизм хранения и пересылки и являются примерами технологии push . Хотя группы новостей Usenet по-прежнему распространялись между серверами с помощью UUCP, [9] UUCP как почтовый транспорт практически исчез [10] вместе с « путями взрыва », которые он использовал в качестве заголовков маршрутизации сообщений. [11]
Sendmail , выпущенный вместе с версией 4.1cBSD в 1983 году, был одним из первых агентов передачи почты, реализовавших SMTP. [12] Со временем, когда BSD Unix стала самой популярной операционной системой в Интернете, Sendmail стал самым распространенным MTA (агентом передачи почты). [13]
Исходный протокол SMTP поддерживал только неаутентифицированные незашифрованные 7-битные текстовые сообщения ASCII, подверженные тривиальной атаке «человек посередине» , спуфингу и спаму , а также требующие кодирования любых двоичных данных в читаемый текст перед передачей. Из-за отсутствия надлежащего механизма аутентификации каждый SMTP-сервер по своей конструкции представлял собой открытый ретранслятор почты . Консорциум Интернет-почты (IMC) сообщил, что 55% почтовых серверов были открытыми ретрансляторами в 1998 году, [ 14 ] но менее 1% в 2002 году . SMTP принципиально непрактичен для общего использования в Интернете.
В ноябре 1995 года RFC 1869 определил расширенный простой протокол передачи почты (ESMTP), который установил общую структуру для всех существующих и будущих расширений, целью которых было добавление функций, отсутствующих в исходном SMTP. ESMTP определяет согласованные и управляемые средства, с помощью которых можно идентифицировать клиентов и серверы ESMTP, а серверы могут указывать поддерживаемые расширения.
Отправка сообщений ( RFC 2476) и SMTP-AUTH ( RFC 2554) были представлены в 1998 и 1999 годах, описывая новые тенденции в доставке электронной почты. Первоначально SMTP-серверы обычно были внутренними по отношению к организации, получали почту для организации извне и ретранслировали сообщения из организации во внешнюю среду . Но со временем SMTP-серверы (агенты передачи почты) на практике расширили свою роль и стали агентами отправки сообщений для почтовых пользовательских агентов , некоторые из которых теперь ретранслировали почту из-за пределов организации. (например, руководитель компании хочет отправить электронную почту во время поездки, используя корпоративный SMTP-сервер.) Эта проблема, возникшая вследствие быстрого расширения и популярности Всемирной паутины , означала, что SMTP должен был включать определенные правила и методы для ретрансляции почты. и аутентификацию пользователей для предотвращения злоупотреблений, таких как пересылка нежелательной электронной почты ( спама ). Работа над отправкой сообщений ( RFC 2476) изначально была начата потому, что популярные почтовые серверы часто переписывали почту, пытаясь исправить в ней проблемы, например, добавляя доменное имя к неквалифицированному адресу. Такое поведение полезно, когда исправляемое сообщение является первоначальной отправкой, но опасно и вредно, когда сообщение исходит из другого места и ретранслируется. Четкое разделение почты на отправку и ретрансляцию рассматривалось как способ разрешить и поощрять переписывание отправок, одновременно запрещая переписывание ретрансляции. Поскольку спам стал более распространенным, его также стали рассматривать как способ авторизации почты, отправляемой из организации, а также отслеживаемости. Такое разделение ретрансляции и отправки быстро стало основой современных методов обеспечения безопасности электронной почты.
Поскольку этот протокол изначально был основан исключительно на тексте ASCII , он плохо справлялся с двоичными файлами или символами многих языков, отличных от английского. Такие стандарты, как многоцелевые расширения почты Интернета ( MIME ), были разработаны для кодирования двоичных файлов для передачи через SMTP. Агенты передачи почты (MTA), разработанные после Sendmail , также имели тенденцию реализовывать 8-битную чистоту , так что альтернативную стратегию «просто отправить восемь» можно было использовать для передачи произвольных текстовых данных (в любой 8-битной кодировке символов, подобной ASCII) через SMTP. Mojibake по-прежнему оставался проблемой из-за различий в сопоставлении наборов символов у разных поставщиков, хотя сами адреса электронной почты по-прежнему допускали использование только ASCII . Сегодня 8-битные MTA, как правило, поддерживают расширение 8BITMIME, что позволяет передавать некоторые двоичные файлы почти так же легко, как обычный текст (ограничения на длину строки и разрешенные значения октетов все еще применяются, поэтому кодирование MIME необходимо для большинства нетекстовых файлов). данные и некоторые текстовые форматы). В 2012 году SMTPUTF8было создано расширение для поддержки текста UTF-8 , позволяющее использовать международный контент и адреса, написанные нелатиницей, например кириллицей или китайским языком .
Многие люди внесли свой вклад в разработку основных спецификаций SMTP, среди них Джон Постел , Эрик Оллман , Дэйв Крокер, Нед Фрид , Рэндалл Гелленс, Джон Кленсин и Кейт Мур .
Электронная почта отправляется почтовым клиентом ( агент пользователя почты , MUA) на почтовый сервер ( агент отправки почты , MSA) с использованием SMTP через TCP- порт 587. Большинство поставщиков почтовых ящиков по-прежнему разрешают отправку через традиционный порт 25. MSA доставляет почту на свой адрес. агент передачи почты (MTA). Зачастую эти два агента представляют собой экземпляры одного и того же программного обеспечения, запущенного с разными опциями на одном компьютере. Локальная обработка может выполняться либо на одной машине, либо распределяться между несколькими машинами; Процессы почтового агента на одной машине могут совместно использовать файлы, но если обработка происходит на нескольких машинах, они передают сообщения между собой с помощью SMTP, где каждая машина настроена на использование следующей машины в качестве смарт- хоста . Каждый процесс сам по себе является MTA (SMTP-сервером).
Граничный MTA использует DNS для поиска записи MX (почтового обменника) для домена получателя (часть адреса электронной почты справа от @). Запись MX содержит имя целевого MTA. На основе целевого хоста и других факторов отправляющий MTA выбирает сервер-получатель и подключается к нему для завершения обмена почтой.
Передача сообщений может происходить в одном соединении между двумя MTA или в серии переходов через промежуточные системы. Принимающий SMTP-сервер может быть конечным пунктом назначения, промежуточным «ретранслятором» (то есть он хранит и пересылает сообщение) или «шлюзом» (то есть он может пересылать сообщение, используя какой-либо протокол, отличный от SMTP). Согласно разделу 2.1 RFC 5321, каждый переход представляет собой формальную передачу ответственности за сообщение, при этом принимающий сервер должен либо доставить сообщение, либо должным образом сообщить о неспособности сделать это.
Как только конечный узел принимает входящее сообщение, он передает его агенту доставки почты (MDA) для локальной доставки. MDA сохраняет сообщения в соответствующем формате почтового ящика . Как и при отправке, этот прием может осуществляться с использованием одного или нескольких компьютеров, но на схеме выше MDA изображен в виде одного ящика рядом с ящиком почтового обменника. MDA может доставлять сообщения непосредственно в хранилище или пересылать их по сети с использованием SMTP или другого протокола, такого как протокол локальной передачи почты (LMTP), производного SMTP, разработанного для этой цели.
После доставки на локальный почтовый сервер почта сохраняется для пакетного получения аутентифицированными почтовыми клиентами (MUA). Почта извлекается приложениями конечных пользователей, называемыми почтовыми клиентами, с использованием протокола доступа к сообщениям в Интернете (IMAP), протокола, который одновременно облегчает доступ к почте и управляет сохраненной почтой, или протокола почтового отделения (POP), который обычно использует традиционную почту mbox . формате файла или собственной системе, такой как Microsoft Exchange/Outlook или Lotus Notes / Domino . Клиенты веб-почты могут использовать любой метод, но протокол получения часто не является формальным стандартом.
SMTP определяет транспорт сообщений , а не их содержимое . Таким образом, он определяет почтовый конверт и его параметры, такие как отправитель конверта , но не заголовок (кроме информации трассировки ) и не тело самого сообщения. STD 10 и RFC 5321 определяют SMTP (конверт), а STD 11 и RFC 5322 определяют сообщение (заголовок и тело), формально называемое форматом интернет-сообщения .
SMTP — это текстовый протокол , ориентированный на соединение , в котором отправитель почты взаимодействует с получателем почты, выдавая командные строки и предоставляя необходимые данные по надежному каналу упорядоченного потока данных, обычно через соединение протокола управления передачей (TCP). Сеанс SMTP состоит из команд, исходящих от SMTP- клиента (инициирующего агента , отправителя или передатчика) и соответствующих ответов от SMTP- сервера (прослушивающего агента или получателя), так что сеанс открывается и происходит обмен параметрами сеанса. Сеанс может включать ноль или более транзакций SMTP. Транзакция SMTP состоит из трех последовательностей команд/ответов:
Помимо промежуточного ответа для DATA, ответ каждого сервера может быть как положительным (коды ответа 2xx), так и отрицательным. Отрицательные ответы могут быть постоянными (коды 5xx) или временными (коды 4xx). Отклонение — это постоянный сбой, и клиент должен отправить сообщение о возврате на сервер, с которого он его получил . Удаление — это положительный ответ, за которым следует отбрасывание сообщения, а не его доставка .
Инициирующий хост, SMTP-клиент, может быть либо почтовым клиентом конечного пользователя , функционально идентифицируемым как почтовый пользовательский агент (MUA), либо агентом передачи почты (MTA) сервера ретрансляции , то есть SMTP-сервером, действующим как SMTP-клиент. , в соответствующем сеансе, для ретрансляции почты. Полноценные SMTP-серверы поддерживают очереди сообщений для повторных попыток передачи сообщений, которые привели к временным сбоям.
MUA знает SMTP-сервер исходящей почты из своей конфигурации. Сервер ретрансляции обычно определяет, к какому серверу подключиться, просматривая DNS- запись ресурса MX (Mail eXchange) для доменного имени каждого получателя . Если запись MX не найдена, соответствующий сервер ретрансляции (не все) вместо этого ищет запись A. Серверы ретрансляции также можно настроить на использование смарт-хоста . Сервер ретрансляции инициирует TCP- соединение с сервером через « общеизвестный порт » для SMTP: порт 25 или для подключения к MSA — порт 587. Основное различие между MTA и MSA заключается в том, что для подключения к MSA требуется SMTP-аутентификация .
SMTP — это только протокол доставки. При обычном использовании почта «пересылается» на почтовый сервер назначения (или почтовый сервер следующего перехода) по мере ее поступления. Почта маршрутизируется на основе сервера назначения, а не отдельных пользователей, которым она адресована. Другие протоколы, такие как протокол почтового отделения (POP) и протокол доступа к сообщениям в Интернете (IMAP), специально разработаны для использования отдельными пользователями, получающими сообщения и управляющими почтовыми ящиками . Чтобы позволить периодически подключаемому почтовому серверу получать сообщения с удаленного сервера по требованию, SMTP имеет функцию инициирования обработки очереди почты на удаленном сервере (см. Запуск удаленной очереди сообщений ниже). POP и IMAP — неподходящие протоколы для ретрансляции почты через периодически подключаемые машины; они предназначены для работы после окончательной доставки, когда информация, необходимая для правильной работы ретранслятора почты («почтовый конверт»), удалена.
Запуск удаленной очереди сообщений позволяет удаленному хосту начать обработку почтовой очереди на сервере, чтобы он мог получать предназначенные ему сообщения, отправив соответствующую команду. Исходная TURNкоманда была сочтена небезопасной и была расширена в RFC 1985 командой , которая работает более безопасно с использованием метода аутентификации , основанного на информации системы доменных имен . [19]ETRN
Почтовому клиенту необходимо знать IP-адрес своего исходного SMTP-сервера, и он должен быть указан как часть его конфигурации (обычно указывается как DNS- имя). Этот сервер будет доставлять исходящие сообщения от имени пользователя.
Администраторам серверов необходимо установить некоторый контроль над тем, какие клиенты могут использовать сервер. Это позволяет им бороться со злоупотреблениями, например со спамом . Широко использовались два решения:
В этой системе SMTP-сервер интернет-провайдера не разрешает доступ пользователям, находящимся за пределами сети интернет-провайдера. Точнее, сервер может разрешать доступ только пользователям с IP-адресом, предоставленным интернет-провайдером, что эквивалентно требованию, чтобы они были подключены к Интернету с помощью того же интернет-провайдера. Мобильный пользователь часто может находиться в сети, отличной от сети своего обычного интернет-провайдера, и затем обнаружит, что отправка электронной почты не удалась, поскольку выбранный настроенный SMTP-сервер больше не доступен.
Эта система имеет несколько вариаций. Например, SMTP-сервер организации может предоставлять услуги только пользователям одной сети, обеспечивая это с помощью брандмауэра для блокировки доступа пользователей в более широком Интернете. Или сервер может выполнять проверку диапазона IP-адреса клиента. Эти методы обычно использовались корпорациями и учреждениями, такими как университеты, которые предоставляли SMTP-сервер для исходящей почты только для внутреннего использования внутри организации. Однако большинство этих органов теперь используют методы аутентификации клиентов, как описано ниже.
Если пользователь является мобильным и может использовать разных интернет-провайдеров для подключения к Интернету, такого рода ограничение использования является обременительным, и изменение настроенного адреса SMTP-сервера исходящей электронной почты нецелесообразно. Крайне желательно иметь возможность использовать информацию о конфигурации почтового клиента, которую не нужно менять.
Современные SMTP-серверы обычно требуют аутентификации клиентов по учетным данным, прежде чем разрешить доступ, а не ограничивать доступ по местоположению, как описано ранее. Эта более гибкая система удобна для мобильных пользователей и позволяет им иметь фиксированный выбор настроенного исходящего SMTP-сервера. Аутентификация SMTP , часто сокращенно SMTP AUTH, является расширением SMTP для входа в систему с использованием механизма аутентификации.
Для связи между почтовыми серверами обычно используется стандартный TCP- порт 25, предназначенный для SMTP.
Однако почтовые клиенты обычно этого не используют, вместо этого используют определенные порты «отправки». Почтовые службы обычно принимают электронные письма от клиентов по одному из:
Порт 2525 и другие могут использоваться некоторыми отдельными провайдерами, но никогда официально не поддерживались.
Многие интернет-провайдеры теперь блокируют весь исходящий трафик через порт 25 от своих клиентов. В основном в качестве меры по борьбе со спамом, [20] но также и для устранения более высоких затрат, которые они несут, оставляя его открытым, возможно, за счет взимания большей платы с тех немногих клиентов, которые требуют, чтобы он был открыт.
Типичный пример отправки сообщения по SMTP на два почтовых ящика ( alice и theboss ), расположенных в одном почтовом домене ( example.com ), воспроизводится в следующем сеансе обмена. (В этом примере части диалога имеют префикс S: и C: для сервера и клиента соответственно; эти метки не являются частью обмена.)
После того как отправитель сообщения (SMTP-клиент) устанавливает надежный канал связи с получателем сообщения (SMTP-сервером), сеанс открывается приветствием сервера, обычно содержащим его полное доменное имя (FQDN), в данном случае smtp.example. .com . Клиент инициирует диалог, отвечая командой, HELOидентифицирующей себя в параметре команды с помощью своего полного доменного имени (или литерала адреса, если он недоступен). [21]
S: 220 smtp.example.com ESMTP Postfix C: HELO Relay.example.org S: 250 Здравствуйте, relay.example.org, рад знакомству C: MAIL FROM:<[email protected]> S: 250 Хорошо C: RCPT TO:<[email protected]> S: 250 Ok C: RCPT TO:<[email protected]> S: 250 Ok C: DATA S: 354 Завершить данные с помощью <CR><LF>.<CR ><LF> C: C: C: C: C: C: C: Привет, Алиса.C: Это тестовое сообщение с 5 полями заголовка и 4 строками в теле сообщения.C: Твой друг, C: Боб C: .S: 250 Хорошо: поставлено в очередь под номером 12345 C: QUIT S: 221 Пока {Сервер закрывает соединение}From: "Bob Example" <[email protected]>To: "Alice Example" <[email protected]>Cc: [email protected]Date: Tue, 15 Jan 2008 16:02:43 -0500Subject: Test message
Клиент уведомляет получателя об исходном адресе электронной почты сообщения в MAIL FROMкоманде. Это также адрес возврата или возврата на случай, если сообщение не может быть доставлено. В этом примере сообщение электронной почты отправляется в два почтовых ящика на одном SMTP-сервере: по одному для каждого получателя, указанного в полях заголовка To:и Cc:. Соответствующая команда SMTP RCPT TO: . Каждый успешный прием и выполнение команды подтверждается сервером кодом результата и ответным сообщением (например, 250 Ok).
Передача тела почтового сообщения инициируется командой, DATAпосле которой оно передается дословно построчно и завершается последовательностью конца данных. Эта последовательность состоит из новой строки ( <CR><LF>), одной точки ( .), за которой следует еще одна новая строка ( <CR><LF>). Поскольку тело сообщения может содержать строку только с точкой как часть текста, клиент отправляет две точки каждый раз, когда строка начинается с точки; соответственно, сервер заменяет каждую последовательность двух точек в начале строки на одну. Такой метод экранирования называется точечной загрузкой .
Положительный ответ сервера на сообщение об окончании данных, как показано на примере, подразумевает, что сервер взял на себя ответственность за доставку сообщения. Сообщение может быть дублировано, если в этот момент произошел сбой связи, например, из-за сбоя питания: до тех пор, пока отправитель не получит этот 250 Okответ, он должен считать, что сообщение не было доставлено. С другой стороны, после того как получатель решил принять сообщение, он должен предположить, что сообщение ему доставлено. Таким образом, в течение этого периода времени оба агента имеют активные копии сообщения, которое они попытаются доставить. [22] Вероятность того, что сбой связи произойдет именно на этом этапе, прямо пропорциональна объему фильтрации, которую сервер выполняет над телом сообщения, чаще всего в целях защиты от спама. Ограничение времени ожидания установлено равным 10 минутам. [23]
Команда QUITзавершает сеанс. Если у электронного письма есть другие получатели, расположенные в другом месте, клиент QUITподключится к соответствующему SMTP-серверу для последующих получателей после того, как текущие адресаты будут поставлены в очередь. Информация, которую клиент отправляет в командах HELOи, MAIL FROMдобавляется (не отображается в примере кода) в качестве дополнительных полей заголовка к сообщению принимающим сервером. Он добавляет поля заголовка Receivedи Return-Pathсоответственно.
В некоторых клиентах реализовано закрытие соединения после принятия сообщения ( 250 Ok: queued as 12345), поэтому последние две строки могут быть опущены. Это вызывает ошибку на сервере при попытке отправить 221 Byeответ.
Клиенты узнают о поддерживаемых сервером параметрах, используя EHLOприветствие, как показано ниже, вместо исходного файла HELO. Клиенты возвращаются к этому варианту HELOтолько в том случае, если сервер не поддерживает EHLOприветствие. [24]
Современные клиенты могут использовать ключевое слово расширения ESMTP, SIZEчтобы запросить у сервера максимальный размер принимаемого сообщения. Старые клиенты и серверы могут пытаться передавать сообщения чрезмерного размера, которые будут отклонены после потребления сетевых ресурсов, включая время подключения к сетевым каналам, которое оплачивается поминутно. [25]
Пользователи могут вручную заранее определить максимальный размер, принимаемый серверами ESMTP. Клиент заменяет HELOкоманду на EHLOкоманду.
S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Привет bob.example.org [192.0.2.201] S: 250-SIZE 14680064 S: 250-PIPELINING S : 250 ПОМОЩЬ
Таким образом, smtp2.example.com заявляет, что он может принимать фиксированный максимальный размер сообщения, не превышающий 14 680 064 октетов (8-битных байтов).
В простейшем случае сервер ESMTP объявляет максимум SIZEсразу после получения файла EHLO. Однако согласно RFC 1870 числовой параметр расширения в ответе не является обязательным. Вместо этого клиенты могут при выдаче команды включать числовую оценку размера сообщения, которое они передают, чтобы сервер мог отказаться от приема слишком больших сообщений.SIZEEHLOMAIL FROM
Исходный SMTP поддерживает только один текст ASCII, поэтому любые двоичные данные должны быть закодированы как текст в этом теле сообщения перед передачей, а затем декодированы получателем. Обычно использовались двоичные кодировки текста , такие как uuencode и BinHex .
Для решения этой проблемы была разработана команда 8BITMIME. Он был стандартизирован в 1994 году как RFC 1652 [26]. Он облегчает прозрачный обмен сообщениями электронной почты , содержащими октеты за пределами семибитного набора символов ASCII , путем кодирования их как частей содержимого MIME , обычно кодируемых с помощью Base64 .
Ретрансляция почты по запросу ( ODMR ) — это расширение SMTP, стандартизированное в RFC 2645, которое позволяет периодически подключаемому SMTP-серверу получать электронную почту, поставленную в очередь, при его подключении.
Исходный SMTP поддерживает адреса электронной почты, состоящие только из символов ASCII , что неудобно для пользователей, чей собственный алфавит не основан на латинице или которые используют диакритические знаки , не входящие в набор символов ASCII. Это ограничение было устранено с помощью расширений, включающих UTF-8 в именах адресов. RFC 5336 представил экспериментальную команду [25] , а позже был заменен RFC 6531, который ввел команду. Эти расширения обеспечивают поддержку многобайтовых символов и символов, отличных от ASCII, в адресах электронной почты, например символов с диакритическими знаками и символов других языков, таких как греческий и китайский . [27] UTF8SMTPSMTPUTF8
Текущая поддержка ограничена, но существует большой интерес к широкому внедрению RFC 6531 и связанных с ним RFC в таких странах, как Китай , которые имеют большую базу пользователей, где латиница (ASCII) является иностранным алфавитом.
Как и SMTP, ESMTP — это протокол, используемый для передачи почты Интернета. Он используется как межсерверный транспортный протокол, так и (с ограниченным поведением) протокол отправки почты.
Основной функцией идентификации для клиентов ESMTP является открытие передачи с помощью команды EHLO(Extended HELLO), а не HELO(Hello, исходный стандарт RFC 821). Сервер ответит успешно (код 250), сбоем (код 550) или ошибкой (код 500, 501, 502, 504 или 421), в зависимости от его конфигурации. Сервер ESMTP возвращает код 250 OK в многострочном ответе со своим доменом и списком ключевых слов для обозначения поддерживаемых расширений. Сервер, соответствующий RFC 821, возвращает код ошибки 500, позволяя клиентам ESMTP попробовать либо .HELOQUIT
Каждое расширение услуги определяется в утвержденном формате в последующих RFC и регистрируется в Управлении по присвоению номеров Интернета (IANA). Первыми определениями были дополнительные службы RFC 821: SEND, SOML(Отправить или Почта), SAML(Отправить и Почта), EXPN, HELPи TURN. Был установлен формат дополнительных команд SMTP и для новых параметров в MAILи RCPT.
Некоторые относительно распространенные ключевые слова (не все из них соответствуют командам), используемые сегодня:
8BITMIME – 8-битная передача данных, RFC 6152ATRN – Аутентификация TURNдля ретрансляции почты по требованию , RFC 2645AUTH – Аутентифицированный SMTP, RFC 4954CHUNKING – Разделение на части, RFC 3030DSN – Уведомление о статусе доставки, RFC 3461 (см. «Переменный путь возврата конверта »).ETRN – Расширенная версия команды запуска удаленной очереди сообщений TURN, RFC 1985.HELP – Предоставьте полезную информацию, RFC 821.PIPELINING – Конвейерная обработка команд, RFC 2920.SIZE – Объявление размера сообщения, RFC 1870.STARTTLS – Безопасность транспортного уровня , RFC 3207 (2002 г.).SMTPUTF8 – Разрешить кодировку UTF-8 в именах почтовых ящиков и полях заголовков, RFC 6531.UTF8SMTP – Разрешить кодировку UTF-8 в именах почтовых ящиков и полях заголовков, RFC 5336 (устарело [28] )Формат ESMTP был переформулирован в RFC 2821 (заменяющий RFC 821) и обновлен до последней версии в RFC 5321 в 2008 году. Поддержка команды на серверах стала обязательной и стала обязательным резервным вариантом.EHLOHELO
Нестандартные, незарегистрированные расширения услуг могут использоваться по двустороннему соглашению, эти услуги обозначаются EHLOключевым словом сообщения, начинающимся с «X», и любыми дополнительными параметрами или глаголами, отмеченными аналогичным образом.
Команды SMTP нечувствительны к регистру. Они представлены здесь с заглавной буквы только для акцента. SMTP-сервер, требующий определенного метода капитализации, является нарушением стандарта. [ нужна цитата ]
По крайней мере, следующие серверы рекламируют расширение 8BITMIME:
Следующие серверы можно настроить для объявления 8BITMIME, но не выполнять преобразование 8-битных данных в 7-битные при подключении к ретрансляторам, отличным от 8BITMIME:
Расширение SMTP-AUTH обеспечивает механизм контроля доступа. Он состоит из этапа аутентификации , посредством которого клиент эффективно входит на почтовый сервер во время процесса отправки почты. Серверы, поддерживающие SMTP-AUTH, обычно можно настроить так, чтобы клиенты использовали это расширение, гарантируя, что истинная личность отправителя известна. Расширение SMTP-AUTH определено в RFC 4954.
SMTP-AUTH можно использовать, чтобы разрешить законным пользователям ретранслировать почту, запрещая при этом услугу ретрансляции неавторизованным пользователям, например спамерам . Это не обязательно гарантирует подлинность отправителя конверта SMTP или заголовка RFC 2822 «From:». Например, спуфинг , при котором один отправитель маскируется под кого-то другого, по-прежнему возможен с помощью SMTP-AUTH, если сервер не настроен на ограничение исходящих сообщений адресами, для которых авторизован этот авторизованный пользователь.
Расширение SMTP-AUTH также позволяет одному почтовому серверу сообщать другому, что отправитель прошел проверку подлинности при ретрансляции почты. Обычно для этого требуется, чтобы сервер-получатель доверял серверу-отправителю, а это означает, что этот аспект SMTP-AUTH редко используется в Интернете. [ нужна цитата ]
Поддерживаемые серверы включают в себя:
Доставка почты может осуществляться как по простому тексту, так и по зашифрованному соединению, однако взаимодействующие стороны могут заранее не знать о возможности другой стороны использовать защищенный канал.
Расширения STARTTLS позволяют поддерживать SMTP-серверы для уведомления подключающихся клиентов о том, что они поддерживают зашифрованную связь TLS , и предлагают клиентам возможность обновить свое соединение, отправив команду STARTTLS. Серверы, поддерживающие расширение, по своей сути не получают никаких преимуществ в безопасности от его реализации самостоятельно, поскольку обновление до зашифрованного сеанса TLS зависит от подключающегося клиента, решившего использовать эту опцию, отсюда и термин « оппортунистический TLS» .
STARTTLS эффективен только против атак пассивного наблюдения, поскольку согласование STARTTLS происходит в виде обычного текста, и активный злоумышленник может тривиально удалить команды STARTTLS. Этот тип атаки «человек посередине» иногда называют STRIPTLS , при которой информация о шифровании, отправленная с одного конца, никогда не достигает другого. В этом сценарии обе стороны воспринимают неверные или неожиданные ответы как признак того, что другая сторона не поддерживает должным образом STARTTLS и по умолчанию использует традиционную передачу почты в виде простого текста. [41] Обратите внимание, что STARTTLS также определен для IMAP и POP3 в других RFC, но эти протоколы служат разным целям: SMTP используется для связи между агентами передачи сообщений, а IMAP и POP3 — для конечных клиентов и агентов передачи сообщений.
В 2014 году Electronic Frontier Foundation запустил проект «STARTTLS Everywhere», который, как и список « HTTPS Everywhere », позволял доверяющим сторонам обнаруживать других, поддерживающих безопасную связь, без предварительного обмена данными. Проект прекратил прием заявок 29 апреля 2021 года, и EFF рекомендовал переключиться на DANE и MTA-STS для получения информации о поддержке TLS коллегами. [42]
RFC 8314 официально объявил простой текст устаревшим и рекомендует всегда использовать TLS для отправки почты и доступа к ней, добавляя порты с неявным TLS.
Более новый RFC 8461 2018 года под названием «SMTP MTA Strict Transport Security (MTA-STS)» направлен на решение проблемы активного злоумышленника путем определения протокола, позволяющего почтовым серверам заявлять о своей способности использовать безопасные каналы в определенных файлах на сервере и в определенном DNS . TXT-записи. Проверяющая сторона будет регулярно проверять существование такой записи и кэшировать ее на период времени, указанный в записи, и никогда не обмениваться данными по незащищенным каналам до истечения срока действия записи. [41] Обратите внимание, что записи MTA-STS применяются только к SMTP-трафику между почтовыми серверами, в то время как связь между клиентом пользователя и почтовым сервером защищена транспортным уровнем безопасности с SMTP/MSA, IMAP, POP3 или HTTPS в сочетании с корпоративным или техническая политика. По сути, MTA-STS — это средство распространения такой политики на третьи стороны.
В апреле 2019 года Google Mail объявила о поддержке MTA-STS. [43]
Протоколы, предназначенные для безопасной доставки сообщений, могут выйти из строя из-за неправильной конфигурации или преднамеренного активного вмешательства, что приводит к недоставке сообщений или доставке по незашифрованным или неаутентифицированным каналам. RFC 8460 «Отчеты SMTP TLS» описывает механизм и формат отчетов для обмена статистикой и конкретной информацией о потенциальных сбоях с доменами получателей. Домены-получатели могут затем использовать эту информацию как для обнаружения потенциальных атак, так и для диагностики непреднамеренных неправильных конфигураций.
В апреле 2019 года Google Mail объявила о поддержке отчетов SMTP TLS. [43]
Первоначальная конструкция SMTP не предусматривала возможности аутентификации отправителей или проверки того, что серверы уполномочены отправлять сообщения от их имени, в результате чего возможна подмена электронной почты , которая обычно используется в спаме и фишинге по электронной почте .
Время от времени выдвигаются предложения существенно изменить SMTP или полностью заменить его. Одним из примеров этого является Internet Mail 2000 , но ни он, ни какой-либо другой не добился большого прогресса перед лицом сетевого эффекта огромной установленной базы классического SMTP.
Вместо этого почтовые серверы теперь используют ряд методов, таких как более строгое соблюдение стандартов, таких как RFC 5322, [44] [45] DomainKeys Identified Mail , Sender Policy Framework и DMARC , DNSBL и серые списки для отклонения или карантина подозрительных писем. [46]
В прошлом месяце Технический альянс по борьбе со спамом, созданный в прошлом году Yahoo, America Online, EarthLink и Microsoft, опубликовал список рекомендаций по борьбе со спамом, который включает фильтрацию порта 25.
v4.0: Новая поддержка SMTPUTF8.Обновлено для новых версий