Smtp протокол для чего
Почтовая кухня #2: SMTP
SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи электронной почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.
ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают ESMTP и его расширения.
Сразу отмечу, что в настоящее время SMTP в чистом виде практически не используется, т.к. он даже не поддерживает элементарно авторизацию… Используется ESMTP. Когда/если вы отправляете почту почтовым клиентом (Outlook, Thunderbird, Evolution, TheBat) происходит работа именно по этому протоколу.
Для работы по этому протоколу нужно соединиться с почтовым сервером по определенному порту и отправить некоторую последовательность ESMTP команд.
Команда представляет из себя строку вида
КОМАНДА[пробел]параметр(опционально)
В ответ на команду сервер возвращает строку вида
XXX[пробел]доп. информация
При этом XXX число в ответе сервера обозначает:
2ХХ — команда успешно выполнена
3XX — ожидаются дополнительные данные от клиента
4ХХ — временная ошибка, клиент должен произвести следующую попытку через некоторое время
5ХХ — неустранимая ошибка
Так вот, давайте перейдем ближе к делу — попробуем элементарно отправить e-mail из консоли через какой-нибудь почтовый сервер (не важно, линукс у вас или виндоус). Так будет проще познакомиться с этим протоколом — сразу на практике. Привожу комманды и параллельно объясняю их значение.
Для нашего эксперимента буду использовать почтовый сервер яндекса. Подразумевается, что уже есть там аккаунт…
Сразу предупреждаю, что после соединения все команды нужно вводить максимально быстро, т.к. при задержке около 15 секунд соединение автоматически разрывается. Рекомендую сперва все команды заранее набрать в текстовом редакторе а после просто вставлять их в командную строку.
telnet smtp.yandex.ru 2025 #соединяемся с smtp почтовым сервером. Адрес и порт smtp сервера можно посмотреть в инструкциях на сайте почтовика
Ответ:
Trying 213.180.204.38…
Connected to smtp.yandex.ru.
Escape character is ‘^]’.
220 Yandex ESMTP (NO UCE)(NO UBE) server ready at Mon, 2 Feb 2009 13:47:22 +0300
Код 220 говорит об успешном соединении
EHLO [91.198.212.5] #Приветствуем сервер и отсылаем ему наш внешний IP (IP не обязательно отсылать, можно обойтись просто EHLO, но сервер скорее всего на это ругнется)
UPD: Желательно отправлять даже не IP а доменное имя для этого IP вродеEHLO you.provider.domain без квадратных скобок
Ответ:
250-smtp18.yandex.ru Hello 91.198.212.5
250-SIZE 20971520
250-8BITMIME
250-PIPELINING
250-CHUNKING
250-ENHANCEDSTATUSCODES
250-DSN
250-X-RCPTLIMIT 25
250-AUTH=LOGIN
250-AUTH LOGIN
250-STARTTLS
250 HELP
Сервер принял приветствие и выслал список поддерживаемых команд. Из этого списка нас интересует AUTH LOGIN. Это команда для авторизации на сервере по base64-закодированному логину и паролю. Так вот, нужно заранее подготовить закодированные в base64 пароль и логин от вашей почты. Можно это сделать, например, здесь seriyps.ru/crypt или командой в Linux echo [ваш пароль/логин] | base64
AUTH LOGIN # Сообщаем серверу о намерении пройти авторизацию
Ответ:
Этот самый VXNlcm5hbWU6 — закодированное в base64 слово “Username:”, а номер ответа 3ХХ означает, что сервер ждет от нас дополнительной информации. Не будем его огорчать:
ВАШ_ЛОГИН_ПОЧТЫ_В_BASE_64 #Отправляем ваш логин почты в base64, например dmFzaWFwdXBraW4=
Ответ:
Это, как можно догадаться, “Password:” в base64
ВАШ_ПАРОЛЬ_ПОЧТЫ_В_BASE_64 # Отправляем пароль почты в base64, например MTIzNDU2
Ответ:
т.е. авторизация прошла успешно. Теперь можно отправлять e-mail)
MAIL FROM: vasiapupkin@ya.ru # Сообщаем, что хотим отправить почту с адреса vasiapupkin@ya.ru Адрес может быть любым (в том числе с несуществующих доменов, однако он может проверяться при проверке на спам)
Ответ:
RCPT TO: billy@microsoft.com # Сообщаем, что хотим отправить письмо на адрес billy@microsoft.com
Ответ:
250 2.1.5 Recipient address syntax Ok; rcpt=
DATA # Здесь сообщаем, что начинаем передачу данных.
Ответ:
Т.е. сервер будет считывать введенные в консоли данные до того момента, пока мы не нажмем Энтер точка Энтер (после этой комбинации письмо сразу отправляется)
Два раза Энтер, затем вводим сам текст письма.
Hello, Billy! You’ll die tomorrow!
Энтер. Энтер # Сообщаем, что закончили передачу сообщения
Ответ:
250 2.0.0 accepted; S10436885AbZBBKvs
Т.е. сообщение принято для передачи
Теперь можно отправить еще какое-нибудь письмо (MAIL FROM: RCPT TO:) или завершить сеанс работы
QUIT # Завершаем сеанс
Ответ:
221 2.0.0 smtp18.yandex.ru Out
Connection closed by foreign host.
Это все. Как видно, протокол довольно простой, основные сложности — в формировании самого тела письма.
Конечно, здесь не приведена информация по отправке почты в кодировках текста, отличных от ASCII, не написано про вложенные файлы и MIME но если вам нужны подробности, вот несколько ссылок:
Электронная_почта Wiki
SMTP Wiki
MIME Wiki
rfc5321
При разработке приложений непосредственно с SMTP обычно работать не приходится, для этого используют различные фреймворки или стандартные функции. Для PHP можно посмотреть:
SMTP PEAR расширение
PHPMailer библиотека для работы с электронной почной
Удачных экспериментов!
Протокол SMTP что такое и для чего он нужен
SMTP (Simple Mail Transfer Protocol) — простой протокол передачи почты. Протокол SMTP был создан в 1982 году, а расширенная версия SMTP (ESMTP, Extended SMTP) вышла в 2008 году и используется сейчас.
Архитектура электронной почты
Протокол SMTP используется при передаче электронной почты, возможны два варианта использования:
При передачи почты от агента пользователя почтовому серверу и при передачи писем между почтовыми серверами используется протокол SMTP. Для чтения почты используется протоколы POP3 и IMAP.
Место протокола SMTP в стеке TCP/IP
На практике, почти всегда используется один транспортный протокол TCP и порт 25.
Формат электронного письма
Электронное письмо состоит из трех частей, это конверт, заголовок и тело письма. Команды протокола SMTP находятся только в конверте, именно конверт используется при передачи почты между серверами и почтовыми клиентами и данные в конверты определяются, как почта будет передаваться.
Заголовки и тело письма формально не являются частью протокола SMTP, они задаются в отдельном документе RFC2822. Так как заголовки используются при передаче писем, мы их рассмотрим.
Протокол SMTP, также как и протокол HTTP работает в текстовом режиме, это означает, что нет специального формата пакета, клиент и сервер взаимодействуют друг с другом в режиме запрос-ответ передавая друг другу обычные текстовые строки.
Команды SMTP
Команды SMTP состоят из 4-х символов. Никакой особой причины для этого нет, просто разработчики протокола выбрали такую длину команд. Основные команды перечислены на картинке ниже, есть и другие команды, но они используются значительно реже.
Ответы SMTP
Также как и протокол HTTP, SMTP использует ответы состоящие из двух частей:
Заголовки письма
Заголовки письма формально не являются частью стандарта SMTP.
Пример сеанса SMTP
Рассмотрим пример сеанса SMTP, который используется для отправки письма.
Подключаемся к почтовому серверу по адресу 220 smtp.example.ru ESMTP Postfix на 25 порт. Выдаем команду HELO в которой указываем свой домен. Сервер отвечает сообщением со статусом 250 это означает, что соединение установлено и в текстовом сообщении сервер еще раз пишет свое доменное имя.
Само письмо состоит из двух частей, заголовок и тело сообщения.
После того, как введена точка, сервер понимает, что письмо закончено и выдает сообщение со статусом 250 2.0.0 Ok: queued as 7FD9DC2E0060 сообщение поставлено в очередь для передачи. Выдаем команду QUIT, чтобы закончить сеанс связи. Сервер отвечает сообщением со статусом 221 пока.
Расширение SMTP
В 2008 году появилось расширение SMTP — ESMTP. Там появились новые команды. Вместо команды HELO предлагается использовать команду EHLO — Extended HELO. Если мы хотим использовать расширенную версию SMTP, то при установки соединения вместо команды HELO мы должны указывать команду EHLO.
Примеры других новых команд:
Другое важное изменение в расширенной версии протокола SMTP это возможность использования 8-битных наборов символов. В обычном SMTP можно использовать коды символов состоящие из 7 бит, это латинские буквы, цифры и другие символы из набора. Для того, чтобы передавать кириллицу необходимо было применять различные ухищрения. В расширенной версии SMTP ничего такого делать не надо, можно передавать кириллицу напрямую.
Команда EHLO
Если мы хотим использовать расширенную версию протокола SMTP, то для установки соединения, мы должны использовать команду EHLO и после нее указывать домен отправителя, также, как и для обычной команды HELO.
При получении этой команды, почтовый сервер понимает, что мы хотим использовать расширенную версию протокола SMTP и он выдает нам перечень команд расширенной версии, которые он поддерживает.
Безопасность и спам
Протокол SMTP не содержит механизмов для защиты данных. Адреса, которые вы вводите в поля MAIL FROM в конверте и FROM в заголовке никак не проверяются. Во-первых значения этих полей могут отличаться друг от друга. Во-вторых можно использовать любой почтовый адрес, не обязательно ваш, в том числе другие люди, если знают ваш email адрес могут подставить его в эти поля и отправлять почту якобы от вашего имени.
По умолчанию, протокол SMTP не использует шифрование и все письма, которые передаются через интернет могут быть прочитаны. В расширенной версии протокола SMTP появилась возможность использовать шифрование с помощью команды STARTTLS, но эту возможность мало кто использует.
Другая проблема, которая связана с электронной почтой это спам — рассылка нежелательных сообщений, как правило рекламных. Протокол SMTP не содержит никаких механизмов защиты от спама, но современные почтовые серверы пытаются использовать внешние механизмы.
Например, когда клиент подключился к почтовому серверу, выдал команду HELO, указал свое доменное имя, почтовый сервер выполняет проверку соответствия этого доменного имени IP-адресу клиента. Для этого почтовый сервер выполняет реверсивный DNS запрос на IP-адрес с которого подключился клиент и сравнивает полученное доменное имя с тем, которое указал клиент в команде HELO. Если доменные имена отличаются, то в зависимости от настроек почтовый сервер может не принять сообщение.
Многие почтовые серверы настроены так, чтобы принимать почту только для локальных пользователей, т.е. для тех, у которых есть почтовые ящики в том домене, который они обслуживают. Серверы, которые работают в другом режиме и позволяют передавать почту на любые email адреса в интернете называются открытые релеи. Спамеры с помощью специальных программ ищут открытые релеи в интернете и используют их с помощью массовой рассылки писем. Если почтовый сервер работает в режиме открытого релея, это серьезная недоработка администратора этого сервера.
Также есть возможность проверки адреса отправителя с помощью цифровой подписи, для этого также используются взаимодействия с системой DNS. В DNS записях специального вида хранится открытый ключ электронной подписи для данного домена и этот открытый ключ можно использовать для проверки подлинности адреса отправителя.
Заключение
Протокол SMTP — простой протокол передачи почты. Он используется для передачи почтовых сообщений от агента пользователя на почтовый сервер или для передачи почты между разными почтовыми серверами.
SMTP: как работает, для чего нужен и подходит ли для массовых рассылок
Блочный редактор писем, готовые шаблоны email, формы подписки и автоматизация. Запускайте email-рассылки, чтобы быть на связи со своими клиентами.
Где взять базу? Как сделать красивое письмо? Какие показатели смотреть? Расскажем об этом в бесплатном курсе из 16 писем. Татуировка в каждом письме!
Рассказываем про инструменты для email-рассылок. Обсуждаем лучшие примеры и механики. Говорим о деньгах. Публикуем вакансии.
SMTP (Simple Mail Transfer Protocol) — сетевой протокол, предназначенный для передачи электронной почты. Он используется каждый раз, когда мы отправляем письмо через веб-сервисы (Gmail, Mail.ru), десктопные программы (Outlook, Thunderbird, TheBat) или сервисы рассылок (UniSender).
GMail, Mail.Ru, Yandex и других провайдеров электронной почты можно сравнить с почтовым отделением в вашем районе. Вы приходите туда, указываете на конверте, куда отправлять письмо и отдаёте его почтальону.
SMTP — это всё, что происходит в почтовом отделении, когда вы передали письмо. Например, на почте наклеят марки, проверят посылку на вес, организуют логистику и доставят письмо до адресата.
Тут возникает вопрос: если SMTP такой универсальный, почему нельзя отправлять письма напрямую через него? Можно, но есть несколько «но», о которых я расскажу дальше.
А пока немного теории.
Матчасть: как работает SMTP
Обычному пользователю знание SMTP не нужно, достаточно воспользоваться интерфейсом любого почтовика. С помощью команд из почтовика он будет отправлять запросы к серверу получателя.
Вот пример того, как выглядит общение серверов изнутри (SMTP-сессия):
$ telnet expamle.com 25 — мы пробуем подключиться к example.com по 25 порту, который как раз используется для передачи почты.
Connected to example.com.
Escape character is ‘^]’.
220 mailserver at example.com greets you. Make love not war! — подключение удалось.
250 example.com — поприветствовали друг друга с помощью команды HELO, сервер получателя ответил командой 250, что значит, что возможно дальнейшее «общение».
MAIL FROM: test@test.com > — мы говорим, от кого хотим отправить письмо.
250 2.1.0 Ok — сервер отвечает, что готов принять письмо от этого адресата (бывают ситуации, когда адрес внесен в блэклист на стороне получателя, и тогда уже здесь начнутся ошибки.
RCPT TO: user@example.com > — мы говорим, кому хотим отправить письмо.
250 2.1.5 Ok — сервер отвечает, что готов принять письмо для этого получателя (если адреса не существует, то здесь сервер может сказать что-то вроде 550 No such user here.
DATA — сообщаем серверу, что начинаем передавать письмо.
FROM: test@test.com — начинаем передавать письмо вместе с техническими заголовками.
SUBJECT: test mail from test subject
. — показываем, что мы закончили передачу письма.
250 2.0.0 Ok: queued as 1CF5FC0AAE — сервер отвечает, что принял письмо для доставки и назначил ему id 1CF5FC0AAE (по нему, в случае недоставки, системный администратор принимающего сервера сможет найти, что стало с письмом.
QUIT — сообщаем, что сеанс связи закончен.
221 2.0.0 Bye — сервер прощается с нами.
Connection closed by foreign host. — соединение обрывается.
Это пример самой простой SMTP-сессии. Она может быть намного сложнее, если получателей будет несколько или сервер получателя потребует аутентификацию и шифрование.
Кажется, что мешает подробно изучить документацию по SMTP и отправлять массовые рассылки через своё SMTP-решение? С этим есть проблема.
Предлагаю посмотреть на разные способы отправки массовых рассылок и оценить их по 3 параметрам: необходимость в доработках, доставляемость писем и цена.
Ящик на бесплатной почте
Доработки от разработчиков: ⭐️
Доставляемость массовых рассылок: ⭐️
Почти все почтовые провайдеры (Gmail, Mail.ru) предоставляют доступ к ящику по SMTP. Тем не менее, отправлять массовые рассылки с бесплатной почты не получится.
Преимущества
Ящики на Gmail, Mail.ru или Яндексе бесплатные. На этом преимущества для отправки массовых писем заканчиваются.
Недостатки
Пока вы отправляете небольшое количество писем, вас может устраивать бесплатная почта. Но если подписчиков много, вы столкнётесь с ограничениями по количеству писем:
| Почтовый провайдер | Ограничение |
| Mail.ru | 1 письмо в минуту |
| Yandex.ru | 150 писем в сутки |
| Gmail.com | 500 писем в сутки |
| Rambler.ru | 200 писем в час |
| Ukr.net | 250 писем в сутки |
| Meta.ua | 200 писем в сутки |
Больше писем отправить не дадут. Более того, если мы попробуем перешагнуть через допустимый порог, то ящик заблокируют, а все письма начнут попадать в «Спам».
Почтовые провайдеры не могут допустить, чтобы с их серверов отправляли спам. Он ухудшает репутацию серверов почтовиков — из-за этого даже нормальные письма могут не дойти до «Входящих».
Вывод: не подходит для массовых рассылок.
Почта интернет-провайдера
Доработки от разработчиков: ⭐️
Доставляемость массовых рассылок: ⭐️
Этот способ похож на предыдущий: почта интернет-провайдера подходит для личной переписки, но не для массовых рассылок. Отправка писем идёт через IP-адреса провайдера — они не могут допустить, чтобы через них проходил спам. Поэтому на большинстве таких ящиков тоже стоит ограничение на количество писем в сутки.
Вывод: не подходит для массовых рассылок.
Хостинг
Доработки от разработчиков: ⭐️
Доставляемость массовых рассылок: ⭐️⭐️
Преимущества
Плюсы покупки хостинга — вы получаете email-адрес на том же домене, на котором будет располагаться ваш сайт. Это удобно, допустим, когда у вас есть небольшой интернет-магазин, и вам нужно отправлять сообщения со статусом заказа.
Недостатки
Но когда возникнет необходимость массовых рассылок, вы можете столкнуться с ограничениями и трудностями.
Часто хостинг располагается на общих IP-адресах хостинг провайдера, а это значит, что параллельно с вами на данном IP-адреса может находиться еще кто-то, и отправлять спам. Ваши письма из-за этого тоже будут попадать в спам. Именно из-за этого часто провайдеры ограничивают возможность рассылок для владельцев хостинга, и требуют покупки VPS (виртуального сервера) или выделенного сервера, что приводит нас к следующему пункту.
Вывод: подходит для массовых рассылок, если купить виртуальный сервер и настроить его.
Собственное SMTP-решение
Доработки от разработчиков: ⭐️⭐️⭐️
Доставляемость массовых рассылок: ⭐️⭐️⭐️ (при правильной настройке)
Как мы уже сравнили в начале, SMTP — это про всё, что касается отправки и доставки сообщения до получателя. Что именно отправлять и как отправлять — ваша ответственность. SMTP подходит для всего: транзакционных писем, массовых рассылок или личной переписки.
Преимущества
Простота. SMTP — простой протокол: его легко протестировать и внедрить (особенно, если у вас уже было SMTP-решение до этого).
Вот, что говорит CTO UniSender Александр Брычук:
Преимущество SMTP в том, что его можно быстро проверить, потому что это стандартный протокол. В случае с SMTP ссылки отписки, шаблоны, трекинг тоже может работать. Эту информацию можно передавать в X-заголовках письма. Но для этого нужны доработки.
Использование SMTP требует меньше знаний для внедрения, чем, скажем, использование WEB API (на котором построены сервисы транзакционных писем). SMTP хорошо изучен, для него есть подробная документация. Непредвиденные обстоятельства вроде внезапной смены протокола или изменения работы каких-то методов, сведены к минимуму.
Чтобы запустить SMTP-сервер, нужно разобраться, как работает протокол, и изучить набор необходимых команд.
Подробный отчёт об ошибках. Используя SMTP, вы сразу получаете ответ о доставке или ошибке доставки сообщения. Многие сервисы не дают развернутый ответ о причинах недоставки. Если письмо не дошло, то чаще всего они просто выведут причину: несуществующий адрес, блокировка сообщения как спама.
SMTP-сессия покажет, на каком именно этапе возникла ошибка доставки. Иногда это полезно. Например, если ошибка возникла на этапе передачи данных MAIL FROM (смотрите пример SMTP-сессии), то ваш обратный адрес не нравится серверу получателя.
Недостатки
Грейлистинг. Протокол SMTP требует постоянного общения сервера отправителя и получателя. Недостаточно отправить один запрос на отправку письма. Сначала серверы должны «поздороваться», потом отправитель должен сообщить, от кого письмо, потом предоставить содержание письма. На каждый из этих этапов мы ждём ответ сервера получателя. Когда отправляется одно письмо, трудностей не возникает.
Но когда отправляется много писем, может, например, включиться грейлистинг. Это технология защиты от спама, когда сервер получателя сознательно отвечает вашему SMTP-серверу, что он недоступен. В этом случае SMTP, рассылающие спам, обычно прекращают попытки. Знание о таком поведении необходимо закладывать в логику работы вашего SMTP сервера. Например, в сервисах рассылок повторные попытки отправки автоматизированы — письма лучше доходят до получателей.
Необходимость глубокой доработки. Чтобы настроить полноценный email-маркетинг на своём SMTP-сервере, нужно много доработок. Например, чтобы следить за открытиями и переходами из писем, нужны специальные заголовки или трек-пиксели. И так с каждым инструментом — чтобы его сделать, нужно звать разработчиков.
Вывод: подходит для массовых рассылок, но нужна глубокая доработка со стороны разработчиков.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
SMTP (Simple Mail Transfer Protocol)
| Уровень (по модели OSI): | Прикладной |
|---|---|
| Семейство: | стек протоколов TCP/IP |
| Назначение протокола: | Отправка электронной почты |
| Спецификация: | RFC 5321 |
| Основные реализации (клиенты): | MUA (The Bat!, MS Outlook, MS Outlook Express, Mozilla Thunderbird, Claws Mail и др.) |
| Основные реализации (серверы): | MTA (sendmail, postfix, OpenSMTPD, qmail, exim, Microsoft Exchange Server, MDaemon) |
| Расширяемость: | Доп. команды (RFC 2449) |
| Вступил в силу с: | 1982 |
SMTP (англ. Simple Mail Transfer Protocol ) – протокол передачи сообщений с компьютера на почтовый сервер для доставки конечному получателю. Этот протокол обеспечивает перенаправление почтовых сообщений (с помощью записей MX, или записей программы обмена электронной почтой, и записей А, или записей хоста в системе DNS), форматирование почтовых сообщений и установление сеансов между почтовыми клиентами и почтовыми серверами. В протоколе SMTP в качестве транспортного протокола обычно используется TCP, но могут применяться и другие протоколы, как определено в документе RFC 821.
Содержание
История
Данный протокол зародился в начале 70-х двадцатого века как стандарт, созданный с целью унификации систем связи различных компьютерных систем, которые не имели ничего общего между собой.
В 1971 г. появился Mail Box Protocol и SNDMSG, который был «изобретён» Рэем Томлинсоном из BBN Technologies для TOPS-20/TENEX-компьютеров, посылающих сообщения по ARPANET (в то время к ней были подсоединены менее 50 хостов). Данный протокол можно считать истоком протокола SMTP.
SMTP впервые был описан в RFC 821 (1982 год); последнее обновление в RFC 5321 (2008) включает масштабируемое расширение – ESMTP (англ. Extended SMTP). В настоящее время под «протоколом SMTP», как правило, подразумевают и его расширения. Протокол SMTP предназначен для передачи исходящей почты с использованием порта TCP 25.
Архитектура
Рисунок 1 – Схема взаимодействия по протоколу SMTP
Канал связи устанавливается непосредственно между отправителем и получателем сообщения. При таком взаимодействии почта достигает абонента в течении нескольких секунд после отправки. [Источник 1]
Принцип работы
Протокол SMTP не несет никакой ответственности за прием почты. Это означает, что в спецификации этого протокола не определены способы настройки почтовых ящиков для отдельных пользователей, а также не упоминаются какие-либо иные задачи (такие как аутентификация), которые должны быть решены при приеме электронной почты. В этой спецификации просто указано, как должна осуществляться передача электронной почты от отправителя к получателю.
Но в спецификации SMTP определен формат электронной почты и указано, какие наборы символов могут применяться в сообщениях электронной почты. Первоначально в спецификации SMTP было определено использование только 7-битовых символов ASCII. Но с появлением [MIME (Multipurpose Internet Mail Extensions)|стандарта многоцелевых почтовых расширений Internet (Multipurpose Internet Mail Extensions – MIME)]] и превращением Internet во всемирную сеть было предложено включить в дополнительные спецификации другие наборы символов. Благодаря этому в настоящее время электронное письмо может быть отправлено практически на любом национальном языке, а к письму могут прилагаться в закодированном виде данные почти любого типа, даже такие как изображения или исполняемые файлы. После внедрения всех этих дополнений протокол SMTP стал более сложным, но вместе с тем и более гибким.
Задачи
Обычный ответ SMTP сервера состоит из номера ответа, за которым через пробел следует дополнительный текст. Номер ответа служит индикатором состояния сервера. [Источник 2]
Команды
Каждая команда SMTP начинается с ключевого слова – названия команды. За ним могут следовать параметры, отделенные пробелом.
Регистр символов, используемых во всех названиях команд и, за редким исключением, в параметрах базового протокола SMTP, не имеет значения. Однако в некоторых элементах расширений строчные и прописные символы могут различаться. Необходимо также учитывать, что левая часть почтового адреса, до символа @, может быть регистрозависимой.
Конец строк в протоколе SMTP обозначается последовательностью символов «возврат каретки» (шестнадцатеричный код 0 D ) и «перевод строки» (шестнадцатеричный код 0А). Эта последовательность обозначается CRLF. Сервер начинает выполнение команды только получив от клиента строку, завершающуюся последовательностью CRLF.
Сервера SMTP должны принимать командные строки длинной до 512 символов. Это значение может быть увеличено по желанию разработчиков. Для серверов, поддерживающих расширения ESMTP, требующие дополнительных параметров, максимально допустимая длина командной строки увеличивается. Соответствующие требования приведены в RFC, описывающих эти расширения.
Если не используется расширение, позволяющее серверу принимать несколько команд подряд, клиент передает серверу следующую команду только после получения ответа на предыдущую.
Рассмотрим команды SMTP, необходимые для отправки сообщения.
EHLO (Расширенное HELO)
Диалог клиента и сервера, как правило, начинается с приветствия. В RFC 821 в качестве приветствия предлагалась команда HELO. Однако с введением расширений ESMTP, эта команда была заменена на EHLO. Использование расширений ESMTP возможно только после выполнения команды EHLO.
Передача почты возможна только после выполнения одной из двух названых команд. Другие команды, не связанные с передачей почты ( NOOP, HELP, EXPN, VRFY, RSET и QUIT ), в принципе могут быть исполнены и без приветствия.
В качестве аргумента клиент передает серверу свое полное доменное имя, если таковое имеется. Если клиент не имеет доменного имени, например, если в качестве клиента выступает MUA, установленный на компьютере, получающем адрес динамически, то в качестве аргумента передается адрес электронной почты отправителя. Желательно, чтоб полученная от клиента информация была исчерпывающей для его идентификации.
Сервер проверяет соответствие указанного клиентом в приветствии доменного имени его адресу IP. Результат проверки добавляется к заголовку письма, но диалог продолжается независимо от достоверности полученного сервером идентификатора.
В ответ на команду EHLO сервер присылает список, каждая строка которого содержит ключевое слово, соответствующее расширению, поддерживаемому вызываемым сервером, и, при необходимости, уточняющие параметры. Это единственный предусмотренный базовым протоколом SMTP ответ сервера, в котором клиентская программа должна проанализировать не только числовой код ответа, но и его текст. Из ответа на команду EHLO клиент узнает, какие дополнительные функции он может использовать при отправке сообщения.
Если устаревшее программное обеспечение сервера не поддерживает команду EHLO, то выдается сообщение об ошибке. В этом случае клиент должен попытаться повторить приветствие, используя команду HELO. Естественно, расширениями ESMTP уже не удастся воспользоваться.
HELO (Приветствие)
RFC 2821 рекомендует использовать команду HELO, только если программное обеспечение не поддерживает команду EHLO. Отличие этой команды только в том, что она делает невозможным использование расширений ESMTP.
В ответ на эту команду сервер сообщает, готов ли он к продолжению диалога.
MAIL (Отправитель)
Отправка электронного сообщения невозможна без успешного выполнения этой команды, для каждого письма команда MAIL должна быть выполнена только один раз.
Команда MAIL может быть выполнена только после успешного выполнения команды EHLO или H E LO.
С помощью этой команды серверу сообщается адрес отправителя письма. На этот адрес письмо должно вернуться в случае невозможности доставки. Если возврат не желателен, адрес может быть оставлен пустым: <>:
Обычно это бывает, если отправляемое сообщение уже и есть возвращаемое письмо. Это делается для того, чтобы избежать петли: письмо не может быть доставлено адресату и возвращается отправителю, но, если оно не может быть доставлено отправителю, то посылается обратно и так далее. Если же адрес отправителя не известен, то попытки вернуть его предприниматься не будут: в случае невозможности доставки получателю, письмо будет удалено.
Поскольку базовый протокол SMTP не предусматривает никакой авторизации отправителя, адрес отправителя может быть указан произвольно и не может считаться достоверным. В последние годы большинство MTA проверяют существование почтового домена отправителя и отвергают сообщения с адресами отправителей в несуществующих доменах. К сожалению, более детальная проверка возможна только при использовании дополнительных средств авторизации и обычно не применяется.
Базовый протокол SMTP не предусматривает дополнительных параметров для команды MAIL, но такие параметры использует ряд расширений ESMTP.
RCPT (Получатель)
Доставка сообщения возможна, только если указан хотя бы один доступный адрес получателя. Команда RCPT принимает в качестве аргумента только один адрес. Если нужно послать письмо большему числу адресатов, то команду RCPT следует повторять для каждого. Согласно RFC 2821, сервера SMTP должны быть готовы принять до ста команд RCPT на одно сообщение. Если письмо адресовано большему числу получателей, то для оставшихся клиент должен передать сообщение повторно. Максимальное число получателей может быть изменено администратором.
Команда RCPT может быть выполнена только после успешного выполнения команды MAIL.
Сервер анализирует каждый адрес и после каждой команды RCPT выдает сообщение, свидетельствующее о возможности или невозможности доставки письма по указанному адресу.
Базовый протокол SMTP не предусматривает дополнительных параметров для команды RCPT, но такие параметры использует ряд расширений ESMTP.
DATA (Текст сообщения)
C помощью этой команды серверу передается текст сообщения, состоящий из заголовка и отделенного от него пустой строкой тела сообщения.
Команда DATA может быть выполнена только после успешного выполнения хотя бы одной команды RCPT.
Команда DATA не требует никаких параметров и завершается последовательностью CRLF.
В ответ на правильно введенную команду DATA сервер сообщает о готовности к приему или об ошибке, если прием сообщения невозможен.
В случае положительного ответа сервера, клиент передает сообщение.
Передача заканчивается строкой, состоящей из одной точки. Эта строка не является частью сообщения и удаляется на приемной стороне. Чтобы исключить ложное срабатывание в случае, если сообщение содержит строку, состоящую из одной точки, на передающей стороне к началу каждой строки, начинающейся с точки, добавляется еще одна точка. На приемной стороне добавленные точки удаляются.
Распознав окончание сообщения, сервер должен принять решение о возможности или невозможности доставки и послать соответствующий ответ клиенту. Сделать это следует как можно быстрее, если нет явных свидетельств невозможности доставки сообщения, его рекомендуется принять, сообщив клиенту об успешном завершении операции. Если доставка в последствии окажется невозможна, следует просто отправить письмо обратно, сообщив в квитанции причину отказа. Это делается для того, чтобы избежать проблемы, описанной в RFC1047 : не дождавшись ответа сервера, клиент разрывает соединение, считая передачу закончившейся неудачей, хотя сервер, возможно, позже осуществил доставку. Через некоторое время клиент снова пытается послать то же самое сообщение, что может привести к многократной передаче одного и того же письма. На ожидание ответа после завершения отправки сообщения рекомендуется выделять не меньше десяти минут. На ожидание других ответов отводятся от двух до пяти минут.
Необходимо принимать строки сообщения длиной до 1000 символов, включая последовательность CRLF, но не включая точку, добавляемую в начало строки во избежание ложного обнаружения конца сообщения.
Минимальный размер письма, которое должен принимать сервер SMTP – 64 килобайта, включая как тело сообщения, так и его заголовок.
QUIT (Выход)
Командой QUIT клиент заканчивает диалог с сервером. Сервер посылает подтверждение и закрывает соединение. Получив это подтверждение, клиент тоже прекращает связь.
Перечисленных команд вполне достаточно для того, чтобы передать сообщение. Однако RFC 2821 предусматривает еще ряд команд, которые могут быть использованы в основном в процессе отладки сервера.
HELP (Помощь)
Если команда HELP вызывается без параметров, сервер посылает клиенту список доступных команд. Если в качестве параметра передано название команды, то клиенту посылается описание этой команды. Серверам SMTP рекомендуется поддерживать эту команду без параметров. Описание отдельных команд посылать не обязательно.
VRFY (Проверить), EXPN (Раскрыть)
Команда VRFY используется для проверки наличия указанного в качестве аргумента почтового ящика. В ответ сервер посылает информацию о владельце ящика или сообщение об ошибке, свидетельствующее о том, что указанный ящик не существует.
Если указанный адрес указывает на несколько почтовых ящиков, команда VRFY возвращает список пользователей, внесенных в соответствующую рассылку, либо сообщение об ошибке, свидетельствующее о неоднозначности ответа на полученный запрос.
Для получения адресов, внесенных в список рассылки, используется команда EXPN.
Используя эти команду, злоумышленники могут получить список адресов пользователей сервера.
Обе команды могут быть полезны в процессе отладки сервера, потому они, как правило, поддерживаются. Но на серверах, используемых в реальном окружении, их обычно отключают. Возможен также вариант, при котором вызов команд возможен, но они проверяют только синтаксическую верность адреса.
Согласно RFC 821, команды VRFY и EXPN не являются обязательными. Поэтому, если сервер их поддерживает, они должны быть перечислены в ответе сервера на команду EHLO, как расширения ESMTP.
NOOP (Пустая команда)
В ответ на команду NOOP сервер посылает подтверждение выполнения. Никаких действий на сервере не производится, параметры команды игнорируются.
RSET (Сброс)
Команда RSET аннулирует все переданные до нее на сервер данные. Процесс передачи сообщения следует начать заново.
Перечисленные команды используются вместо команды MAIL для передачи сообщения на терминал получателя (SEND) или в его почтовый ящик, если пользователь не активен или запретил прием сообщений ( SOML ) или и на терминал, и в почтовый ящик (SAML).
Описанные в RFC 821 устаревшими. Если их все же используют, то они должны быть перечислены в ответе на команду EHLO, как расширения ESMTP.
TURN (Смена направления передачи)
Эта команда предназначена для почтовых серверов, не имеющих постоянного соединения с сетью. Они должны периодически, обычно по телефонной сети, соединяться с серверами, выполняющими функции промежуточных хранилищ сообщений, и забирать накопившуюся почту. Поскольку протокол SMTP предусматривает отправку сообщений только от клиента к серверу, для передачи в обратном направлении им необходимо поменяться ролями.
Команда TURN представляет потенциальную опасность, так как она может быть использована для перехвата чужой почты. Потому RFC 2821 категорически не рекомендует ее использовать. Хорошими альтернативами команде TURN являются расширения ESMTP ETRN и ATRN, рассматриваемые ниже.
Ответы сервера SMTP
На каждую команду клиента сервер посылает ответ, состоящий из числового кода и отделенной от него пробелом текстовой строки.
В большинстве случаев для правильной интерпретации ответа клиенту достаточно числового кода. Текстовая строка нужна для интерпретации ответа человеком. Исключение составляет ответ на команду EHLO, содержащий список расширений ESMTP, поддерживаемых сервером, а так же ответы на некоторые команды ESMTP.
Согласно RFC 2821, код ответа состоит из трех цифр. Первая цифра кода может принимать следующие значения:
Предварительный положительный результат. Команда принята, но для ее выполнения сервер ожидает реакции клиента на посылаемую в этом ответе информацию. Клиент должен послать следующую команду для продолжения работы. В базовом протоколе SMTP не предусмотрено команд, требующих ответов такого типа.
Вторая цифра может принимать следующие значения:
Если ответ состоит из нескольких строк, то каждая из них начинается числовым кодом, который отделяется от сопровождающего текста не пробелом, а символом «минус» (-). В последней строке цифровой код отделяется от текста пробелом. Каждая строка ответа заканчивается последовательностью CRLF.
В таблице ниже собраны ответы, предусмотренные для команд SMTP.
| Код | Расшифровка | Команды |
|---|---|---|
| 211 | Состояние системы | HELP |
| 214 | Информация об использовании команд | HELP |
| 220 | Готовность к работе | Установление соединения |
| 221 | Канал передачи закрыт | QUIT |
| 250 | Команда выполнена успешно | EHLO, HELO, MAIL, RCPT DATA, RSET, VRFY, EXPN, NOOP |
| 251 | Почта для данного пользователя переадресована и будет доставлена по новому адресу | RCPT, VRFY |
| 252 | Команда не будет выполнена, но доставка сообщения возможна. Ответ свидетельствует о том, что выполнение команд заблокировано из соображений безопасности, и не может быть интерпретирован как информация об опрашиваемом почтовом ящике | VRFY, EXPN |
| 354 | Команда DATA принята, ожидается текст сообщения, заканчивающийся строкой, состоящей из одной точки | DATA |
| 421 | Служба недоступна, связь прекращается. Ответ выдается при прекращении работы сервера во время сеанса связи | Любая |
| 450 | Доставка сообщения в данный момент не возможна: почтовый ящик не доступен | RCPT |
| 451 | Выполнение команды прервано: ошибка сервера | MAIL, RCPT, DATA |
| 452 | Команда не выполнена: недостаточно памяти | MAIL, RCPT, DATA |
| 500 | Синтаксическая ошибка, команда не понята (возможно, превышена допустимая длина строки) | Несуществующая команда |
| 501 | Синтаксическая ошибка в параметрах или аргументах (например, использование параметров в командах, не допускающих параметров) | Любая |
| 502 | Команда не поддерживается (отключена администратором) | VRFY, EXPN, HELP |
| 503 | Неправильный порядок команд | MAIL, RCPT, DATA |
| 504 | Параметр команды не поддерживается | EHLO, HELO, VRFY, EXPN, HELP |
| 550 | Команда не выполнена: почтовый ящик недоступен (не найден, доступ запрещен, выполнение команды запрещено администратором) | EHLO, HELO, MAIL, RCPT, VRFY, EXPN |
| 551 | Адрес пользователя изменился | RCPT, VRFY |
| 552 | Выполнение команды прервано: превышен выделенный объем памяти | MAIL, RCPT, DATA |
| 553 | Неправильный синтаксис адреса | MAIL, RCPT, VRFY |
| 554 | Служба SMTP на вызываемой машине не запущена | Установление соединения |
| 554 | Доставка не может быть осуществлена ни по одному адресу D | ATA |
В случае переадресации почты допускается также использование ответа 250. В этом случае клиент о переадресации не информируется. Сервер может также отказать в приеме почты для уже не существующего пользователя и послать ответ 551 с указанием нового адреса или ответ 550. [Источник 3]