Smtp протокол что это такое
Что такое SMTP-протокол и как он устроен?
SMTP (Simple Mail Transfer Protocol) — протокол передачи почты. Он был представлен еще в 1982 году, но не теряет актуальности до сих пор. В статье разбираемся, какие задачи решает протокол и как он работает.
Для чего используется SMTP
У протокола две главные задачи:
SMTP и его место в стеке TCP/IP
Теоретически SMTP умеет работать с практически любыми протоколами так называемого транспортного уровня, включая TCP, UDP и другие. Еще на заре развития протокола за ним закрепили два номера порта:
В большинстве случаев протокол SMTP используется для передачи исходящей почты с использованием порта TCP 25. То есть можно сказать, что SMTP-порт — это как раз TCP 25, хоть и не всегда. Иногда задействуется еще порт 465. Так происходит, когда порт требует защищенного SSL-соединения.
Но в большинстве случаев используется лишь один транспортный протокол TCP с портом 25 (это SMTP-порт по умолчанию). Другие варианты применяются крайне редко, например, когда провайдеры по какой-то причине закрывают доступ к 25 порту. Они могут делать это, например, для блокировки спам-рассылок.
Электронное письмо и его формат
Сообщение электронной почты всегда состоит из трех элементов:
Конверт применяется для передачи сообщений электронной почты от клиенту к серверу и обратно. При этом как клиент, так и сервер взаимодействуют друг с другом в обычном формате «запрос-ответ». В ходе взаимодействия между ними передаются текстовые строки.
Что касается заголовка и тела письма, то их параметры прописаны в отдельном документе — RFC2822.
Формат поля заголовка Received:
Received:
From host
by host
via physical-path
with protocol
id message-id
for final e-mail destination
Это поле используется для идентификации тех SMTP-серверов, которые были задействованы в процессе доставки сообщения от отправителя к получателю. Любой сервер из цепочки добавляет к сообщению собственное поле Received, где можно видеть техническую информацию об этом сервере.
Return-Path — поле возврата, которое используется для определения маршрута, по которому прошло сообщение. Если оно было отправлено прямо на сервер получателя, то в поле отображается один адрес. Если же серверов несколько, они будут отображаться списком.
Команды и ответы SMTP
Команды
Все они состоят из четырех символов. Сакрального замысла здесь нет, просто в самом начале разработчики договорились, что длина будет именно такой. Ниже — основные команды SMPT. Есть и другие, но они используются реже.
Ответы SMTP
Здесь все одновременно и проще, и сложнее. Ответы в случае SMTP состоят из двух частей:
Коды сообщений начинаются на 2, 3, 5. Если сообщение начинается на 2, это значит, что предыдущая команда успешно завершена. «Тройка» в коде означает успешную отправку с необходимостью предоставить дополнительные данные.
Если сообщение начинается на 5, это означает технический сбой. Так, ошибка 502 — индикатор нереализованной команды, а 503 сообщает о неправильной последовательности команд.
Как работает SMTP — простыми словами
Давайте представим, что вы установили и настроили собственный SMTP-сервер. Далее вы планируете отправить письмо. Работает отправка по определенному алгоритму:
Если все хорошо, то далее в работу вступают уже другие протоколы — POP и IMAP, но о них мы поговорим в другой статье.
Пример работы SMTP
В качестве примера давайте рассмотрим пример сеанса SMTP, который инициализируется при необходимости отправить электронное письмо. На картинке ниже — данные сеанса, с которыми мы будем работать дальше.
Здесь мы видим подключение к почтовому серверу по 25 порту. Говоря техническим языком, подключение выполнено по адресу 220 smtp.example.ru ESMTP Postfix на 25 порт. Начало подключения — использование команды HELO, которая нужна для указания собственного домена. После этого вступает в работу сервер, который возвращает статус 250. Что это такое? Все просто: соединение установилось без проблем. После этого сервер еще раз пишет доменное имя в текстовом сообщении.
Теперь наступает очередь использования команды Mail FROM, которая нужна для отображения адреса отправителя сообщения. Если все хорошо, то сервер снова отвечает сообщением со статусом 250. Мы видим, что с текстовой частью все хорошо, команда выполнена, проблем не возникло.
Наступает следующий этап — использование команды Mail FROM для того, чтобы указать адрес отправителя. Если сервер возвращает статус 250, то мы уже знаем, что это означает. Все удалось, теперь нужно выполнить команду DATA для ввода самого письма. В этом случае сервер отвечает уже не статусом 250, а другим — 354. После этого можно начинать вводить текст письма. Важный нюанс: заканчиваться все это должно отдельной строкой, которая содержит всего одну точку.
Сообщение всегда состоит из двух частей. Первая — заголовок, вторая — тело сообщения. Последнее необходимо отделять от заголовка пустой строкой. В этом случае требуется использовать заголовок FROM, это адрес пользователя, отправившего сообщение. Указывать нужно не только сам адрес, но и имя. А еще требуется заголовок, который дает получателю понять, в чем заключается основной посыл сообщения. Что касается пустой строки, то она отделяет заголовки от тела письма.
Возьмем самое простое сообщение, которое состоит из двух строчек текста: это «Hello, email world!» и «Hello, SMTP!». Заканчивается письмо строкой, которая содержит всего одну точку. Но эта строчка не будет видна получателю, она чисто техническая и будет обязательно убрана в ходе передачи. Если же точка нужна, то нужно указать сразу две точки, из которых одна будет удалена.
Наконец, если есть точка, то сервер видит, что письмо полностью завершено, выдавая статус сообщения 250 2.0.0 Ok: queued as 7FD9DC2E0060. Все это означает, что письмо уже находится в очереди ожидания. Для завершения сеанса нужно ввести всего одну команду — QUIT. Сервер ответит сообщением со статусом 221, что означает «пока».
Нужен ли собственный сервер SMTP?
Здесь все зависит от задач, которые будет решать пользователь. SMTP подходит для реализации масштабного спектра задач — от отправки сообщения до доставки его получателю. Чаще всего SMTP используют для транзакционных писем, массовых рассылок или личной переписки.
Собственный SMTP дает немного больше преимуществ перед корпоративными (или, например, Google). Это, как правило, невысокая цена, внимательное отношение со стороны разработчиков и хорошая доставляемость массовых рассылок.
Достоинство SMTP в том, что его достаточно просто внедрить, для этого протокола есть обширная документация и развитое комьюнити.
Немного о безопасности и спаме
Протокол SMTP очень простой, у него нет никаких инструментов для защиты пользовательских данных от злоумышленников. Так, адреса, указанные в соответствующем поле, не проверяются.
Кроме того, у SMTP по дефолту не используется шифрование, так что любые письма, передаваемые разными компаниями, могут быть прочитаны — было бы желание и соответствующие инструменты. Но это относится к SMTP первой версии. В улучшенном варианте разработчики добавили шифрование. Для того, чтобы его задействовать, нужно использовать специальную команду STARTTLS.
Еще одна проблема SMTP — обилие нежелательных рекламных сообщений. К сожалению, протокол не содержит никаких защитных инструментов для ликвидации спама. Правда, многие современные почтовые серверы стараются использовать и внешние механизмы.
Большинство почтовых серверов для безопасности настраиваются на работу лишь с локальными юзерами. То есть это те пользователи, у которых есть ящики с адресом из пула домена, который они и обслуживают. Здесь встречаются и новые термины. Так, серверы, которые работают в ином режиме, позволяя передавать почту абсолютно на все адреса, называются «открытые релеи». Они нужны обычным пользователям, но активнее всего их используют злоумышленники. Зачем? Чтобы рассылать спам, конечно же. Поэтому за режимом работы корпоративных серверов нужно следить. Если при проверке сети окажется, что сервер работает в режиме открытого релея, стоит поговорить с администратором сервера.
А еще можно проверить адрес отправителя посредством цифровой подписи, о чем мы уже упоминали выше.
Например, есть возможность проверки email отправителя, воспользовавшись цифровой подписью. С этой целью используется, например, взаимодействие с системой DNS. В ней хранится открытый ключ электронной подписи для конкретного домена. И этот ключ как раз можно использовать для проверки.
В сухом остатке
SMTP — проверенный временем протокол передачи электронной почты, который просто работает. Да, у него есть свои недостатки, но они нивелируются простотой и надежностью протокола. К слову, он может использоваться как для отправления сообщений на почтовый сервер, так и на целую группу серверов.
Кстати, можно сделать собственный сервер SMTP для того, чтобы отправлять массовые рассылки. Но в этом случае придется выполнить множество разных тасков, включая добавление обработки статуса доставки письма, обход разного рода «черных» и «серых» списков. Требуется еще и удобная статистика отправлений, и возможность отписки от рассылки.
Для того чтобы все реализовать, лучше использовать специализированный сервис, владельцы которого развернули необходимые услуги. В этом случае разработчики требуются лишь для того, чтобы добавить сервис к CRM-системе.
Можно пойти еще дальше и организовать сервисы разных рассылок. Их достоинство состоит в том, что все возможности встроены в пользовательский интерфейс. А возможности не только базовые, ведь в таких сервисах есть функции сбора писем и форм подписки, работы с контактами, настройка цепочек в автоматическом режиме и проведение сплит-тестов.
Добавим, что собственный SMTP-сервер можно реализовать на мощностях Selectel, арендовав для этой задачи выделенные сервер или виртуальную машину в «Облачной платформе Selectel».
SMTP. Описание протокола
Что такое SMTP — описание?
На протяжении нескольких десятков лет, пользователи сети Интернет используют электронную почту, чтобы обмениваться сообщениями и письмами. До начала 90-х годов прошлого века электронными сообщениями пользовались, как правило, сотрудники крупных организаций. С обширной компьютеризацией и распространением всемирной паутины, электронные письма прочно вошли в жизнь обычных пользователей.
Развитие интернет технологий привело к появлению так называемых почтовых протоколов, используемых для сетевой переписки. Они делают возможной обработку больших по размеру писем, оказывая пользователям всевозможные сервисные услуги.
Он не стеснен какими-либо конкретными подсистемами передачи данных. Его работа нуждается только в надежном канале потока их передачи с сохранением порядка.
SMTP используется, в основном, для отправки писем и обращений пользователей на сервер, после чего происходит отправка почты получателям. Для того, чтобы получить письма, нужно чтобы почтовый клиент работал на протоколе IMAP или же POP3.
Для чего используется?
Простой протокол впервые опубликован в 1982 г. Использовался он как дополнительное приложение к популярному тогда клиенту — Unix Copy Program. Первым клиентом, работающим под стеком SMTP, стал Sendmail.
На сегодняшний день это типовой почтовый протокол. Его используют все почтовые программы и серверы.
Принцип работы протокола
SMTP — текстовый протокол, его принцип работы требует соединения, по которому пользователь, отправляющий электронное письмо, связывается с его получателем используя определенную командную строку. А получение данных происходит посредством использования надежного канала связи. Как правило, этим каналом связи является соединение TCP.
Рабочая сессия протокола состоит из отправляемых mail — клиентом SMTP ряда команд и ответов на них сервера. При рабочей сессии и клиент, и сервер обмениваются необходимыми параметрами.
Операция протокола включает в себя комбинацию, состоящую из следующих последовательностей команд и ответов:
Первоначальным SMTP-клиентом вполне может выступать почтовый клиент получателя, или агент пересылки корреспонденции на сервере.
Как работают другие почтовые протоколы
SMTP является лишь протоколом доставки корреспонденции в сети. Он не может по команде взять электронное сообщение с удаленного сервера или как-то управлять e-mail ящиком.
Для этого существуют другие протоколы, например IMAP и POP. Их использование предпочтительнее при временном подключении к сети или когда ПК включается периодически.
Проверка и регистрация доменов SU — зарегистрируйте запоминающийся домен для Вашего проекта.
Post Office Protocol – это простой сетевой протокол, включающий в себя три разновидности: POP, POP2 и POP3. Разработаны они для того, чтобы доставлять корреспонденцию пользователю с центрального почтового сервера, для удаления почты с сервера и для идентификации пользователя. Для идентификации используется сочетание логина и пароля. Стоит отметить, что все три протокола не взаимозаменяемы.
Протокол включает SMTP, используемый для передачи исходящей почты.
В соответствии с POP3, письма, поступающие на определенный e-mail сохраняются на сервере до загрузки их на ПК во время очередного сеанса. Когда загрузка произошла, становится возможным прочитать сообщения, отключившись от сети. Считается, что POP3 — самый быстрый почтовый протокол.
С помощью Internet Message Access Protocol становится возможным хранение сообщений в директориях файлов на сервере и производить поиск любых строк сообщений прямо там.
Данный протокол подходит тем пользователям, компьютеры которых используют непрерывное подключение к интернету. Его отличие от POP в том, что при проверке новых писем загружаются только их заголовки.
iPipe – надёжный хостинг-провайдер с опытом работы более 15 лет.
Что это такое? Спам – в большинстве случаев это рассылка электронной почты по базе пользователей, которые не давали на неё…
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]