Электронная почта

2.1 Протокол SMTP.

Главной целью  протокола Simple Mail Transfer Protocol (SMTP, RFC-821, -822) является надежная и эффективная  доставка электронных почтовых сообщений. SMTP - это довольно независимая субсистема, требующая только надежного канала связи. Средой для SMTP может служить  отдельная локальная сеть, система  сетей или вся сеть Internet.

Протокол SMTP базируется на следующей модели коммуникаций: в ответ на запрос пользователя почтовая программа-отправитель устанавливает  двухстороннюю связь с программой-приемником (TCP, порт 25). Получателем может быть конечный или промежуточный адресат. SMTP-команды генерируются отправителем и посылаются получателю. Для каждой команды должен быть получен отклик.

Когда канал  организован, отправитель посылает команду MAIL, идентифицируя себя. Если получатель готов к приему сообщения, он посылает положительный отклик. Далее отправитель посылает команду RCPT, идентифицируя получателя почтового  сообщения. Если получатель может принять  сообщение для оконечного адресата, он снова выдает положительный отклик. В противном случае он отвергает  получение сообщения для данного  адресата, но не вообще почтовой посылки. Взаимодействие с почтовым сервером возможно и в диалоговом режиме.

В следующей  таблице приведено несколько  команд, которые используются в SMTP:

Команды SMTP

После ввода  команды Data пользователь вводит текст  сообщения и как знак окончания  ставит точку в пустой строке. Если письмо дошло до адресата, то выходит  соответствующее сообщение. В противном  случае выходит сообщение о том, что ящика адресата не существует, а на адрес отправителя приходит обратное письмо с текстом отправляемого  сообщения.

Прямая доставка позволяет SMTP пересылать почту, не полагаясь  на промежуточные хосты. Недостаток прямой доставки состоит в том, что  на обоих кончах должны непрерывно поддерживать работу с почтой. Это  не касается почтовых Интернет-серверов, поскольку они постоянно включены и настроены на непрерывную отправку-прием сообщений. Для считывания сообщенй с таких серверов на компьютеры пользователей применяется протокол POP.

Но не в каждой сети используется TCP/IP и SMTP. Чтобы предоставить пользователям услуги электронной  почты в таких случаях, применяют  так называемые почтовые шлюзы, которые  дают возможность абоненту отправлять сообщения в сети, не работающие с протоколами TCP/IP (Fido, Goldnet, AT50).

2.2 Протокол POP (Post Office Protocol)

Протокол обмена почтовой информацией POP предназначен для разбора почты из почтовых ящиков пользователей на их рабочие  места при помощи программ-клиентов. Если по протоколу SMTP пользователи отправляют корреспонденцию через Internet, то по протоколу POP пользователи получают корреспонденцию  из своих почтовых ящиков на почтовом сервере.

Пользователи  ПК могут соединится с почтовым сервером через Telnet и читать почту, используя ПК в качестве терминала. Это широко распространенный способ, особенно для систем с DOS.

Широкое распространение  получили две версии POP – POP2 и POP3. Протокол POP2 определен в стандарте RFC 937 и  использует порт 109. POP3 определен в RFC 1725 и использует порт 110. Это несовместимые  протоколы, в которых применяются  разные команды, но они выполняют  одинаковые функции.

В настоящее  время чаще всего используется протокол POP3.

В следующих  таблицах сведены сведения о командах применяющихся в протоколах POP2 и POP3:

Команды POP2

Команды POP3

РОРЗ-сервис, как  правило, устанавливается на 110-й  ТСР-порт сервера, который будет  находится в режиме ожидания входящего соединения. Когда клиент хочет воспользоваться РОРЗ-сервисом, он просто устанавливает TCP-соединение с портом 110 этого хоста. После установления соединения сервис РОРЗ отправляет подсоединившемуся клиенту приветственное сообщение. После этого клиент и сервер начинают обмен командами и данными. По окончании обмена РОРЗ-канал закрывается.

Ответы РОРЗ-сервера  на команды состоят из строки статус- индикатора, ключевого слова, строки дополнительной информации и символов завершения строки - . Длина строки ответа может достигать 512 символов. Строка статус -индикатора принимает два значения: положительное ("+ОК") и отрицательное ("-ERR"). Любой сервер РОРЗ обязан отправлять строки статус-индикатора в верхнем регистре, тогда как другие команды и данные могут приниматься или отправляться как в нижнем, так и в верхнем регистрах.

Ответы РОРЗ-сервера  на отдельные команды могут составлять несколько строк. В этом случае строки разделены символами . Последнюю строку информационной группы завершает строка, состоящая из символа "." (код - 046) и , т. е. последовательность "CRLF.CRLF".

РОРЗ-сессия состоит  из нескольких частей. Как только открывается TCP-соединение и РОРЗ-сервер отправляет приветствие, сессия должна быть зарегистрирована – состояние аутентификации (AUTHORIZATION state). Клиент должен зарегистрироваться в РОРЗ-сервере, т. е. ввести свой идентификатор  и пароль.

