Почтовые SMTP-порты - значение, особенности и описание. Самое интересное про SMTP, POP3 и IMAP
Сегодня мы подробно расскажем про наиболее используемые в сети интернет протоколы – POP3, IMAP и SMTP. Каждый из указанных протоколов имеет определенное назначение и функциональные возможности. Давайте попробуем разобраться.
Протокол POP3 и его порты
Post Office Protocol 3 (POP3) это стандартный протокол почты созданные для получения электронных писем с удаленного сервера на e-mail клиент.POP3 позволяет вам сохранить почтовое сообщение на ваш компьютер и даже прочесть его, в случае, если вы находитесь не в сети. Важно отметить, что если вы решили использовать POP3 для подключения к учетной записи почты, письма, которые уже скачаны на компьютер, будут удалены с почтового сервера. Как пример, если вы используете несколько компьютеров для подключения к одному почтовому аккаунту, то протокол POP3 может быть не лучшим выбором в данной ситуации. С другой стороны, так как почта хранится локально, на ПК конкретного пользователя, это позволяет оптимизировать дисковое пространство на стороне почтового сервера.
По умолчанию, протокол POP3 использует следующие порты:
- Порт 110 – это порт протокола POP3 по умолчанию. Не является безопасным.
- Порт 995 – этот порт следует использовать в том случае, если вы хотите установить безопасное соединение.
Протокол IMAP и порты
Internet Message Access Protocol (IMAP) – это почтовый протокол, созданный для доступа к почте с локального почтового клиента. IMAP и POP3 – наиболее популярные в сети интернет протоколы, используемые для получения e-mail. Оба этих протокола поддерживается всеми современными почтовыми клиентами (MUA - Mail User Agent) и WEB – серверами.
В то время как POP3 позволяет доступ к почте только с одного приложения, IMAP позволяет доступ из множества клиентов. По этой причине, IMAP наиболее адаптивен в тех случаях, когда доступ к одному почтовому аккаунту необходим для нескольких пользователей.
По умолчанию, протокол IMAP использует следующие порты:
- Порт 143 – порт по умолчанию. Не безопасен.
- Порт 993 – порт для безопасного соединения.
Протокол SMTP и его порты
Simple Mail Transfer Protocol (SMTP) – это стандартный протокол для отправки почтовых сообщений по сети интернет.
Данный протокол описан в RFC 821 и RFC 822, впервые опубликованных в августе 1982 года. В рамках данных RFC, формат адреса должен быть в формате имя_пользователя@доменное_имя . Доставка почты, аналогична работе обычной почтовой службы: например, письмо на адрес [email protected], будет интерпретирован так: ivan_ivanov – адрес, а merionet.ru – почтовый индекс. Если доменное имя получателя отличается от доменного имени отправителя, то MSA (Mail Submission Agent) отправит письмо через Mail Transfer Agent (MTA). Главная идея MTA в том, чтобы перенаправлять письма в другую доменную зону, по аналогии, как традиционная почты отправляет письма в другой город или область. MTA так же получает почту от других MTA.
Протокол 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
Команда HELO
По определению, длина команд протокола SMTP четыре символа. Приветствие, выдаваемое клиентом на сервер, и есть команда HELO. Формат команды следующий:
HELO domain name
Смысл команды HELO заключается в представлении клиента серверу SMTP. К сожалению, этот метод доступа был разработан на начальной стадии развития сети Internet, когда еще не было столь большого числа попыток несанкционированного проникновения в компьютерные системы. Как видите, клиент может назвать себя любым именем в командной строке. Это привело к тому, что в настоящее время большинство серверов SMTP эту команду используют чисто формально. Если они действительно стараются идентифицировать клиента, то подключается механизм обратного преобразования DNS с целью определения действительного имени хоста клиента согласно системе доменных имен по его IP-адресу. Как правило, в целях безопасности серверы SMTP отказывают в установлении соединения хостам, IP-адрес которых не преобразуется в соответствующее имя хоста. Посылая данную команду, клиент уведомляет сервер о желании установить с ним соединение. Отвечая на эту команду, сервер, в свою очередь, уведомляет об установке нового соединения с клиентом и готовности принимать от него последующие команды.
При работе с протоколом 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)
Разница между PLAIN и LOGIN только в том, что в первом варианте передается логин+пароль одной строкой, а во втором варианте - сначала логин, затем пароль. Но все они кодируются обязательно в Base64 .
Команда MAIL
Команда MAIL используется для организации сеанса обмена электронной почтой с сервером после того, как была послана команда HELO. Она указывает, от кого исходит данное сообщение. Формат команды MAIL следующий:
MAIL reverse-path
Аргумент reverse-path не только определяет отправителя сообщения, но также указывает маршрут, по которому можно вернуть сообщение в случае невозможности его доставки. Если отправитель является пользователем на клиентском компьютере, который инициировал сеанс SMTP, то формат команды будет следующим:
MAIL FROM: [email protected]
Заметьте, что в поле FROM указывается адрес электронной почты отправителя сообщения, включая полное имя клиентского хост-компьютера. Эта информация должна присутствовать в поле FROM почтового сообщения (но об этом позже). Если почтовое сообщение проходило на пути от отправителя к получателю через несколько узлов, то каждый из них будет добавлять сведения о себе в поле
Команда 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). В этом случае он добавляет свое имя в поле
Хост shardrach не может переслать сообщение и уведомляет об этом отправителя, подтверждая в то же время правильность адреса хоста meshach.smallorg.org. Таким образом, отправитель может попытаться повторно отправить сообщение прямо на meshach.smallorg.org.
Хост shardrach не может переслать сообщение и посылает уведомление о том, что эту операцию невозможно осуществить с данным сервером. Тогда причины случившегося следует проанализировать системному администратору.
На начальной стадии развития сети Internet практиковалась пересылка сообщений электронной почты вслепую между компьютерами по всему миру, в которых использовался исходный алгоритм передачи почтовых сообщений.
Команда DATA
Эта команда является основной в протоколе SMTP. После обработки команд MAIL и RCPT команда DATA используется для передачи информационной части сообщения. Формат команды DATA следующий:
Все, что следует за этой командой, интерпретируется как сообщение для передачи. Сервер SMTP, как правило, дополняет заголовок сообщения меткой времени и информацией об обратном маршруте return-path. Программа-клиент обозначает конец сообщения посредством передачи строки с одной точкой. Формат этой строки следующий:
Приняв эту последовательность, сервер 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 prez@ mechach.smallorg.org 11 252 < prez@ mechach.smallorg.org> 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 username@ example.com 221 2.0.0 Bye
Команда NOOP
Команда NOOP - сокращение от no operation (англ. нет операции - Прим. пер.). Эта команда не оказывает никакого воздействия на SMTP-сервер, за исключением того, что сервер возвращает на нее позитивный код ответа. Она используется при тестировании соединения без пересылки сообщения.
Команда QUIT
Команда QUIT делает именно то, что она и означает (англ. выйти - Прим. пер.), т.е. сообщает SMTP-серверу о том, что клиентский компьютер закончил текущий сеанс и хочет закрыть соединение. Сервер SMTP должен ответить на эту команду, а затем инициировать и закрыть TCP-соединение. Если сервер принимает команду QUIT в процессе передачи почты, то все переданные в течение сеанса данные должны быть уничтожены и не поступят получателю.
Формат сообщений(EMail)
Стандартные поля заголовка, согласно RFC 822
Документом RFC 822 предусматривается разбиение сообщения на две части. Первая часть называется заголовком. В нее вносятся все данные, идентифицирующие сообщение. Вторая часть называется телом сообщения. Заголовок состоит из полей данных, которые используются по мере необходимости внесения дополнительной информации в сообщение. Поля заголовка и тело сообщения должны разделяться пустой строкой. Для полей заголовка не существует определенного порядка следования, т.е. поля заголовка могут располагаться в произвольном порядке. Кроме того, в одном сообщении поля заголовка могут повторяться. На рисунке представлен общий вид почтового сообщения, соответствующего требованиям RFC 822.
Формат сообщения, согласно RFC 822
Поле заголовка Received
Формат поля заголовка 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
Формат этого поля заголовка следующий:
Return-Path: route
Последний SMTP-сервер в цепочке пересылки добавляет к сообщению поле возврата (Return-Path). Его цель - определение маршрута, посредством которого сообщение достигло получателя. Если сообщение было послано напрямую на сервер получателя, то в этом поле будет отображаться только один адрес. В противном случае здесь будет отображаться полный список серверов, через которые прошло сообщение, чтобы достичь адресата. Может отличаться от MAIL FROM (то есть обратный адрес может быть указан отличным от адреса отправителя).
Поле заголовка Originator
В поле Originator указывается адрес отправителя сообщения. Эта информация весьма полезна в ситуации, когда сообщения были отвергнуты несколько раз частными сетями, прежде чем они попали в сеть Internet. Формат этого поля следующий:
Reply-To: address
Поле Originator является всего лишь небольшим вспомогательным полем в многоцветье полей заголовка. Оно может быть использовано в качестве более простого пути для небольших SMTP-пакетов. При этом необходимость в более сложных полях заголовка, по которым определяется отправитель, отпадает.
Поле заголовка Resent
Поле заголовка Resent идентифицирует почтовое сообщение, которое по какой-либо причине должно было повторно посылаться клиентом. Формат этого поля следующий:
Resent-Reply-To: address
Поля заголовка Authentic
Данные поля заголовка идентифицируют отправителя электронного сообщения. Формат полей 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
В полях заголовка 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 учитывается тип двоичного файла, подвергающегося преобразованию, а также передается дополнительная информация о файле для декодера. Алгоритм MIME позволяет помещать двоичные данные напрямую в стандартное почтовое сообщение, согласно RFC 822. Для описания двоичных данных, вкладываемых в сообщение формата RFC 822, были созданы пять новых полей заголовка. Программы для работы с почтой, которые поддерживают стандарт MIME, должны правильно обрабатывать все эти новые типы заголовков.
Поле заголовка MIME-Version
Первое из дополнительных полей заголовка содержит версию MIME, которую использовал отправитель при кодировании сообщения. В настоящее время в этом поле всегда 1.0.
Поле Content-Transfer-Encoding
В поле заголовка Content-Transfer-Encoding указывается способ помещения двоичных данных в сообщение текстового формата ASCII . На сегодняшний день существует семь различных способов кодирования двоичных данных, однако наиболее часто встречается кодирование base64. При применении этого метода кодирования 6-битовые блоки двоичных данных преобразуются в 8-битовые блоки, воспринимаемые как текст ASCII .
Поле Content-ID
Это поле заголовка используется для идентификации сеансов MIME по определенному идентификационному коду, когда содержимое имеет сложную структуру.
Поле Content-Description
Поле заголовка Content-Description используется для текстового описания в формате ASCII данных, помещенных в почтовое сообщение. Это удобно при пересылке документов, созданных при помощи текстового процессора или графики, которые ничем не отличаются, будучи закодированными base64.
Поле заголовка Content-Type
Поле заголовка 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 $ 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 , 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"
Листинг 5.6. Пример сеанса SMTP с несколькими вложениями MIME (html, txt) Пример сообщения, представленный в листинге 5.6, является сообщением MIME, которое состоит из двух частей. В строке 18 показан тип данных сообщения. Тип multipart/alternative указывает на то, что в сообщении имеются различные типы данных, которые отделены граничным разделителем bounds1. Данные первого типа начинаются со строки 21 и представляют собой простой ASCII -текст, который может прочесть практически любая почтовая программа.
Данные второго типа начинаются со строки 27 и представляют собой форматированный текст с использованием обогащенного текстового формата.
Так как тип MIME, указанный для сообщения, - multipart/alternative, то определение того, какую версию вложения отобразить, всецело зависит от почтовой программы.
Расширенный протокол SMTP
С момента своего появления в 1982 году протокол SMTP прекрасно справлялся со своими задачами по пересылке сообщений между компьютерами в сети Internet. Однако со временем стали заметны заложенные в протокол ограничения. Тогда, вместо того чтобы заменить стандартный протокол, имевший к тому времени широкое распространение, было решено улучшить некоторые функции протокола SMTP. При этом было принято решение, оставив все спецификации SMTP в первозданном виде, лишь добавить к ним новые функции.
В 1995 году увидел свет документ RFC 1869, где был определен метод расширения возможностей протокола SMTP, который назывался "Расширенные службы SMTP".
Расширенный SMTP (Extended SMTP) реализован следующим образом. В начале сеанса SMTP команда HELO заменена на команду приглашения - EHLO. Получение сервером SMTP такой команды означает, что клиент может посылать ему расширенные SMTP команды. В листинге 5.7 показан пример сеанса с использованием EHLO , а также дополнительных команд.
1 $ 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 , 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:
В строке 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-сервером (по тому же РРР-соединению) и отдает всю предназначенную для вашего домена почту, которая имеется у него в очереди на отправку.
Для обмена информации между компьютерами были разработаны стандарты передачи и обработки информации, которые назвали сетевыми протоколами. Наиболее распространены протоколы IP, ICMP, TCP, UDP, SMTP, POP/POP3, IMAP, HTTP/HTTPS и FTP, но существуют и другие, менее известные, такие как SSH, TELNET и другие.
Чтобы двое людей могли разговаривать, они должны владеть одним и тем же языком. Однако им не требуется строго придерживаться грамматике и формальных языковых структур, чтобы понимать друг друга. Для обмена информации между компьютерами все должно быть четко определено и структурировано. Поэтому следует использовать стандарты передачи и обработки различных видов информации. Протоколы установлены международным соглашением и гарантируют обмен информацией между любыми компьютерами в любом месте. Существует множество различных протоколов для различных нужд и типов информации.
IP, ICMP, TCP и UDP
IP (Internet Protocol – интернет протокол) и TCP (Transmission Control Protocol – протокол управления передачей) - это два совершенно различных протокола, которые обычно связывают друг с другом. Часто употребляются комбинации сразу нескольких протоколов, так как функции различных протоколов могут быть совмещены таким образом, чтобы получить решение поставленной задачи. В комбинации каждый протокол выполняет операции на своем уровне.
При передачи информации по интернету, её разбивают на мелкие части – интернет пакеты, которые передаются независимо друг от друга. Это существенно ускоряет передачу информации за счет того, что различные части могут передаваться по разным маршрутам, после чего вновь собираются на месте получения в единое целое. Это также мера предотвращения потери информации в процессе передачи. Протокол TCP отвечает за создание интернет пакетов и из обратную сборку в нужном порядке в месте получения, а также проверяет целостность информации. Если часть пакетов утеряна в процессе передачи, они передаются повторно.
Интернет протокол (IP) используется для доставки информации по нужному адресу. Каждый компьютер, который имеет подключение к интернету имеет свой уникальный адрес – . Каждый отправленный пакет содержит адрес доставки. Интернет пакет может пройти через много маршрутизаторов прежде, чем достигнет своего места назначения. Интернет протокол отвечает за маршрутизацию пакета к указанному компьютеру. IP не создает физических подключений между компьютерами. Он может быть использован совместно с другими протоколами, которые создают подключения.
Для передачи малых кусков информации можно использовать протокол UDP (User Datagram Protocol – протокол пользовательских дейтаграмм). Он также используется совместно с интернет протоколом, но намного проще чем TCP. В отличии от TCP, UDP не гарантирует доставку пакетов в нужной последовательности и не дублирует передачу утерянных пакетов, соответственно он потребляет меньше системных ресурсов, а скорость передачи существенно выше. Он применяется в приложениях которым, требуется большая пропускная способность линий связи, либо малое время доставки данных, например для аудио или видео связи.
Существует и совершенно иной протокол низкого уровня – ICMP (Internet Control Message Protocol – протокол межсетевых управляющих сообщений). В основном он используется в диагностических или сервисных целях, таких как передача сообщений об ошибках и других исключительных ситуациях, возникших при передаче данных, например, запрашиваемая услуга недоступна, или хост, или маршрутизатор не отвечают.
Почтовые протоколы – SMTP, POP, IMAP
Для передачи и получения электронной почты требуются свои собственные протоколы. Почту обычно отправляют по протоколу SMTP (Simple Mail Transfer Protocol – простой протокол передачи почты). Его также используют для передачи почты между почтовыми серверами. При настройке почтовых клиентов (например, Outlook Express) требуется указывать адрес SMTP сервера. Для получения почты с сервера почтового ящика почтовые клиенты обычно используют протокол POP (Post Office Protocol – протокол почтового отделения). На текущий момент действует его третья редакция (версия), которая называется POP3 (Post Office Protocol Version 3 – протокол почтового отделения, версия 3). Для возможности получения почты при настройке в почтовом клиенте необходимо указать адрес POP3 сервера. Адреса SMTP и POP3 серверов могут совпадать, а могут и не совпадать, их следует уточнить у почтового провайдера. Протоколы SMTP и POP3 работают совместно с TCP протоколом для передачи и доставки почты через интернет.
Существует и более функциональный, но менее известный протокол для чтения электронной почты – IMAP (Internet Message Access Protocol – протокол доступа к электронной почте интернета). Данный протокол позволяет получить доступ к письмам хранящимся в почтовом ящике на сервере без необходимости загрузки её на локальный компьютер. Это очень удобно, когда требуется доступ к письмам почтового ящика с нескольких компьютеров. IMAP также работает совместно с протоколом TCP.
Протоколы HTTP и HTTPS
Веб страницы используют язык разметки гипертекста (HTML – HyperText Markup Language). HTML страницы передаются через интернет по стандарту, который называется протокол передачи гипертекста (HTTP – HyperText Transfer Protocol). Основой HTTP является технология «клиент-сервер», то есть пользователь инициирует соединение к серверу для запроса информации, а сервер ожидает соединения для получения запроса, обрабатывает запрос и возвращают обратно сообщение с результатом. HTTP работает совместно с протоколом TCP. Адреса использующие HTTP протокол начинаются с „http:”.
С протоколом HTTP связан протокол HTTPS (HTTP over TLS – HTTP по TLS). Он обеспечивает шифрование при передачи данных для защиты конфиденциальной информации. Адреса URL использующие HTTP протокол начинаются с „https:”.
Протокол передачи файлов – FTP
Протокол передачи файлов (FTP – File Transfer Protocol) предназначен для передачи файлов в компьютерных сетях с одного компьютера на другой. Он обеспечивает возможность простого управления файлами на удаленном компьютере. Это достаточно старый протокол, который был введен в эксплуатацию до всемирной паутины (WWW – World Wide Web). В настоящее время он используется в основном для загрузки файлов на веб сервера, однако существуют и файловые хранилища, работающие по протоколу FTP. Он работает совместно с протоколом TCP. Адреса URL использующие FTP протокол начинаются с „ftp:”.
Для одновременной работы серверов по протоколам SMTP , POP , IMAP , HTTP , HTTPS , FTP и др. вовсе не требуются отдельные компьютеры или ip-адреса. Все эти сервера можно установить на один компьютер с одним ip-адресом. Это достигается за счет то, что каждый из протоколов использует свой .
На протяжении нескольких десятков лет, пользователи сети Интернет используют электронную почту, чтобы обмениваться сообщениями и письмами. До начала 90-х годов прошлого века электронными сообщениями пользовались, как правило, сотрудники крупных организаций. С обширной компьютеризацией и распространением всемирной паутины, электронные письма прочно вошли в жизнь обычных пользователей.
Развитие интернет технологий привело к появлению так называемых почтовых протоколов, используемых для сетевой переписки. Они делают возможной обработку больших по размеру писем, оказывая пользователям всевозможные сервисные услуги.
Он не стеснен какими-либо конкретными подсистемами передачи данных. Его работа нуждается только в надежном канале потока их передачи с сохранением порядка.
SMTP используется, в основном, для отправки писем и обращений пользователей на сервер, после чего происходит отправка почты получателям. Для того, чтобы получить письма, нужно чтобы почтовый клиент работал на протоколе IMAP или же POP3.
Для чего используется?
На сегодняшний день это типовой почтовый протокол. Его используют все почтовые программы и серверы.
Виртуальный хостинг сайтов для популярных 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 в том, что при проверке новых писем загружаются только их заголовки.
компьютер с локального компьютера. Для обмена сообщениями электронной почты между различными компьютерами с 1982 года применяется простой протокол передачи почты Simple Mail Transfer Protocol ( SMTP ). Легкость его применения и транспортируемость на различные платформы сделала этот протокол стандартным для обмена электронными сообщениями между компьютерными системами в сети Internet . Для того чтобы разобраться, как он работает, давайте рассмотрим, что он собой представляет.Описание протокола SMTP
Протокол SMTP был разработан для работы в различных сетях для транспортировки электронной почты. Однако одной из наиболее широко используемых стала сеть Internet , с установкой соединения TCP/IP через порт 25. Большинство версий ОС Linux автоматически устанавливают программный пакет по поддержке SMTP при установке различных сервисов. Для того чтобы убедиться в способности удаленного сервера работать по протоколу SMTP , можно войти на его порт 25, воспользовавшись программой telnet . Если будет получен ответ с этого порта, то на сервере запущен протокол SMTP . На локальном сервере можно проделать тоже самое, подключившись с помощью telnet на порт 25 на localhost . Пример сеанса telnet с сервером на базе ОС Linux показан в листинге 5.1.
1 $ 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; Wed, 25 Aug 1999 18:35:33 -0500 6 QUIT 7 221 shadrach.smallorg.org closing connection 8 Connection closed by foreign host. 9 $ Листинг 5.1. Пример сеанса telnet с портом 25
В строке 1 показан формат команды telnet с использованием хоста localhost и TCP-порта 25. В строке 5 показан типичный ответ сервера с ОС Linux, на котором установлен программный пакет для работы SMTP . Число, с которого начинается ответ, является трехзначным кодом ответа. Этот код может использоваться при поиске и устранении неполадок в работе электронной почты. Далее следует имя сервера SMTP и описание программного пакета SMTP , который распространяется организацией Sendmail Consortium. Строка 6 содержит команду QUIT на закрытие сеанса telnet . После этого сервер SMTP должен выдать сообщение о закрытии сеанса и разорвать TCP-соединение. Из данного примера можно сделать вывод о том, что протокол SMTP использует простые текстовые команды в формате ASCII и возвращает трехзначные кодированные ответы с текстовыми сообщениями. Протокол SMTP описывается документом Internet Request For Comment ( RFC ) номер 821, который был разработан группой Internet Engineering Task Force ( IETF ) и опубликован 21 августа 1982 года. С тех пор он претерпел несколько модификаций, но в целом основные команды протокола не изменились.
Основные команды клиента SMTP
После установления сеанса TCP сервер SMTP посылает клиенту специальное сообщение об установке соединения (как это показано в листинге 5.1). С этого момента управление соединением между двумя компьютерами осуществляется клиентом, подключившимся к серверу. Клиент управляет соединением при помощи набора специальных команд, которые он посылает серверу. Сервер, в свою очередь, должен соответствующим образом ответить на каждую посланную ему команду. В RFC 821 описаны основные команды для клиента SMTP, на которые сервер должен реагировать определенным образом. Хотя с момента создания этого документа появилось несколько расширений к протоколу SMTP, они пока поддерживаются не всеми почтовыми серверами. В этом разделе мы выделим лишь основные команды SMTP, определенные в RFC 821. В разделе "Расширения протокола SMTP" рассматриваются некоторые дополнения, реализованные в последних версиях пакета SMTP.
Формат команд в SMTP прост:
command ,
где command - четырехсимвольная команда протокола SMTP, а parameter - необязательный параметр, определяющий тип данных в команде. В табл. 5.1 приведены основные команды протокола SMTP. Далее мы рассмотрим эти команды более детально.
| Команда | Описание |
|---|---|
| HELO | Открывает приглашение от клиента |
| Определяет отправителя сообщения | |
| RCPT | Определяет получателей сообщения |
| DATA | Определяет начало сообщения |
| SEND | Посылает сообщение на терминал |
| SOML | Send-or-Mail |
| SAML | Send-and-Mail |
| RSET | Сброс SMTP-соединения |
| VRFY | Проверяет имя пользователя системы |
| EXPN | Запрашивает список псевдонимов |
| HELP | Запрашивает список команд |
| NOOP | No operation - Ничего не делать |
| QUIT | Остановить сеанс SMTP |
| TURN | Реверс ролей в SMTP (клиент становится сервером) |
Команда HELO
По определению, длина команд протокола SMTP четыре символа. Приветствие, выдаваемое клиентом на сервер, и есть команда HELO . Формат команды следующий:
HELO domain name
Смысл команды HELO заключается в представлении клиента серверу SMTP. К сожалению, этот метод доступа был разработан на начальной стадии развития сети Internet, когда еще не было столь большого числа попыток несанкционированного проникновения в компьютерные системы. Как видите, клиент может назвать себя любым именем в командной строке. Это привело к тому, что в настоящее время большинство серверов SMTP эту команду используют чисто формально. Если они действительно стараются идентифицировать клиента, то подключается механизм обратного преобразования DNS с целью определения действительного имени хоста клиента согласно системе доменных имен по его IP-адресу. Как правило, в целях безопасности серверы SMTP отказывают в установлении соединения хостам, IP-адрес которых не преобразуется в соответствующее имя хоста. Посылая данную команду, клиент уведомляет сервер о желании установить с ним соединение. Отвечая на эту команду, сервер, в свою очередь, уведомляет об установке нового соединения с клиентом и готовности принимать от него последующие команды.
Пользователи-клиенты и хосты-клиенты
При работе с протоколом SMTP следует различать клиентов SMTP. Пользователи-клиенты и хосты-клиенты не одно и то же. При создании почтового сообщения пользователь системы электронной почты является одновременно и клиентом своего локального хоста . После отправки почтового сообщения он уже не является клиентом процесса SMTP. Теперь его локальный хост-компьютер осуществляет процесс доставки сообщения и сам выступает в качестве клиента SMTP. Когда локальный хост соединяется с удаленным хостом для передачи сообщения с помощью протокола SMTP, он действует как клиент SMTP-процесса. Команда HELO объявляет в качестве клиента имя локального хоста , а не реального пользователя, отославшего сообщение. Довольно часто эти понятия путают, что усложняет решение проблем, возникающих в системах электронной почты.
Команда MAIL
Команда MAIL используется для организации сеанса обмена электронной почтой с сервером после того, как была послана команда HELO . Она указывает, от кого исходит данное сообщение. Формат команды MAIL следующий:
MAIL reverse-path
Аргумент reverse-path не только определяет отправителя сообщения, но также указывает маршрут, по которому можно вернуть сообщение в случае невозможности его доставки. Если отправитель является пользователем на клиентском компьютере, который инициировал сеанс SMTP, то формат команды будет следующим:
MAIL FROM: [email protected]
Заметьте, что в поле FROM
указывается адрес электронной почты
отправителя сообщения, включая полное имя
клиентского хост-компьютера. Эта
информация должна присутствовать в поле FROM
почтового сообщения (но об этом позже). Если
почтовое сообщение проходило на пути от
отправителя к получателю через несколько
узлов, то каждый из них будет добавлять
сведения о себе в поле