SMTP — простой протокол передачи почты [АйТи бубен]
SMTP (Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP. ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают ESMTP и его расширения. SMTP использует порт Порты TCP 25.
Протокол SMTP использует простые текстовые команды в формате ASCII и возвращает трехзначные кодированные ответы с текстовыми сообщениями. Протокол SMTP описывается документом Internet Request For Comment (RFC) номер 821, который был разработан группой Internet Engineering Task Force (IETF) и опубликован 21 августа 1982 года. С тех пор он претерпел несколько модификаций, но в целом основные команды протокола не изменились.
Ссылки:
Основные команды клиента SMTP
- Альтернативой telnet для тестирования SMTP служит утилита swaks:
aptitude install swaks
Формат команд в SMTP прост: command [parameter], где command — четырехсимвольная команда протокола SMTP, а parameter — необязательный параметр, определяющий тип данных в команде.
EHLO(устаревшая — HELO) Открывает приглашение от клиента
MAIL — Определяет отправителя сообщения
RCPT — Определяет получателей сообщения
DATA — Определяет начало сообщения
SEND — Посылает сообщение на терминал
SOML — Send-or-Mail
SAML — Send-and-Mail
RSET — Сброс SMTP-соединения
VRFY — Проверяет имя пользователя системы
EXPN — Запрашивает список псевдонимов
HELP — Запрашивает список команд
NOOP — No operation — Ничего не делать
QUIT — Остановить сеанс SMTP
TURN — Реверс ролей в SMTP (клиент становится сервером)
- AUTH — Показывает серверу механизм аутентификации. RFC 4954 (заменил RFC 2554).
Команда HELO
По определению, длина команд протокола SMTP четыре символа. Приветствие, выдаваемое клиентом на сервер, и есть команда HELO. Формат команды следующий:
HELO domain name
Смысл команды HELO заключается в представлении клиента серверу SMTP. К сожалению, этот метод доступа был разработан на начальной стадии развития сети Internet, когда еще не было столь большого числа попыток несанкционированного проникновения в компьютерные системы. Как видите, клиент может назвать себя любым именем в командной строке. Это привело к тому, что в настоящее время большинство серверов SMTP эту команду используют чисто формально. Если они действительно стараются идентифицировать клиента, то подключается механизм обратного преобразования
При работе с протоколом SMTP следует различать клиентов SMTP. Пользователи-клиенты и хосты-клиенты не одно и то же. При создании почтового сообщения пользователь системы электронной почты является одновременно и клиентом своего локального хоста. После отправки почтового сообщения он уже не является клиентом процесса SMTP. Теперь его локальный хост-компьютер осуществляет процесс доставки сообщения и сам выступает в качестве клиента SMTP. Когда локальный хост соединяется с удаленным хостом для передачи сообщения с помощью протокола SMTP, он действует как клиент SMTP-процесса. Команда HELO объявляет в качестве клиента имя локального хоста, а не реального пользователя, отославшего сообщение. Довольно часто эти понятия путают, что усложняет решение проблем, возникающих в системах электронной почты.
Команда AUTH
Расширение диалога SMTP командой AUTH описывается в RFC 4954.
Возможные механизмы аутентификации:
PLAIN (Uses Base64 encoding.)
LOGIN (Uses Base64 encoding.)
GSSAPI (Generic Security Services Application Program Interface)
DIGEST-MD5 (Digest access authentication)
CRAM-MD5
NTLM
Команда MAIL
MAIL reverse-path
Аргумент reverse-path не только определяет отправителя сообщения, но также указывает маршрут, по которому можно вернуть сообщение в случае невозможности его доставки. Если отправитель является пользователем на клиентском компьютере, который инициировал сеанс SMTP, то формат команды будет следующим:
MAIL FROM: [email protected]
Заметьте, что в поле FROM указывается адрес электронной почты отправителя сообщения, включая полное имя клиентского хост-компьютера. Эта информация должна присутствовать в поле FROM почтового сообщения (но об этом позже). Если почтовое сообщение проходило на пути от отправителя к получателю через несколько узлов, то каждый из них будет добавлять сведения о себе в поле <reverse-path>. Таким образом документируется путь прохождения сообщения через почтовые серверы. Довольно часто электронная почта от клиентов частных сетей должна проходить через несколько серверов электронной почты, прежде чем попасть в сеть Internet. Информация, которая содержится в поле reverse-path часто полезна при разрешении проблем в системах электронной почты или для обнаружения почтовых серверов, которые пытаются скрыть свою принадлежность, посылая сообщения через неизвестные серверы SMTP.
Команда RCPT
Команда RCPT определяет получателей сообщения. Одно и то же сообщение могут получать несколько пользователей. Обычно каждый получатель указывается отдельной строкой с командой RCPT. Формат команды RCPT следующий:
RCPT forward-path
Аргумент forward-path определяет, куда направляется электронная почта. Как правило, здесь указывается полный адрес электронной почты, но может также указываться и имя пользователя локального сервера SMTP. Рассмотрим для примера следующую команду:
RCPT TO: haley
С помощью этой команды указывается, что сообщение должно быть направлено пользователю haley на сервер SMTP, который обрабатывает сообщения. Таким же образом можно посылать сообщения и пользователям других компьютеров, которые не являются пользователями сервера SMTP, куда направлено сообщение. Рассмотрим, например, следующую команду:
RCPT TO: [email protected]
Команда, направленная серверу SMTP с именем shardrach.smallorg.org, вынуждает принять решение о доставке сообщения именно этот сервер. Так как пользователь не зарегистрирован на локальном сервере shardrach, то серверу придется определить, что делать с сообщением дальше. В этом случае возможны три варианта действий хоста shardrach. Давайте остановимся на них подробнее.
Хост shardrach может переслать сообщение получателю и возвратить утвердительный ответ отправителю (OK). В этом случае он добавляет свое имя в поле <reverse-path> команды MAIL, чтобы включить его в маршрут прохождения сообщения при необходимости уведомить отправителя.
Хост shardrach не может переслать сообщение и уведомляет об этом отправителя, подтверждая в то же время правильность адреса хоста meshach.smallorg.org. Таким образом, отправитель может попытаться повторно отправить сообщение прямо на meshach.smallorg.org.
Хост shardrach не может переслать сообщение и посылает уведомление о том, что эту операцию невозможно осуществить с данным сервером. Тогда причины случившегося следует проанализировать системному администратору.
На начальной стадии развития сети Internet практиковалась пересылка сообщений электронной почты вслепую между компьютерами по всему миру, в которых использовался исходный алгоритм передачи почтовых сообщений.
Команда DATA
Эта команда является основной в протоколе SMTP. После обработки команд MAIL и RCPT команда DATA используется для передачи информационной части сообщения. Формат команды DATA следующий:
DATA
Все, что следует за этой командой, интерпретируется как сообщение для передачи. Сервер SMTP, как правило, дополняет заголовок сообщения меткой времени и информацией об обратном маршруте return-path. Программа-клиент обозначает конец сообщения посредством передачи строки с одной точкой. Формат этой строки следующий:
<CR><LF>.<CR><LF>
Приняв эту последовательность, сервер SMTP «понимает», что передача сообщения закончена и следует вернуть код ответа, который оповестит клиента о том, что его сообщение принято.
Команда SEND
Команда SEND используется для передачи почтовых сообщений непосредственно на терминал зарегистрированного пользователя системы. Эта команда выполняется только в том случае, когда пользователь находится в системе, и обычно представляет собой всплывающее сообщение, подобно команде write в ОС UNIX. У этой команды имеется серьезный недостаток: с ее помощью внешний пользователь может легко определить, кто в данный момент находится в системе. Эта «возможность» давно и активно эксплуатируется хакерами для получения идентификаторов пользователя в сети Internet у ничего не подозревающих жертв, находящихся в системе. Из-за угрозы безопасности в настоящее время большинство программных пакетов для работы с SMTP уже не содержат эту команду.
Команда RSET
Команда RSET — сокращение от reset (англ. сброс — Прим. пер.). Если клиент запутался в ответах, получаемых от сервера, или решил, что соединение потеряно, он может послать команду RSET и вернуть сеанс к его начальной точке — выполнению команды HELO. При этом все ранее посланные команды — MAIL, RCPT и DATA будут аннулированы. Очень часто к этой команде прибегают в качестве «последнего средства», когда клиент либо потерял последовательность команд, либо получил неожиданный ответ от сервера.
VRFY
Команда VRFY является сокращением от verify (англ. проверить — Прим. пер.). Ее можно использовать для определения возможности доставки сервером почты определенному получателю перед выполнением команды RCPT. Формат этой команды следующий:
VRFY username
По принятии данной команды сервер SMTP определяет, имеется ли у него на локальном сервере пользователь с заданным именем. Если такой пользователь найден, то сервер вернет ответ с полным почтовым адресом пользователя. Если такого пользователя нет на локальном сервере, то SMTP-сервер может либо вернуть негативный ответ клиенту, либо указать, что он будет пересылать все сообщения удаленному пользователю. Это зависит от того, будет ли сервер SMTP пересылать сообщения удаленному клиенту.
Команда VRFY может оказаться эффективным инструментом при поиске неполадок в работе электронной почты. Довольно часто, отправляя почтовые сообщения, пользователи ошибаются при написании имени адресата или хоста и затем недоумевают, почему их сообщения не были получены. Конечно, первое, что они предпримут, — это пожалуются администратору почтовой системы на отвратительную работу системы электронной почты. Как администратор почтовой системы вы, можете проверить работоспособность адресов электронной почты двумя путями. Во-первых, с помощью команды DNS host, которая позволяет определить правильность доменного имени и наличие почтового сервера, обслуживающего домен. И во-вторых, можно зайти с помощью telnet на порт 25 почтового сервера и затем задать команду VRFY, которая определит правильность имени пользователя. В листинге 5.3 показан пример использования команды VRFY для проверки имен пользователей.
1 [riley@shadrach riley]$ telnet localhost 25 2 Trying 127.0.0.1... 3 Connected to localhost. 4 Escape character is '^]'. 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Thu, 26 Aug 1999 19:20:16 -050 6 HELO localhost 7 250 shadrach.smallorg.org Hello localhost [127.0.0.1], pleased to meet you 8 VRFY rich 9 250 <rich@shadrach,smallorg.org> 10 VRFY [email protected] 11 252 <[email protected]> 12 VRFY jessica 13 550 jessica... User unknown 14 QUIT 15 221 shadrach.smallorg.org closing connection 16 Connection closed by -foreign host. 17 [riley@shadrach riley]$
В строках 8–13 представлены результаты выполнения команды VRFY. В строке 8 делается попытка выполнить VRFY для локального пользователя rich. Ответ SMTP- сервера в строке 9 подтверждает, что пользователь с таким именем имеется в системе, и клиенту возвращается его полный адрес электронной почты. В строке 10 показан еще один вариант задания команды VRFY. Здесь клиент пытается выполнить команду VRFY для пользователя на удаленном компьютере. Ответ, полученный в строке 11 от системы shadrach, отличается от результата, полученного в строке 9. В разделе «Ответы сервера» значения кодов, возвращаемых сервером, обсуждаются более детально. В нашем случае отметим, что система shadrach уведомляет клиента о том, что почта будет пересылаться пользователю prez на удаленном сервере meshach.smallorg.org. Строка 12 отображает попытку проверить несуществующее имя в системе meshach. Ответ SMTP-сервера в строке 13 в пояснениях не нуждается.
- Проверить существования пользователя используя bash и curl.
$ echo -e "VRFY [email protected]\n QUIT" | curl telnet://mail.example.com:25 220 mail.1-talk.com ESMTP Postfix 252 2.0.0 [email protected] 221 2.0.0 Bye
Команда NOOP
Команда NOOP — сокращение от no operation (англ. нет операции — Прим. пер.). Эта команда не оказывает никакого воздействия на SMTP-сервер, за исключением того, что сервер возвращает на нее позитивный код ответа. Она используется при тестировании соединения без пересылки сообщения.
Команда QUIT
Команда QUIT делает именно то, что она и означает (англ. выйти — Прим. пер.), т.е. сообщает SMTP-серверу о том, что клиентский компьютер закончил текущий сеанс и хочет закрыть соединение. Сервер SMTP должен ответить на эту команду, а затем инициировать и закрыть TCP-соединение. Если сервер принимает команду QUIT в процессе передачи почты, то все переданные в течение сеанса данные должны быть уничтожены и не поступят получателю.
Формат сообщений интернет EMail описывается в RFC2822, который заменил более старый RFC822.Стандартные поля заголовка, согласно RFC 822
Документом RFC 822 предусматривается разбиение сообщения на две части. Первая часть называется заголовком. В нее вносятся все данные, идентифицирующие сообщение. Вторая часть называется телом сообщения. Заголовок состоит из полей данных, которые используются по мере необходимости внесения дополнительной информации в сообщение. Поля заголовка и тело сообщения должны разделяться пустой строкой. Для полей заголовка не существует определенного порядка следования, т.е. поля заголовка могут располагаться в произвольном порядке. Кроме того, в одном сообщении поля заголовка могут повторяться. На рисунке представлен общий вид почтового сообщения, соответствующего требованиям RFC 822.
Формат сообщения, согласно RFC 822
Формат поля заголовка Received: (Принято:) следующий:
Received: from host name by host name via physical-path with protocol id message-id for final e-mail destination
Поле заголовка Received используется для идентификации SMTP-серверов, которые принимали участие в процессе доставки сообщения от отправителя получателю. Каждый сервер добавляет к почтовому сообщению свое поле Received, с указанием специфических сведений о себе. Субполя в поле Received указывают на путь, протокол и компьютеры, принимавшие участие в передаче сообщения.
Формат этого поля заголовка следующий:
Return-Path: route
Последний SMTP-сервер в цепочке пересылки добавляет к сообщению поле возврата (Return-Path). Его цель — определение маршрута, посредством которого сообщение достигло получателя. Если сообщение было послано напрямую на сервер получателя, то в этом поле будет отображаться только один адрес. В противном случае здесь будет отображаться полный список серверов, через которые прошло сообщение, чтобы достичь адресата. Может отличаться от MAIL FROM (то есть обратный адрес может быть указан отличным от адреса отправителя).
В поле Originator указывается адрес отправителя сообщения. Эта информация весьма полезна в ситуации, когда сообщения были отвергнуты несколько раз частными сетями, прежде чем они попали в сеть Internet. Формат этого поля следующий:
Reply-To: address
Поле Originator является всего лишь небольшим вспомогательным полем в многоцветье полей заголовка. Оно может быть использовано в качестве более простого пути для небольших SMTP-пакетов. При этом необходимость в более сложных полях заголовка, по которым определяется отправитель, отпадает.
Поле заголовка Resent идентифицирует почтовое сообщение, которое по какой-либо причине должно было повторно посылаться клиентом. Формат этого поля следующий:
Resent-Reply-To: address
Данные поля заголовка идентифицируют отправителя электронного сообщения. Формат полей Authentic:
From: user-name Sender: user-name
Поле From:(От:) идентифицирует автора сообщения. Обычно в полях From: и Sender:(Отправитель:) указывается один и тот же пользователь, так что в действительности требуется только одно из этих полей. В том случае, когда отправитель почты не является автором сообщения, а оно лишь посылается с его адреса, оба поля все равно должны быть указаны — этим обеспечивается возврат сообщения отправителю, если доставка его адресату оказалась невозможной. Поля заголовка Resent-authentic
Поля Resent-authentic определяют отправителя сообщения, которое по какой-либо причине повторно передавалось программой-клиентом. Формат этих полей следующий:
Resent-From: date-time Resent-Sender: date-time Поля Resent-From: и Resent-Sender: работают подобно полям From: и Sender:. Они лишь отражают, что сообщение было повторно передано клиентом по неизвестной причине.
Поля заголовка Dates
Поля заголовка Dates используются для помещения метки времени в сообщение при передаче его от клиента серверу. Формат полей Dates следующий:
Date: date-time Resent-Date: date-time Поле Date: (Дата) будет пересылать информацию в заголовке сообщения в точном соответствии с оригиналом сообщения. Этот параметр может оказаться полезным при отслеживании времени получения ответов, в особенности — множественных ответов.
В полях заголовка Destination указываются адреса электронной почты получателей сообщения. Эти поля являются чисто информационными. Сервер SMTP в любом случае не будет посылать сообщение в почтовый ящик пользователя, пока на получит команду RCPT, выданную для данного пользователя (см. раздел «Основные команды клиента SMTP»). Формат этих полей следующий:
To: address Resent-To: address CC: address Resent-CC: address BCC: address Resent-BCC: address
Поля To:, CC: и BCC: устанавливают стандартный алгоритм обработки электронной почты. Большинство пакетов для работы с электронной почтой используют именно эту терминологию для классификации получателей сообщения. Поле CC: сходно с памяткой, и указанные в нем получатели должны получить «копию» сообщения. Еще одно новое понятие, введенное системами электронной почты, — BCC: или «невидимая копия» (blind carbon copy). В поле «невидимой копии» также указывается получатель копии сообщения, но его адрес не виден посторонним (это не совсем этично). В связи с этой опцией обсуждалась вопросы компьютерной этики, но на сегодняшний день практически все программы для работы с электронной почтой поддерживают эту возможность.
Необязательными являются поля, которые более подробно идентифицируют сообщение для сервера SMTP, но, согласно RFC 822, могут и не присутствовать в сообщении. Тем не менее эти поля в настоящее время широко распространены, и многим из вас придется столкнуться с ними. Формат некоторых из них следующий:
Message-ID: message-id Resent-Message-ID: message-id In-Reply-To: message-id References: message-id Keywords: text - list Subject: text Comments: text Encrypted: word
Наиболее полезным и часто используемым из этого набора является поле Subject: (Тема). Большинство программ для работы с электронной почтой допускает ввод отправителем темы сообщения в одну строку, которая описывает для получателя содержание сообщения. Эта строка текста довольно часто используется почтовой программой-клиентом при формировании списков полученных сообщений. Еще одно необязательное поле также помогает идентифицировать почтовое сообщение. Это поле Message-ID: (Идентификатор сообщения). В этом поле сообщению присваивается уникальный идентификационный номер, который может затем отображаться в возвращенном сообщении. Специальное поле шифрования Encrypted: указывает, было ли сообщение в целях безопасности подвергнуто шифрованию, а в Keywords: можно задать ключевые слова, которые можно использовать при поиске определенного текста, встречающегося в сообщении (сообщениях).
В алгоритме кодирования MIME учитывается тип двоичного файла, подвергающегося преобразованию, а также передается дополнительная информация о файле для декодера. Алгоритм MIME позволяет помещать двоичные данные напрямую в стандартное почтовое сообщение, согласно RFC 822. Для описания двоичных данных, вкладываемых в сообщение формата RFC 822, были созданы пять новых полей заголовка. Программы для работы с почтой, которые поддерживают стандарт MIME, должны правильно обрабатывать все эти новые типы заголовков.
Первое из дополнительных полей заголовка содержит версию MIME, которую использовал отправитель при кодировании сообщения. В настоящее время в этом поле всегда 1.0.
В поле заголовка Content-Transfer-Encoding указывается способ помещения двоичных данных в сообщение текстового формата ASCII. На сегодняшний день существует семь различных способов кодирования двоичных данных, однако наиболее часто встречается кодирование base64. При применении этого метода кодирования 6-битовые блоки двоичных данных преобразуются в 8-битовые блоки, воспринимаемые как текст ASCII.
Это поле заголовка используется для идентификации сеансов MIME по определенному идентификационному коду, когда содержимое имеет сложную структуру.
Поле заголовка Content-Description используется для текстового описания в формате ASCII данных, помещенных в почтовое сообщение. Это удобно при пересылке документов, созданных при помощи текстового процессора или графики, которые ничем не отличаются, будучи закодированными base64.
Поле заголовка Content-Type
В этом поле заголовка как раз и происходит основное действие нашей пьесы. Это поле идентифицирует данные, заключенные в MIME-сообщение. В настоящее время используется семь основных классов данных, идентифицированных в MIME. В каждом классе имеются свои подклассы, которые более детально характеризуют тип данных, заключенных в сообщении.
Тип данных text идентифицирует данные в формате ASCII, которые должны читаться в исходном виде. Здесь существует также два подкласса — plain-текст, т.е. неформатированный ASCII-текст, и enriched-текст, который включает в себя элементы форматирования, схожие с обогащенным текстовым форматом. Новейшие программы для работы с электронной почтой могут работать даже с обогащенным текстовым форматом (RTF).
Тип данных message позволяет почтовой программе отсылать простые сообщения в формате RFC 822. Подклассы этого типа: rfc822, который указывает на то, что вложением является обычное сообщение, соответствующее RFC 822; partial, который позволяет разбивать длинные сообщения на несколько частей, и external-body, который позволяет помещать указатель на объект, не являющийся частью сообщения.
Тип данных image определяет вложение в сообщение двоичных данных, которые представляют собой графическое изображение. В настоящее время для этого типа определено два подкласса — jpeg и gif.
Тип данных video, соответственно, определяет, что вложенные в сообщение данные представляют собой видеоданные. В настоящее время для этого типа определен только один подкласс — формат mpeg.
Тип данных audio обозначает содержимое сообщения как аудиоданные (звуковые файлы). Здесь также пока определен только один подкласс basic, который соответствует одному каналу ISDN с частотой дискретизации 8 Кгц.
Тип данных application соответствует двоичным данным, вложенным в сообщение, которые являются приложением (например, электронные таблицы Microsoft Excel или документы, созданные с помощью текстового процессора Microsoft Word). На сегодняшний день определено два подкласса такого рода данных — postscript и octet-stream. Довольно часто подкласс octet-stream используется при вложении в сообщение прикладных данных, таких как документы Microsoft Word или электронные таблицы Microsoft Excel.
Тип данных multipart идентифицирует сообщения, содержащие несколько различных типов данных. Этот формат довольно часто встречается в почтовых программах, поддерживающих вывод сообщения несколькими способами, например в виде текста ASCII, HTML-текста или аудиофайла. Граничный идентификатор разделяет различные типы данных. В то же время каждый тип данных идентифицируется определенным полем заголовка типа данных. Тип данных multipart имеет четыре подкласса.
Подкласс mixed указывает на то, что каждая из частей сообщения является независимой и все они должны быть представлены получателю в том порядке, в каком они были вложены отправителем. Подкласс parallel указывает то, что каждая из частей сообщения является независимой и все они могут быть представлены получателю в любом порядке. Следующий подкласс alternative указывает, что все части сообщения представляют собой одни и те же данные, но представленные в различном виде. При этом получатель может выбрать наилучшее средство для просмотра полученных данных. Подкласс digest во многом сходен с подклассом mixed, но при этом указывает, что тело сообщения всегда представляется в формате RFC822.
1 [rich@shadrach rich]$ telnet localhost 25 2 Trying 127.0.0.1... 3 Connected to localhost. 4 Escape character is '^]'. 5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 07:36:58 -050 6 HELO localhost 7 258 shadrach.smallorg.org Hello localhost [127.0.0.1] , pleased to meet you 8 MAIL FROM:rich@localhost 9 250 rich@localhost... Sender ok 10 RCPT TO:rich 11 250 rich... Recipient ok 12 DATA 13 354 Enter mail, end with "." on a line by itself 14 From:"Rich Blum" <rich@localhost> 15 To:"rich"<rich©localhost> 16 Subject:Formatted text message test 17 MIME-Version: 1.0 18 Content-Type: multipart/alternative; boundary=bounds1 19 20 –bounds1 21 Content-Type: text/plain; charset=us-ascii 22 23 This is the plain text part of the message that can 24 be read by simple e-mail readers. 25 26 –-bounds1 27 Context-Type: text/enriched 28 29 This is the <bold>rich text</bold> version of the <bigger>SAME</bigger> message. 30 31 –-bounds1-- 32 . 33 250 MAA04305 Message accepted for delivery 34 QUIT 35 221 shadrach.smallorg.org closing connection 36 Connection closed by foreign host. 37 You have new mail in /var/spool/mail/rich 38 [rich@shadrach rich]$
Листинг 5.6. Пример сеанса SMTP с несколькими вложениями MIME (html, txt) Пример сообщения, представленный в листинге 5.6, является сообщением MIME, которое состоит из двух частей. В строке 18 показан тип данных сообщения. Тип multipart/alternative указывает на то, что в сообщении имеются различные типы данных, которые отделены граничным разделителем bounds1. Данные первого типа начинаются со строки 21 и представляют собой простой ASCII-текст, который может прочесть практически любая почтовая программа.
Данные второго типа начинаются со строки 27 и представляют собой форматированный текст с использованием обогащенного текстового формата.
Так как тип MIME, указанный для сообщения, — multipart/alternative, то определение того, какую версию вложения отобразить, всецело зависит от почтовой программы.
С момента своего появления в 1982 году протокол SMTP прекрасно справлялся со своими задачами по пересылке сообщений между компьютерами в сети Internet. Однако со временем стали заметны заложенные в протокол ограничения. Тогда, вместо того чтобы заменить стандартный протокол, имевший к тому времени широкое распространение, было решено улучшить некоторые функции протокола SMTP. При этом было принято решение, оставив все спецификации SMTP в первозданном виде, лишь добавить к ним новые функции.
В 1995 году увидел свет документ RFC 1869, где был определен метод расширения возможностей протокола SMTP, который назывался «Расширенные службы SMTP».
Расширенный SMTP (Extended SMTP) реализован следующим образом. В начале сеанса SMTP команда HELO заменена на команду приглашения — EHLO. Получение сервером SMTP такой команды означает, что клиент может посылать ему расширенные SMTP команды. В листинге 5.7 показан пример сеанса с использованием EHLO , а также дополнительных команд.
1 [katie@shadrach katie]$ telnet localhost 25
2 Trying 127.0.0.1...
3 Connected to localhost.
4 Escape character is '^]'.
5 220 shadrach.smallorg.org ESMTP Sendmail 8.9.3/8.9.3; Mon, 30 Aug 1999 16:36:48 -050
6 EHLO localhost
7 250-shadrach.smallorg.org Hello localhost [127.0.0.1] , pleased to meet you
8 250-EXPN
9 250-VERB
10 250-8BITMIME
11 250-SIZE
12 250-DSN
13 250-ONEX
14 250-ETRN
15 250-XUSR
16 250 HELP
17 HELP DSN
18 214-MAIL FROM: <sender> [ RET={ FULL || HDRS} ] [ ENVID=<envid> ]
19 214-RCPT TO: <recipient> [ NOTIFY={NEVER,SUCCESS,FAILURE,DELAY} ]
20 214- [ ORCPT=<recipient> ]
21 214- SMTP Delivery Status Notifications.
22 214-Descriptions:
23 214- RET Return either the full message or only headers.
24 214- ENVID Sender's "envelope identifier" for tracking.
25 214- NOTIFY When to send a DSN. Multiple options are OK, comma -
26 214- delimited. NEVER must appear by itself.
27 214- ORCPT Original recipient.
28 214 End of HELP info
29 HELP ETRN
30 214-ETRN [ <hostname> | @<domain> | #<queuename> ]
31 214- Run the queue for the specified <hostname>, or
32 214- all hosts within a given <domain>, or a specially-named
33 214- <queuename> (implementation-specific).
34 214 End of HELP info
35 QUIT
36 221 shadrach.smallorg.org closing connection
37 Connection closed by foreign host.
38 [katie@shadrach katie]$В строке 6 задана SMTP-команда EHLO для подключения к серверу SMTP. Строки 7–16 отображают ответ сервера. Заметьте, сервер сигнализирует о том, что для использования доступно больше команд, т.е. сеанс происходит в «расширенном» режиме. Одна из новых групп команд называется параметрами уведомления о доставке сообщения (Delivery Status Notification). Эти параметры могут использоваться с командами MAIL и RCPT для отображения состояния доставки определенного сообщения электронной почты. Однако для нас как администраторов почтовой системы наибольший интерес представляет команда ETRN.
Команда TURN уже упоминалась ранее. Эта команда весьма эффективна, но, к сожалению, небезопасна. Чтобы компенсировать этот недостаток, в RFC 1985 определена новая реализация команды TURN, которая обеспечивает больший уровень безопасности. Команда ETRN позволяет SMTP-клиенту выдавать запрос на SMTP-сервер для того, чтобы инициировать еще одно SMTP-соединение с клиентом для передачи ему сообщений. Единственное отличие команды ETRN от TURN заключается в том, что запрос поступает не на использование существующего соединения, а на открытие нового сеанса SMTP. Таким образом, SMTP-сервер может соединиться с клиентским компьютером с помощью обычных алгоритмов преобразования имен системы DNS. При этом открытие нового соединения основывается не на том имени, под которым клиентский компьютер регистрируется на сервере, а на реальном имени хоста клиента. В таком случае, если хакер установит несанкционированное SMTP-соединение и воспользуется командой ETRN, то сервер SMTP просто организует новое соединение с реальным клиентом и перешлет ему электронную почту. В результате, пострадавших нет. Формат команды ETRN следующий:
Здесь в роли name может выступать либо имя хоста, либо доменное имя (если поступает запрос на получение почты для всего домена). Команда ETRN весьма хорошее подспорье для администратора электронной почты. Если почту для вашего почтового сервера хранит провайдер Internet, то с помощью этой команды можно уведомить его о готовности к приему собранной для вас почты. Существует несколько способов реализации такого алгоритма. Один из них — использование специальной программы Perl, которая поставляется с программой sendmail. Ее работа как раз и заключается в том, что после установления соединения с провайдером Internet она выдает команду ETRN с именем вашего домена в качестве аргумента. Получив эту команду, сервер SMTP провайдера инициирует еще одно SMTP-соединение с вашим локальным SMTP-сервером (по тому же РРР-соединению) и отдает всю предназначенную для вашего домена почту, которая имеется у него в очереди на отправку.
smtp.txt · Последние изменения: 2018/07/22 12:29 (внешнее изменение)
wiki.dieg.info
SMTP протокол — что это такое, где используется.
Что такое SMTP — описание?
На протяжении нескольких десятков лет, пользователи сети Интернет используют электронную почту, чтобы обмениваться сообщениями и письмами. До начала 90-х годов прошлого века электронными сообщениями пользовались, как правило, сотрудники крупных организаций. С обширной компьютеризацией и распространением всемирной паутины, электронные письма прочно вошли в жизнь обычных пользователей.
Развитие интернет технологий привело к появлению так называемых почтовых протоколов, используемых для сетевой переписки. Они делают возможной обработку больших по размеру писем, оказывая пользователям всевозможные сервисные услуги.
Он не стеснен какими-либо конкретными подсистемами передачи данных. Его работа нуждается только в надежном канале потока их передачи с сохранением порядка.
SMTP используется, в основном, для отправки писем и обращений пользователей на сервер, после чего происходит отправка почты получателям. Для того, чтобы получить письма, нужно чтобы почтовый клиент работал на протоколе IMAP или же POP3.
Для чего используется?
Простой протокол впервые опубликован в 1982 г. Использовался он как дополнительное приложение к популярному тогда клиенту — Unix Copy Program. Первым клиентом, работающим под стеком SMTP, стал Sendmail.
На сегодняшний день это типовой почтовый протокол. Его используют все почтовые программы и серверы.
Виртуальный хостинг сайтов для популярных CMS:
Принцип работы протокола.
SMTP — текстовый протокол, его принцип работы требует соединения, по которому пользователь, отправляющий электронное письмо, связывается с его получателем используя определенную командную строку. А получение данных происходит посредством использования надежного канала связи. Как правило, этим каналом связи является соединение TCP.
Рабочая сессия протокола состоит из отправляемых mail — клиентом SMTP ряда команд и ответов на них сервера. При рабочей сессии и клиент, и сервер обмениваются необходимыми параметрами.
Операция протокола включает в себя комбинацию, состоящую из следующих последовательностей команд и ответов:
- Команда MAIL FROM — обозначивает обратный электронный адрес;
- Команда RCPT TO — определяет получателя конкретного письма;
- DATA — это команда, отвечающая за отправку текста электронного сообщения. Это тело письма, которое включает в себя заголовок и текста письма, разделенных между собой пустой строкой.
Первоначальным SMTP-клиентом вполне может выступать почтовый клиент получателя, или агент пересылки корреспонденции на сервере.
Как работают другие почтовые протоколы.
SMTP является лишь протоколом доставки корреспонденции в сети. Он не может по команде взять электронное сообщение с удаленного сервера или как-то управлять e-mail ящиком.
Для этого существуют другие протоколы, например IMAP и POP. Их использование предпочтительнее при временном подключении к сети или когда ПК включается периодически.
POP.
Post Office Protocol – это простой сетевой протокол, включающий в себя три разновидности: POP, POP2 и POP3. Разработаны они для того, чтобы доставлять корреспонденцию пользователю с центрального почтового сервера, для удаления почты с сервера и для идентификации пользователя. Для идентификации используется сочетание логина и пароля. Стоит отметить, что все три протокола не взаимозаменяемы.
Протокол включает SMTP, используемый для передачи исходящей почты.
В соответствии с POP3, письма, поступающие на определенный e-mail сохраняются на сервере до загрузки их на ПК во время очередного сеанса. Когда загрузка произошла, становится возможным прочитать сообщения, отключившись от сети. Считается, что POP3 — самый быстрый почтовый протокол.
IMAP.
С помощью Internet Message Access Protocol становится возможным хранение сообщений в директориях файлов на сервере и производить поиск любых строк сообщений прямо там.
Данный протокол подходит тем пользователям, компьютеры которых используют непрерывное подключение к интернету. Его отличие от POP в том, что при проверке новых писем загружаются только их заголовки.
www.ipipe.ru
Почтовая кухня #2: SMTP / Habr
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…Код 220 говорит об успешном соединении
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
EHLO [91.198.212.5] #Приветствуем сервер и отсылаем ему наш внешний IP (IP не обязательно отсылать, можно обойтись просто EHLO, но сервер скорее всего на это ругнется)
UPD: Желательно отправлять даже не IP а доменное имя для этого IP вродеEHLO you.provider.domain без квадратных скобок
Ответ:
250-smtp18.yandex.ru Hello 91.198.212.5Сервер принял приветствие и выслал список поддерживаемых команд. Из этого списка нас интересует AUTH LOGIN. Это команда для авторизации на сервере по base64-закодированному логину и паролю. Так вот, нужно заранее подготовить закодированные в base64 пароль и логин от вашей почты. Можно это сделать, например, здесь seriyps.ru/crypt или командой в Linux echo [ваш пароль/логин] | base64
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 # Сообщаем серверу о намерении пройти авторизацию
Ответ:
334 VXNlcm5hbWU6Этот самый VXNlcm5hbWU6 — закодированное в base64 слово “Username:”, а номер ответа 3ХХ означает, что сервер ждет от нас дополнительной информации. Не будем его огорчать:
ВАШ_ЛОГИН_ПОЧТЫ_В_BASE_64 #Отправляем ваш логин почты в base64, например dmFzaWFwdXBraW4=
Ответ:
334 UGFzc3dvcmQ6Это, как можно догадаться, “Password:” в base64
ВАШ_ПАРОЛЬ_ПОЧТЫ_В_BASE_64 # Отправляем пароль почты в base64, например MTIzNDU2
Ответ:
235 Authentication successful.т.е. авторизация прошла успешно. Теперь можно отправлять e-mail)
MAIL FROM: [email protected] # Сообщаем, что хотим отправить почту с адреса [email protected] Адрес может быть любым (в том числе с несуществующих доменов, однако он может проверяться при проверке на спам)
Ответ:
250 2.1.0 Sender syntax Ok;
RCPT TO: [email protected] # Сообщаем, что хотим отправить письмо на адрес [email protected]
Ответ:
250 2.1.5 Recipient address syntax Ok; rcpt=<[email protected]>
DATA # Здесь сообщаем, что начинаем передачу данных.
Ответ:
354 Start mail input; end with <CRLF>.<CRLF>Т.е. сервер будет считывать введенные в консоли данные до того момента, пока мы не нажмем Энтер точка Энтер (после этой комбинации письмо сразу отправляется)
Электронное письмо состоит из следующих частей:
- Заголовков SMTP-протокола (то, что мы вводим при MAIL FROM: и RCPT TO: плюс некоторая служебная информация)
- Заголовков письма. (отправитель, обратный адрес, адресат, отметки о спам-проверках, тема письма, MIME-тип, кодировка и т.п.)
- Тела письма. (отделяется от заголовков пустой строкой, обычный ASCII текст либо соответствующий mime типу набор данных)
Начинаем вводить заголовки письма. Можно вставить и файл, закодированный в base64 но это уже немного выходит за рамки статьи:
From: Vasia Pupkin <[email protected]> #Заголовок для поля От
To: Billy G <[email protected]> #Заголовок для поля Кому
Subject: Hello Billy # Заголовок для темы сообщения
(Кстати, хочу заметить, что MAIL FROM: [email protected] и From: Вася Пупкин вовсе не обязаны совпадать! т.е. можно отправить почту с яндекса а притвориться, что она отправлена с mail.ru например… Что поделать — протоколу уже почти 30 лет. Хотя это не очень-то сложно вычислить…)
Два раза Энтер, затем вводим сам текст письма.
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.
Это все. Как видно, протокол довольно простой, основные сложности — в формировании самого тела письма.
Резюмируя:telnet smtp.yandex.ru 2025
EHLO 91.198.212.5
AUTH LOGIN
ВАШ_ЛОГИН_ПОЧТЫ_В_BASE_64
ВАШ_ПАРОЛЬ_ПОЧТЫ_В_BASE_64
MAIL FROM: [email protected]
RCPT TO: [email protected]
DATA
From: Вася Пупкин <[email protected]>
To: Билли Г <[email protected]>
Subject: Hello Billy
Hello, Billy! You will be die tomorrow!
Энтер . Энтер
QUIT
Конечно, здесь не приведена информация по отправке почты в кодировках текста, отличных от ASCII, не написано про вложенные файлы и MIME но если вам нужны подробности, вот несколько ссылок:
Электронная_почта Wiki
SMTP Wiki
MIME Wiki
rfc5321
При разработке приложений непосредственно с SMTP обычно работать не приходится, для этого используют различные фреймворки или стандартные функции. Для PHP можно посмотреть:
SMTP PEAR расширение
PHPMailer библиотека для работы с электронной почной
Удачных экспериментов!
habr.com
Simple Mail Transfer Protocol — это… Что такое Simple Mail Transfer Protocol?
| Название: | Simple Mail Transfer Protocol |
|---|---|
| Уровень (по модели OSI): | Прикладной |
| Семейство: | TCP/IP |
| Порт/ID: | 25/TCP |
| Назначение протокола: | Отправка электронной почты |
| Основные реализации (клиенты): | MUA (The Bat!, MS Outlook, MS Outlook Express, Mozilla Thunderbird) |
| Основные реализации (серверы): | MTA (postfix, exim) |
| Расширяемость: | Доп. команды (RFC 2449) |
SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.
ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают ESMTP и его расширения.
Обзор протокола
SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты почтовый клиент должен использовать протоколы IMAP.
Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (англ. Mail eXchange — обмен почтой) системы Exim[1]) для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись (RFC 2782).
Широкое распространение SMTP получил в начале 1980-х годов. До него использовался протокол UUCP, который требовал от отправителя знания полного маршрута до получателя и явного указания этого маршрута в адресе получателя, либо наличия прямого коммутируемого или постоянного соединения между компьютерами отправителя и получателя.
агентом отправки сообщений, который начал работать с SMTP. В настоящее время протокол SMTP является стандартным для электронной почты и его используют все клиенты и серверы.
Протокол был разработан для передачи только текста в кодировке MIME, который описывает способ преобразования двоичных файлов в текстовые. В настоящее время большинство серверов поддерживают 8BITMIME, позволяющий отправлять двоичные файлы так же просто, как текст.
Сервер SMTP — это конечный автомат с внутренним состоянием. Клиент передает на сервер строку команда<пробел>параметры<перевод строки>. Сервер отвечает на каждую команду строкой, содержащей код ответа и текстовое сообщение, отделенное пробелом. Код ответа — число от 100 до 999, представленное в виде строки, трактующийся следующим образом:
- 2ХХ — команда успешно выполнена
- 3XX — ожидаются дополнительные данные от клиента
- 4ХХ — временная ошибка, клиент должен произвести следующую попытку через некоторое время
- 5ХХ — неустранимая ошибка
Текстовая часть ответа носит справочный характер и предназначен для человека, а не программы.
ESMTP — расширяемый протокол, в отличие от SMTP. При установлении соединения сервер объявляет о наборе поддерживаемых расширений (в качестве ответа на команду EHLO). Соответствующие расширения могут быть использованы клиентом при работе. Необходимо помнить, что если сессия начинается с команды HELO (используемой в «классическом» SMTP, RFC 821), то список расширений выводиться не будет.
Безопасность SMTP и спам
Изначально SMTP не поддерживал единой схемы авторизации. В результате этого спам стал практически неразрешимой проблемой, так как было невозможно определить, кто на самом деле является отправителем сообщения — фактически можно отправить письмо от имени любого человека. В настоящее время производятся попытки решить эту проблему при помощи спецификаций SPF, Sender ID, Yahoo Domain Keys. Единой спецификации на настоящий момент не существует.
Пример простейшей SMTP-сессии
C: — клиент, S: — сервер
S: (ожидает соединения) C: (Подключается к порту 25 сервера) S:220 mail.company.tld ESMTP CommuniGate Pro 5.1.4i is glad to see you! C:HELO S:250 domain name should be qualified C:MAIL FROM: <[email protected]> S:250 [email protected] sender accepted C:RCPT TO:<[email protected]> S:250 [email protected] ok C:RCPT TO: <[email protected]> S:550 [email protected] unknown user account C:DATA S:354 Enter mail, end with "." on a line by itself C:Hi! C:. S:250 769947 message accepted for delivery C:QUIT S:221 mail.company.tld CommuniGate Pro SMTP closing connection S: (закрывает соединение)
В результате такой сессии письмо будет доставлено адресату [email protected], но не будет доставлено адресату [email protected], потому что такого адреса не существует.
Расширения ESMTP
RFC 1869 предписывает начинать сессию не командой HELO, а командой EHLO. В случае, если сервер не поддерживает расширений, то он ответит на EHLO ошибкой, в этом случае клиент должен послать команду HELO и не использовать расширения протокола.
Если же сервер поддерживает ESMTP, то кроме приветствия он сообщит список поддерживаемых расширений протокола SMTP, например:
ehlo office.company1.tld 250-mail.company2.tld is pleased to meet you 250-DSN 250-SIZE 250-STARTTLS 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-TURN 250-ATRN 250-NO-SOLICITING 250-HELP 250-PIPELINING 250 EHLO
Стандарты RFC
- RFC 1870 SMTP Service Extension for Message Size Declaration (заменяет RFC 1653)
- RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes
- RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30)
- RFC 2554 SMTP Service Extension for Authentication
- RFC 2821 The Simple Mail Transfer Protocol (заменяет RFC 821 aka STD 10, RFC 974 и RFC 1869)
- RFC 2822 Internet Message Format (заменяет RFC 822 aka STD 11)
- RFC 2920 SMTP Service Extension for Command Pipelining (STD 60)
- RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages
- RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (заменяет RFC 2487)
- RFC 3461 SMTP Service Extension for Delivery Status Notifications (заменяет RFC 1891)
- RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (заменяет RFC 1892)
- RFC 3463 Enhanced Status Codes for SMTP (заменяет RFC 1893)
- RFC 3464 An Extensible Message Format for Delivery Status Notifications (заменяет RFC 1894)
- RFC 3552 Guidelines for Writing RFC Text on Security Considerations
- RFC 3834 Recommendations for Automatic Responses to Electronic Mail
- RFC 4409 Message Submission for Mail (заменяет RFC 2476)
Примечания
- ↑ Спецификация Exim MTA Описание dnslookup роутера(англ.)
См. также
dic.academic.ru
Почтовые SMTP-порты — значение, особенности и описание :: SYL.ru
Simple Mail Transfer Protocol (SMTP) — это стандарт для e-mail-почты. Изначально был зафиксирован в RFC 821 (1982 г.), последний раз обновлялся в 2008 году с расширенными добавлениями SMTP по RFC 5321 (широко распространенным сегодня протоколом).
Хотя почтовые серверы и другие почтовые агенты применяют SMTP для передачи и получения e-mail-корреспонденции, программное обеспечение пользовательского класса, как правило, использует SMTP-порты только для отправки данных на сервер для ретрансляции. Для получения сообщений клиентские приложения обычно используют либо IMAP, либо POP3. Данные протоколы наиболее удобны и востребованы для этих целей: имеют расширенный функционал и широкий спектр возможностей.
Характерные особенности
SMTP-связь между почтовыми серверами использует порт TCP 25. Почтовые клиенты часто отправляют исходящие письма на почтовый сервер по порту 587. Несмотря на то что устаревшие почтовые провайдеры по-прежнему разрешают использовать нестандартный порт 465 для этой цели.
SMTP-соединения, защищенные TLS, известные как SMTPS, могут быть выполнены с использованием технологии STARTTLS.
Запатентованные системы и системы электронной почты используют свои собственные нестандартные протоколы для доступа к почтовым ящикам на своих почтовых серверах — все компании используют порты SMTP-сервера, когда отправка или получение электронной почты происходят за пределами их собственных систем.
Назначение SMTP
Почти все действия в Интернете становятся возможными благодаря протоколам — специальным правилам сетевого программного обеспечения, которые позволяют компьютеру связываться со всеми сетями, чтобы пользователи могли делать покупки, читать новости, отправлять электронную почту. Протоколы жизненно важны для повседневной сетевой деятельности — они встроены в сетевое программное обеспечение и используются по умолчанию.
Протокол SMTP-порта предоставляет набор кодов, которые упрощают обмен сообщениями электронной почты между серверами (сетевой компьютер, который обрабатывает входящую и исходящую электронную почту). Это своего рода сокращение, которое позволяет серверу разбить разные части сообщения на категории, которые может понять другой сервер. Когда пользователь отправляет сообщение, оно превращается в строки текста, разделенные кодовыми словами (или цифрами), которые определяют назначение каждого раздела.
Техническая терминология
SMTP — это протокол TCP/IP, используемый для работы с e-mail-почтой. Однако поскольку он ограничен возможностью отправлять сообщения в очередь на принимающей стороне, он обычно используется либо с POP3, либо с IMAP, которые позволяют хранить данные на сервер и при необходимости загружать их. Иными словами, обычно используют приложение, которое выбирает SMTP для отправки e-mail и POP3 или IMAP для получения корреспонденции. В системах на основе Unix sendmail является наиболее широко используемым SMTP-сервером для электронной почты. В коммерческий пакет Sendmail входит сервер POP3. Microsoft Exchange включает в себя SMTP-сервер и так же может быть настроен на поддержку POP3.
SMTP, как правило, используется для работы через интернет-порт 25. Альтернативой SMTP, который широко используется в Европе, является X.400. Многие почтовые серверы теперь поддерживают Extended Simple Mail Transfer Protocol (ESMTP), который позволяет передавать мультимедийные файлы в виде электронной почты.
История
В 1960-х годах использовались разные формы обмена электронными сообщениями. Пользователи общались с помощью систем, созданных для конкретных мэйнфреймов. Поскольку все больше компьютеров становились взаимосвязанными, появилась необходимость в разработке стандартов, позволяющих пользователям разных систем отправлять электронную почту друг другу. SMTP возник из этих стандартов, разработанных в 1970-х годах.
Дальнейшие реализации включают FTP Mail Protocol, начиная с 1973 года. Работа по развитию продолжалась в 1970-х гг., пока ARPANET не перешла в современный Интернет в 1980 году. Затем Джон Постель предложил протокол передачи почтовых данных.
SMTP начал широко применяться в начале 1980-х гг. В то время данный протокол был дополнением к Unix для почтовой программы Unix Copy Program. SMTP лучше всего работает, когда отправляющая и принимающая машины подключены к Сети, используют механизм хранения и отправки и являются примерами технологии push.
Модель обработки почты
E-mail-почта отправляется почтовым клиентом (почтовым агентом пользователя, MUA) на почтовый сервер (агент отправки почты, MSA) с использованием SMTP на TCP-порт 587. Большинство провайдеров почтовых ящиков по-прежнему разрешают отправку на традиционный порт 25. MSA доставляет почту на свой почтовый агент (агент передачи почты, MTA). Зачастую эти агенты являются экземплярами общего программного обеспечения, активированного с различными параметрами на одном компьютере. Локальная обработка может выполняться либо на одной машине, либо разделяться между несколькими машинами. Процессы почтового агента на одной машине могут обмениваться файлами, но если обработка выполняется на нескольких машинах, они передают сообщения между собой, используя SMTP-порт, где каждая машина настроена на использование следующей машины в качестве интеллектуального хоста.
Обзор протокола
SMTP представляет собой текстовый протокол, ориентированный на соединение, в котором отправитель почты общается с почтовым получателем путем выдачи командных строк и предоставления необходимых данных по надежному упорядоченному каналу потока данных. Сеанс SMTP состоит из команд, созданных SMTP-клиентом (инициирующим агентом, отправителем или передатчиком) и соответствующими ответами от SMTP-сервера (агента прослушивания или получателя). Сеанс может включать в себя ноль или более SMTP-транзакций, которые состоят из трех последовательностей команд/ответов:
MAIL (сервер mail.ru SMTP-порта), чтобы установить обратный адрес, также называемый обратный путь.
RCPT, чтобы установить получателя сообщения. Эта команда может выдаваться неоднократно, но один раз для каждого пользователя.
DATA, чтобы сигнализировать начало текста и его содержание. Данный параметр состоит из заголовка и тела сообщения, разделенного пустой строкой. DATA представляет собой группу команд, на которую сервер отвечает дважды: один раз для самой команды DATA, чтобы подтвердить, что он готов принять данные, повторно — после окончания последовательности информации, чтобы принять или отклонить все сообщение.
Помимо промежуточного ответа для DATA, ответ каждого сервера может быть либо положительным, либо отрицательным (код 2xx). Отрицательные ответы могут быть постоянными (коды 5xx) или временными (коды 4xx). Отклонение — это постоянный сбой, и клиент должен отправить сообщение отказов на сервер, на который он его получил. Падение — это положительный ответ, за которым следует отказ от сообщения.
Почтовые SMTP-порты и их значение
SMTP — только протокол доставки. При обычном использовании почта отправляется на целевой почтовый сервер, например, SMTP-сервер порта mail. Данные маршрутизируются на основе целевого сервера, а не отдельных пользователей, к которым он адресован. Другие протоколы (POP или IMAP) специально разработаны для использования отдельными пользователями, которые получают сообщения и управляют почтовыми ящиками. SMTP, POP и IMAP являются неприемлемыми протоколами для ретрансляции почты с помощью компьютеров с прерывистой связью. Они предназначены для работы после окончательной доставки, когда информация, критически важная для правильной работы почтового ретранслятора, была удалена.
Пуск очереди пустых сообщений
Remote Message Queue Starting — это функция SMTP, которая позволяет удаленному хосту запустить обработку почты на сервере, чтобы она могла получать сообщения, предназначенные для нее, отправив команду TURN. Однако эта функция создавала потенциальную угрозу безопасности данных и была расширена в RFC 1985 командой ETRN, которая более надежно работает с использованием метода аутентификации на основе информации о системе доменных имен.
Международный адрес электронной почты
Пользователи, чей сценарий не является латинским, или которые используют диакритические символы не в наборе символов ASCII, испытывали трудности с требованием адреса электронной почты латинского алфавита (SMTP-порт mail.ru). RFC 6531 был создан для решения этой проблемы, предоставляя возможности интернационализации для SMTP, расширения SMTPUTF8 и поддержки многобайтовых и не-ASCII-символов в адресах электронной почты. Примеры: диакритические знаки и другие языковые символы (греческий и китайский). Также актуально для SMTP-порта Yandex.
Текущая поддержка этого документа на данный момент ограничена, но есть большой интерес к широкому внедрению RFC 6531 и соответствующих RFC в таких странах, как Китай, которые имеют большую пользовательскую базу, где Latin (ASCII) является иностранным сценарием.
Исходящая почта SMTP-сервера
Клиент электронной почты должен знать IP-адрес своего исходного SMTP-сервера. Это должно быть указано как часть его конфигурации (обычно это имя DNS). Этот сервер будет предоставлять исходящие сообщения от имени пользователя.
Ограничения доступа к серверу исходящей почты
Администраторам сервера необходимо наложить определенный контроль на тех клиентов, которые могут использовать сервер. Это позволяет бороться со злоупотреблениями и спамом. Широко использовались подобные решения:
раньше многие системы вводили ограничения на использование местоположения клиента, разрешая только использование клиентами, чей IP-адрес является одним из администраторов сервера. Использование с любого другого IP-адреса клиента запрещено.
Современные SMTP-серверы обычно предлагают альтернативную систему, требующую аутентификации клиентов по учетным данным, прежде чем разрешать доступ.
SMTP — какой порт используется?
Связь между почтовыми серверами обычно всегда использует стандартное значение порта TCP 25, назначенного для SMTP. Тем не менее почтовые клиенты обычно вместо этого используют определенные порты порта smtp ssl. Большинство провайдеров интернет-услуг теперь блокируют весь трафик исходящего порта от своих клиентов в качестве меры защиты от спама. По той же причине предприятия обычно настраивают свой брандмауэр, чтобы разрешить исходящий порт с назначенных почтовых серверов.
Пример транспорта SMTP
Типичный пример отправки сообщения через SMTP на два почтовых ящика (alice и theboss), расположенных в одном и том же почтовом домене (example.com или localhost.com), воспроизводится в следующем сеансе обмена. После того как отправитель сообщения (клиент SMTP) устанавливает надежный канал связи для приемника сообщений (SMTP-сервер), сеанс открывается с сервером, обычно содержащим его полное доменное имя (FQDN), в этом случае smtp, example или com. Клиент инициирует свое диалоговое окно, отвечая командой HELO, идентифицирующей себя в параметре команды с его полным доменным именем (или литералом адреса, если он недоступен).
Дополнительные расширения
Клиенты узнают, какие опции поддерживает сервер, используя приветствие EHLO, вместо исходного HELO. Клиенты возвращаются в HELO только в том случае, если сервер не поддерживает расширения SMTP.
Современные клиенты могут использовать ключевое слово SSRE расширения ESMTP для запроса сервера для максимального размера сообщения, которое будет принято. Старые клиенты и серверы могут пытаться передавать сообщения с избыточным размером, которые будут отклонены после использования сетевых ресурсов, включая время подключения к сетевым ссылкам.
Методы защиты от спама и аутентификация по электронной почте
Исходный дизайн SMTP не имел возможности идентифицировать отправителей или проверять, разрешено ли серверам отправлять от их имени. В результате возможно использование спуфинга электронной почты, что обычно используется в почтовом спаме и фишинге.
Производятся специальные предложения для изменения SMTP или их замены полностью. Одним из примеров этого является Internet Mail 2000, но ни он, ни какой-либо другой не добились большого успеха перед сетевым эффектом огромной установленной базы классического SMTP. Вместо этого почтовые серверы теперь используют целый ряд методов, в том числе DomainKeys, DomainKeys Identified Mail, Policy Policy Framework и DMARC, DNSBLs и greylisting для отклонения или карантина подозрительных писем.
www.syl.ru
Описание протокола SMTP | Протоколы
Основная задача протокола SMTP (Simple Mail Transfer Protocol) заключается в том, чтобы обеспечивать передачу электронных сообщений (почту). Для работы через протокол SMTP клиент создаёт TCP соединение с сервером через порт 25. Затем клиент и SMTP сервер обмениваются информацией пока соединение не будет закрыто или прервано. Основной процедурой в SMTP является передача почты (Mail Procedure). Далее идут процедуры форвардинга почты (Mail Forwarding), проверка имён почтового ящика и вывод списков почтовых групп. Самой первой процедурой является открытие канала передачи, а последней — его закрытие.
Команды SMTP указывают серверу, какую операцию хочет произвести клиент. Команды состоят из ключевых слов, за которыми следует один или более параметров. Ключевое слово состот из 4-х символов и разделено от аргумента одним или несколькими пробелами. Каждая командная строка заканчивается символами CRLF. Вот синтаксис всех команд протокола SMTP (SP — пробел):
HELO <SP> <domain> <CRLF> MAIL <SP> FROM:<reverse-path> <CRLF> RCPT <SP> TO:<forward-path> <CRLF> DATA <CRLF> RSET <CRLF> SEND <SP> FROM:<reverse-path> <CRLF> SOML <SP> FROM:<reverse-path> <CRLF> SAML <SP> FROM:<reverse-path> <CRLF> VRFY <SP> <string> <CRLF> EXPN <SP> <string> <CRLF> HELP <SP> <string> <CRLF> NOOP <CRLF> QUIT <CRLF>
Обычный ответ SMTP сервера состоит из номера ответа, за которым через пробел следует дополнительный текст. Номер ответа служит индикатором состояния сервера.
Отправка почты
Первым делом подключаемся к SMTP серверу через порт 25. Теперь надо передать серверу команду HELLO и наш IP адрес:
C: HELLO 195.161.101.33 S: 250 smtp.mail.ru is ready
При отправке почты передаём некоторые нужные данные (отправитель, получатель и само письмо):
C: MAIL FROM:<drozd> 'указываем отправителя S: 250 OK C: RCPT TO:<[email protected]> 'указываем получателя S: 250 OK
указываем серверу, что будем передавать содержание письма (заголовок и тело письма)
C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF>
передачу письма необходимо завершить символами CRLF.CRLF
S: 250 OK C: From: Drozd <[email protected]> C: To: Drol <[email protected]> C: Subject: Hello
между заголовком письма и его текстом не одна пара CRLF, а две.
C: Hello Drol! C: You will be die on next week!
заканчиваем передачу символами CRLF.CRLF
Теперь завершаем работу, отправляем команду QUIT:
S: QUIT C: 221 smtp.mail.ru is closing transmission channel
> Другие команды
* SEND — используется вместо команды MAIL и указыает, что почта должна быть доставлена на терминал пользователя.
* SOML, SAML — комбинации команд SEND или MAIL, SEND и MAIL соответственно.
* RSET — указвает серверу прервать выполнение текущего процесса. Все сохранённые данные (отправитель, получатель и др) удаляются. Сервер должен отправить положительный ответ.
* VRFY — просит сервер проверить, является ли переданный аргумент именем пользователя. В случае успеха сервер возвращает полное имя пользователя.
* EXPN — просит сервер подтвердить, что переданный аргумент — это список почтовой группы, и если так, то сервер выводит членов этой группы.
* HELP — запрашивает у сервера полезную помощь о переданной в качестве аргумента команде.
* NOOP — на вызов этой команды сервер должен положительно ответить. NOOP ничего не делает и никак не влияет на указанные до этого данные.
www.internet-technologies.ru
Smtp — Традиция
SMTP (англ. Simple Mail Transfer Protocol — простой протокол передачи почты) — это сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP. ESMTP (англ. Extended SMTP) — масштабируемое расширение протокола SMTP. В настоящее время под «протоколом SMTP», как правило, подразумевают SMTP и его расширения.
Обзор протокола[править]
SMTP используется для отправки почты от пользователей к серверам и между серверами для дальнейшей пересылки к получателю. Для приёма почты почтовый клиент должен использовать протоколы POP3 или IMAP.
Данные передаются при помощи TCP, при этом обычно используется порт 25 или 587. При передаче сообщений между серверами обычно используется порт 25.
Чтобы доставить сообщение до адресата, необходимо переслать его почтовому серверу домена, в котором находится адресат. Для этого обычно используется запись типа MX (англ. Mail eXchange — обмен почтой) системы DNS. Если MX запись отсутствует, то для тех же целей может быть использована запись типа A. Некоторые современные реализации SMTP-серверов (например, Exim[1]) для определения сервера, обслуживающего почту в домене адресата, также могут задействовать SRV-запись (RFC 2782).
Широкое распространение SMTP получил в начале 1980-х годов. До него использовался протокол UUCP, который требовал от отправителя знания полного маршрута до получателя и явного указания этого маршрута в адресе получателя, либо наличия прямого коммутируемого или постоянного соединения между компьютерами отправителя и получателя.
Sendmail был одним из первых (если не первым) агентом отправки сообщений, который начал работать с SMTP.
В настоящее время протокол SMTP является стандартным для электронной почты и его используют все клиенты и серверы.
Протокол был разработан для передачи только текста в кодировке ASCII, кроме того, первые спецификации требовали обнуления старшего бита каждого передаваемого байта. Это не даёт возможности отсылать текст на национальных языках (например, кириллице), а также отправлять двоичные файлы (такие как изображения, видеофайлы, программы или архивы). Для снятия этого ограничения был разработан стандарт MIME, который описывает способ преобразования двоичных файлов в текстовые. В настоящее время большинство серверов поддерживают 8BITMIME, позволяющий отправлять двоичные файлы так же просто, как текст.
Сервер SMTP — это конечный автомат с внутренним состоянием. Клиент передает на сервер строку команда<пробел>параметры<перевод строки>. Сервер отвечает на каждую команду строкой, содержащей код ответа и текстовое сообщение, отделенное пробелом. Код ответа — число от 100 до 999, представленное в виде строки, трактующийся следующим образом:
- 2ХХ — команда успешно выполнена
- 3XX — ожидаются дополнительные данные от клиента
- 4ХХ — временная ошибка, клиент должен произвести следующую попытку через некоторое время
- 5ХХ — неустранимая ошибка
Текстовая часть ответа носит справочный характер и предназначен для человека, а не программы. ESMTP — расширяемый протокол, в отличии от SMTP. При установлении соединения сервер объявляет о наборе поддерживаемых расширений (в качестве ответа на команду EHLO). Соответствующие расширения могут быть использованы клиентом при работе. Необходимо помнить, что если сессия начинается с команды HELO (используемой в «классическом» SMTP, RFC 821), то список расширений выводиться не будет.
Изначально SMTP не поддерживал единой схемы авторизации. В результате этого спам стал практически неразрешимой проблемой, так как было невозможно определить, кто на самом деле является отправителем сообщения — фактически можно отправить письмо от имени любого человека. В настоящее время производятся попытки решить эту проблему при помощи спецификаций SPF, Sender ID, Yahoo Domain Keys. Единой спецификации на настоящий момент не существует.
Пример простейшей SMTP-сессии[править]
C: — клиент, S: — сервер S: (ожидает соединения) C: (Подключается к порту 25 сервера) S:220 mail.company.tld ESMTP CommuniGate Pro 5.1.4i is glad to see you! C:HELO S:250 domain name should be qualified C:MAIL FROM: <[email protected]> S:250 [email protected] sender accepted C:RCPT TO:<[email protected]> S:250 [email protected] ok C:RCPT TO: <[email protected] > S:550 [email protected] unknown user account C:DATA S:354 Enter mail, end with «.» on a line by itself C:Hi! C:. S:250 769947 message accepted for delivery C:QUIT S:221 mail.company.tld CommuniGate Pro SMTP closing connection S: (закрывает соединение) В результате такой сессии письмо будет доставлено адресату [email protected], но не будет доставлено адресату [email protected], потому что такого адреса не существует.
HELO <SP> <string><CRLF>— Идентифицирует SMTP-сервер отправителя, открывает сеанс
Пример HELO user.example.net 250 server.example.com Hello user.example.net [192.168.1.1] pleased to meet you
QUIT<CRLF>— Завершает SMTP-сеанс.
Пример QUIT 221 2.0.0 server.example.com closing connection
MAIL <SP> FROM:<reverse-path> <CRLF>— Задает адрес отправителя.
Пример MAIL FROM: [email protected] 250 2.1.0 [email protected]… Sender ok
RCPT <SP> TO:<forward-path> <CRLF>— Задает адрес получателя.
Пример RCPT TO: [email protected] 250 2.1.5 [email protected]… Recipient ok
DATA <CRLF>— Указывает на начало сообщения. Для окончания сообщения указывается<CRLF>.<CRLF>.
Пример: DATA 354 Enter mail, end with «.» on a line by itself this is a test message. . 250 2.0.0 l3PDY91f000484 Message accepted for delivery
VRFY <SP> <string><CRLF>— проверяет существование получателя.
Пример (пояснение чуть ниже): VRFY 252 2.5.2 Cannot VRFY user; try RCPT to attempt delivery (or try finger)
EXPN <SP> <string><CRLF>— показывает список адресов для списка рассылки.
Пример (пояснения чуть ниже): EXPN 502 5.7.0 Sorry, we do not allow this operation
NOOP<CRLF>— пустая операция
Пример: NOOP 250 2.0.0 OK
TURN<CRLF>— сервер и клиент меняются ролями после ответа сервера 200 OK
Пример: (команда не реализована) TURN 502 5.5.1 Command not implemented: «TURN»
RSET<CRLF>— сброс сессии в исходное состояние
Пример: RSET 250 2.0.0 Reset state
HELP<CRLF>— информация о поддерживаемых командах. Некоторые сервера поддерживают справку по отдельным командам, например,HELP MAIL(sendmail), некоторые выводят по этой команде лишь список доступных команд без пояснения (Microsoft Exchange Server).
Пример: HELP 214-2.0.0 This is sendmail version 8.12.9 214-2.0.0 Topics: 214-2.0.0 HELO EHLO MAIL RCPT DATA 214-2.0.0 RSET NOOP QUIT HELP VRFY 214-2.0.0 EXPN VERB ETRN DSN AUTH 214-2.0.0 STARTTLS 214-2.0.0 For more info use «HELP <topic>». 214-2.0.0 To report bugs in the implementation send email to 214-2.0.0 [email protected]. 214-2.0.0 For local information send email to Postmaster at your site. 214 2.0.0 End of HELP info HELP MAIL 214-2.0.0 MAIL FROM: <sender> [ <parameters> ] 214-2.0.0 Specifies the sender. Parameters are ESMTP extensions. 214-2.0.0 See «HELP DSN» for details. 214 2.0.0 End of HELP info Из-за проблем со спамом, почти все современные сервера игнорируют команды VRFY и EXPN, как раскрывающие информацию о пользователе.
RFC 1869 предписывает начинать сессию не командой HELO, а командой EHLO. В случае, если сервер не поддерживает расширений, то он ответит на EHLO ошибкой, в этом случае клиент должен послать команду HELO и не использовать расширения протокола.
Если же сервер поддерживает ESMTP, то кроме приветствия он сообщит список поддерживаемых расширений протокола SMTP, например:
ehlo office.company1.tld
250-mail.company2.tld is pleased to meet you
250-DSN
250-SIZE
250-STARTTLS
250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM
250-ETRN
250-TURN
250-ATRN
250-NO-SOLICITING
250-HELP
250-PIPELINING
250 EHLO
- RFC 1870 SMTP Service Extension for Message Size Declaration (заменяет RFC 1653)
- RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes
- RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30)
- RFC 2554 SMTP Service Extension for Authentication
- RFC 2821 The Simple Mail Transfer Protocol (заменяет RFC 821 aka STD 10, RFC 974 и RFC 1869)
- RFC 2822 Internet Message Format (заменяет RFC 822 aka STD 11)
- RFC 2920 SMTP Service Extension for Command Pipelining (STD 60)
- RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages
- RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (заменяет RFC 2487)
- RFC 3461 SMTP Service Extension for Delivery Status Notifications (заменяет RFC 1891)
- RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (заменяет RFC 1892)
- RFC 3463 Enhanced Status Codes for SMTP (заменяет RFC 1893)
- RFC 3464 An Extensible Message Format for Delivery Status Notifications (заменяет RFC 1894)
- RFC 3552 Guidelines for Writing RFC Text on Security Considerations
- RFC 3834 Recommendations for Automatic Responses to Electronic Mail
- RFC 4409 Message Submission for Mail (заменяет RFC 2476)
Прикладной уровень: HTTP, DHCP, IRC, SNMP, DNS, NNTP, XMPP, SIP, BitTorrent, XDR, IPP…
- Электронная почта: SMTP, POP3, IMAP4 • Передача файлов: FTP, TFTP, SFTP • Удалённый доступ: rlogin, Telnet, SSH
Транспортный уровень: TCP, UDP, SCTP, DCCP, RTP, RUDP…
Сетевой уровень: IPv4, IPv6, ARP, RARP, ICMP, IGMP
Канальный уровень: Ethernet, 802.11 WiFi, Token ring, FDDI, PPP, HDLC, SLIP, ATM, DTM, X.25, Frame Relay, SMDS, SDH, PDH, ISDN
Физический уровень: RS-232, EIA-422, RS-449, EIA-485…
eo:SMTP hu:Simple Mail Transfer Protocol ku:SMTP lt:SMTP lv:SMTP nn:Simple Mail Transfer Protocol
При написании этой статьи использовались материалы страницы «Smtp» Русской Википедии.
traditio.wiki