После этого  сервер предоставляет клиенту его  почтовый ящик и открывает для  данного клиента транзакцию - состояние  начала транзакции обмена (TRANSACTION state). На этой стадии клиент может считать  и удалить почту своего почтового  ящика.

После того как  клиент заканчивает работу (передает команду QUIT), сессия переходит в состояние UPDATE - завершение транзакции. В этом состоянии РОРЗ-сервер закрывает  транзакцию данного клиента (на языке  баз данных - операция COMMIT) и закрывает TCP-соединение.

В случае получения  неизвестной, неиспользуемой или неправильной команды, РОРЗ-сервер должен ответить отрицательным состоянием индикатора.

РОРЗ-сервер может  использовать в своей работе таймер контроля времени соединения. Этот таймер отсчитывает время "бездействия" ("idle") клиента в сессии от последней  переданной команды. Если время сессии истекло, сервер закрывает TCP-соединение, не переходя в состояние UPDATE (иными  словами, откатывает транзакцию или  на языке баз данных - выполняет ROLLBACK).

2.3 Формат  почтового сообщения

Формат почтового  сообщения Internet определен в документе RFC-822 (Standard for ARPA Internet Text Message). Это довольно большой документ объемом в 47 страниц  машинописного текста, поэтому рассмотрим формат сообщения на примерах. Почтовое сообщение состоит из трех частей: конверта, заголовка и тела сообщения. Пользователь видит только заголовок  и тело сообщения. Конверт используется только программами доставки. Заголовок  всегда находится перед телом  сообщения и отделен от него пустой строкой. RFC-822 регламентирует содержание заголовка сообщения. Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ":". Минимально необходимыми являются поля Date, From и To, например: 

 Date:    Wed May 10 18:31:21 2000 

From:   postcards@postcards.mail.ru  

 To:       hetene@mail.ru

Поле Date определяет дату отправки сообщения, поле From - отправителя, а поле  To – получателя(ей). Если письмо отослано по списку рассылки, то в поле To будет указан адрес почтового ящика, на который посылается текст письма для рассылки. К примеру, для рассылки анекдотов от сайта www.anekdot.ru таким ящиком является anekdot-daily@lists.cityline.ru  Письма по спискам рассылки идут довольно долго и могут запоздать на сутки и более. Бывает, что при ежедневной рассылке почты письмо за текущий день не приходит, а приходит оно после письма за следующий день. То есть, если письмо должно прийти 9-го числа, то может случиться, что оно придет 10-го, 11-го числа или еще позже. Это обусловлено самой системой рассылки. Письмо может проходить через большое количество серверов и вследствие этого может опоздать. Также на это влияет и загруженность почтового сервера. 

Чаще заголовок  содержит дополнительные поля:   

 Date:    Tue May 9 12:21:18 2000  

From:   ykovrizhnykh@online.kz   

Sender: admin@online.kz             

To: hetene@mail.ru  

Message-ID: <4231.629.XYzi-admin@online.kz>

В данном случае поле Sender указывает, что владелец ящика ykovrizhnykh@online.kz не является автором сообщения. Он только переслал сообщение, которое  получил от admin@online.kz. Поле Message-ID содержит уникальный идентификатор сообщения  и используется программами доставки почты. Следующее сообщение демонстрирует  все возможные поля заголовка:   

Date:                 16 Mon Feb 2000 16:53:33   

 From:                Ken Davis   

Subject:                          Re: The Syntax in the RFC  

Sender:              KSecy@Other-host  

Reply-To:          Sam.Irving@Reg.Organization   

To:                    hetene@mail.ru  

cc:                     Important folks  

Comment:         New company launced.   

In-Reply-To:     , George`s message   

Message-ID:      <4331.629.XYzi-What@Other-Host

Поле Subject определяет ему сообщения, Reply-To - пользователя, которому отвечают, Comment - комментарий, In-Reply-To - показывает, что сообщение  относится к типу "В ответ  на Ваше сообщение, отвечающее на сообщение, отвечающее ...". 

Следует сказать, что формат сообщения постоянно  дополняется и совершенствуется. В RFC-1327 введены дополнительные поля для совместимости с почтой протокола X.400. Кроме этого, следует обратить внимание на поля некоторых довольно часто встречающихся заголовков, которые не регламентированы в RFC-822. Так первое предложение заголовка, которое начинается со слова From, может  содержать UUCP-путь сообщения, по которому можно определить, через какие  машины сообщение "пробиралось". Поле Received: содержит транзитные адреса почтовых серверов с датой и временем прохождения сообщения. Вся эта  информация полезна при разборе  трудностей с доставкой почты.

2.4 Структура  электронного адреса

2.4.1 Адреса  электронной почты   

 Рассмотрим  адрес hetene@mail.ru

Он состоит  из адреса машины и имени адресата, которое отделено знаком "@".  Слева от @ стоит имя адресата,  точнее,  имя  файла-почтового ящика на сервере,  с которого он забирает письма.