Лекция 7 Протоколы электронной почты SМТР, РОРЗ,IМАР4

Формат почтовых сообщений MIME. Модель работы SMTP. Ретрансляция сообщений. Расширение SMTP-сервиса для передачи 8-битных данных. Взаимодействие SMTP с транспортным протоколом TCP, POP3. Принципы работы. Протокол IMAP4. Принципы работы. Атрибуты сообщений системы (MAP).

В этом разделе мы разберем работу наиболее распространенной части iп1ете1 —электронной почты (е-mail) и наиболее популярных протоколов, которые она использует. Скорость, эффективность и простота использова­ния концепции е-mail, сделали этот сервис наиболее распространенным в 1п1ете1. Е-mail-сообщения могут передаваться и достигать своего места на­значения через весь земной шар за считанные минуты. Пользователи 1п1егnеtласково называют обычную почту "улиткой" из-за ее относительной мед­лительности.

SМТР

Основным протоколом работы с электронной почтой является SМТР (SimpleProtocolMailTransfer, Простой протокол передачи почты). ПротоколSМТР поддерживает передачу сообщений электронной почты между произвольными узлами сетиInternet. Он служит для достоверной и надеж­ной передачи сообщений.между хостами сети 1п1е1пе1. 5МТР —протокол прикладного уровня, поэтому обычно над модулем 8МТР располагается почтовая служба организаций. Существует огромное число коммерческих и свободно распространяемых программных пакетов для работы с е-mail, ис­пользующих 5МТР-сервис. Среди них такие популярные программы, какMicrosoftMail,MicrosoftЕхсhange.

5МТРпредставляет собой независимый от транспортной подсистемы про­токол, для работы которого необходим только транспортный канал передачи потока данных. Собственные механизмы промежуточного хранения почты и механизмы повышения надежности доставки позволяют протоколу 5МТР использовать для работы различные транспортные службы. 5МТРможет ра­ботать по любому транспортному каналу, удовлетворяющему требованиям передачи данных 5МТРчерез различные сети или группы сетей, например, ТСР, Х25 и др.

Протокол 5МТРобеспечивает как передачу сообщений в адрес одного получателя, так и тиражирование нескольких копий сообщения для пере­дачи в разные адреса. Протокол 5МТРможет передавать не только тексто­вые сообщения, но и двоичную информацию, такую как рисунки, испол­няемые файлы и др. Двоичная информация, находящаяся в сообщении, пе­ред отправкой определенным образом форматируется и, как правило, кодируется в 7-битный вид, хотя современные расширения протокола5МТР —Е5МТР позволяют передавать данные в 8-битном виде. Формати­рование и кодирование разнородной пользовательской информации произ­водится программным обеспечением .оболочки электронной почты.

После того как пользователь закончил формирование своего сообщения, т. е. вставил необходимые картинки, присоединил к текстовому сообщению дополнительные файлы или исполняемые программы, сообщение помеща­ется в определенную структуру —конверт сообщения. Конверт для пользо­вательских данных содержит информацию о структуре и составе передавае­мых данных, дату формирования сообщения, имена и адреса отправителя, имена и адреса получателя или группы получателей, темы сообщения и др. По сути, почтовый конверт сообщения можно представлять как протокол более высокого прикладного уровня, который структурирует данные пользо­вательского ввода и представляет их в виде, пригодном для работы протоко­ла передачи сообщений — 5МТР.

Прежде чем переходить к рассмотрению работы протокола передачи поч­ты — 5МТР,необходимо коротко остановиться на описании структур и форматов данных, в которые укладываются разнородные пользовательские данные —текст, изображения, звуки и т. п. при передаче по электронной почте.

7.1 Формат почтовых сообщений, мiме

К сожалению, рамки данной книги не позволяют подробно разобрать все типы почтовых сообщений, разновидности кодировок и представлений дан­ных. Доступное и подробное изложение этой темы может составить несколько объемистых томов. В данном разделе будут кратко изложены наиболее рас­пространенные типы форматов и их взаимодействие между собой.

Любое сообщение состоит из конверта сообщения и тела сообщения. Кон­верт содержит информацию, необходимую для доставки и обработки сооб­щения. Тело сообщения содержит информацию, которую отправитель пере­дает получателю. Иными словами, конверт представляет собой каркас, на который накладываются данные пользователя. Конверт и данные в сообще­нии тесно взаимосвязаны друг с другом, все почтовые системы для построе­ния конверта используют информацию тела сообщения. Структура конверта, как правило, задается локальным почтовым программным обеспечением. Поэтому, прежде чем отправлять данные в определенном конверте, нужно убедиться, что получатель этих данных сумеет извлечь их из конверта.

В простейшем случае конверт сообщения состоит только из заголовка. Заго­ловок отделен от тела сообщения пустой строкой. Заголовок состоит из не­скольких строк, содержащих информацию о сообщении.

Каждая строка заголовка содержит имя поля заголовка и данные поля заго­ловка. Имя поля отделено от данных символом ":".Названия полей должны состоять из символовASCIIот 32до 126.Каждая строка заканчивается <CRLF>. Определенные поля данных должны иметь заданную структуру, например, поля "Date:", "From:" и пр., другие поля могут иметь произволь­ную структуру, например, поля "Subject:", "Comments:" и др.

Рассмотрим состав и структуру основных полей сообщения на следующем простейшем примере:

From: "Somebody M.S." <mike@joke.ru>

To: zol@fun.ru

Date: Wed, 10 Sep 1997 16:17:50 +0300

Subject: Hello Message-ID: <some. 5tring@ joke. ru>

Hello!

How do you do?

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

• Поле "From:" содержит адрес отправителя. Это поле содержит адрес ав­тора сообщения. Как правило, этот идентификатор устанавливается в параметрах настройки программы почтового клиента. Если бы отправи­тель поручил кому-либо другому отправить за него сообщение, напри­мер, своему секретарю, сообщение содержало бы поле "Sender:". В этом поле был бы указан реальный отправитель сообщения, т. е. идентифика­тор пользователя, который вошел в почтовую систему и отправил данное письмо, пользуясь, например, настройками программы клиента автора сообщения. Например, если бы сообщение было отправлено секретаремlisa@joke.ru, оно содержало бы следующее:

From: mikegjoke.ru (mikegjoke.ru)

Sender: lisa@joke.ru

Поле "From:" может содержать несколько адресов отправителей, от име­ни которых было отправлено сообщение, но не должно содержать груп­повой адрес, например:

From: mike@ joke. ru,

vlad@joke, ru

Sender: lisa@joke.ru

• Поле "To:" содержит адрес(а) получателя(ей) —кому предназначено данное сообщение. Любое сообщение должно содержать либо поле "То:", либо поле "Сс:" —содержащее адреса получателей копий данного сооб­щения, например:

То: OdengMad-Host,

lrving@Other-Host

Сс: Simmons@bra.x400.icl.co.uk, Blob@ultra.x400.icl.uk

• Поле "Date:" содержит дату отправки сообщения почтовой системой. Поле даты содержит дату, время и часовую зону. Формат даты также за­висит от почтовой системы.

• Поле "Subject:" содержит тему данного сообщения, заполняется пользо­вателем самостоятельно, в соответствии с содержанием информацион­ной части сообщения.

• Поле "Message-Id:" содержит уникальный идентификатор сообщения. Он используется для ссылок на данное сообщение других сообщений и идентификации частей данного сообщения. Состав идентификатора оп­ределяется типом почтовой системы и, как правило, состоит из строки символов и адреса хоста отправителя.

• В сообщении может быть поле "Reply-To:" —где указан почтовый ящик, куда следует направлять ответы на данное сообщение. Например, если отправитель, имеющий адресmike@joke.ru, захочет, чтобы ответ на его сообщение получил его секретарь, он может указать:

Reply-To: lisa@joke.ru

Ответы на сообщение, в заголовке которого есть поле "Reply-To:", от­правляются по указанному в этом поле адресу. Если этого поля нет, от­веты направляются по адресу, указанному в поле "From:".

Минимальный заголовок сообщения должен содержать поля: "Date:", "From:", "То:" или "Сс:". Все остальные поля не являются обязательными в формате заголовка сообщения и их присутствие и содержимое непосредст­венно зависит от типа используемой почтовой системы.

При передаче сообщения через промежуточные почтовые серверы, к заго­ловку достраиваются записи "Received:", содержащие поля с адресами и временем обработки сообщения промежуточными серверами, например:

Received: from ns. joke, ru (ns,joke.ru [199.86.42.18])

by bulldozer.arcom.spb.su (8.8.5/t/97-Mar-14) with ESMTP id QAA10700 for <zol@joke.ru>; Wed, 10 Sep 1997 16:24:02 +0400 (MSD)

Заголовок также может содержать запись типа и версии программного обес­печения клиента ("X-Mailer:"), комментарии ("Comments:"), приоритетность ("Priority:") и др., например:

Priority: normal

X-mailer: Pegasus Mail v3.22

Очередность полей заголовка определяется почтовой системой, но, как пра­вило, они размещаются следующим образом: "Received:", "Date:", "From:", "Subject:", "Sender:", "Reply-To:", "To:", "Cc:", "Comment:", "X-Mailer:", "Message-ID:" и др.

На начальном этапе развития электронной почты было вполне достаточно передавать между пользователями только текстовые сообщения, которые содержали только символы из набора ASCII. Если пользователю требовалось отправить изображение или исполняемый файл, он кодировал его символа­миASCIIи вставлял в текст сообщения.

С ростом популярности электронной почты и расширением возможностей компьютеров и линий передачи, назрела необходимость передавать по почте тексты, написанные на разных национальных языках, изображения, испол­няемые файлы, видео и другие бинарные данные в унифицированном фор­мате. Старая схема передачи таких данных становилась все более неудобной из-за того, что:

1. Разные клиенты работали с различными типами кодирования, что часто приводило к невозможности прочитать полученные данные адресатом.

2. Не была определена структура размещения и идентификации типа зако­дированных данных. Чтобы понять, что представляет собой полученная информация, ее надо было вынуть из сообщения и раскодировать.

В результате было сильно затруднено, а реально и невозможно, развитие • программных средств просмотра данных сообщения "на лету", т. е. чтобы программное обеспечение клиента могло автоматически распознавать тип данных и представлять их пользователю сразу в момент просмотра сооб­щения.

В общем, все это очень неудобно, особенно, если вам приходится постоянно работать с электронной почтой, например, прочитывать и отвечать на не­сколько десятков электронных писем в день.

Поэтому, для более удобной работы с составными и нестандартными (не ASCII) сообщениями и был разработан стандартMIME(MultipurposeInternetMailExtensions, Многоцелевое расширение электронной почты).

Стандарт MIMEне заменяет, а расширяет существующий до сих пор способ форматирования сообщений.MIMEпредставляет собой новый формат представления данных, который позволяет почтовому клиенту удобный и гибкий интерфейс работы с электронной почтой.MIME —это, образно говоря, новый конверт, в который вы можете положить разнообразный текст, графические изображения, видеофрагменты и отправить адресату, который, в свою очередь, может быстро и без проблем воспользоваться всей получен­ной информацией. Сообщение построено с использованиемMIME, если в его заголовке присутствуют следующие поля:

• Стандарт MIMEидентифицируется в почтовом сообщении полем "Mime-Version:", которое содержит строку версииMIMEрасширения данного сообщения.

Например: "Mime-Version: 1.0".

• Поле "Content-Type:" указывает состав сообщения:

1. "text" —сообщение содержит текстовую информацию в виде после­довательности символов из набора, указанного параметром "charset" (us-ascii,iso-8859-1,koi8-r,windows-1251 и др.). Например: "Content-Type: text/plain; charset="iso-8859-l""

2. "multipart" —означает, что данное сообщение состоит из нескольких отдельных блоков, каждый из которых описывает свой состав само­стоятельно. Данный тип имеет параметр "boundary", который содер­жит строку-разделитель частей сообщения. Например: "Content-Type: multipart/mixed; boundary="this is a separator""

3. "application", "image", "audio", "video" —означают, что сообщение со­держит двоичные данные определенного типа. Например: "Content-Type: application/rnsword; name="file. doc"" или "Content-Type: image/gif; name="pic.gif""

4. "message" —сообщение содержит другое сообщение. Например, строка "Content-Type:message/RFC-822" указывает, что далее следует сообщение, отформатированное в соответствии с пра­вилами, сформулированными в документеRFC-822.

Примечание

RFC-822 —это основополагающий документ форматов почтовых сообщений. Он описывает только самые основы структуры почтовых сообщений без каких-либо расширений. Если указано, что сообщение сформировано на основанииRFC-822, то это значит, что данное сообщение составлено в каноническом виде.

• Поле "Content-Transfer-Encoding:" содержит идентификатор типа коди­ровки, используемой в данном сообщении или его части: "base64", "quoted-printable", "Tbit", "8bit", "binary" или др.

Особенность типов кодировки: "Tbit", "8bit",'binary" состоит в том, что они не подразумевают никакого кодирования. Эти типы только обозна­чают, что данные представлены в определенном виде. "Tbit" —данные содержат только ASCII-символы, "8bit"и 'binary" —указывают на то, что данные содержат не только ASCII-символы.Разница между типами "8bit" и 'binary" состоит в ограничении длины строки данных. У типа "8bit" строка ограничена длиной строки SMTP-протокола — 1000байтна у типа "binary" таких ограничений нет.

Примечание

Кодировка "8blt", как правило, используется для передачи текстовых сообщений на различных национальных языках, а кодировка "binary" —для передачи графики, видео и т. п. Для передачи данных в этих кодировках серверыSMTPдолжны уметь работать с 8-битными данными, т. е. поддерживать расширения протоколаSMTP-ESMTP.

Кодировки "base64" и "quoted-printable" преобразуют последовательность символов данных сообщения из набора 00-FFв последовательность из символовASCII.

Кодировка "quoted-printable", как правило, предназначена для кодирова­ния текстов на различных национальных языках, содержащих символы из второй части таблицы кодировки (7F —FF). Кодировка "Quoted-printable" удобна тем, что символы верхней части таблицы кодировки (00—7F) представляются в своем естественном виде. Это делает латинский текст письма хоть немного более удобным для чтения (чего, к сожалению, не скажешь о кириллице). Описание алгоритма кодирования "quoted-printable" не входит в рамки данной книги, однако, для понимания принципов его работы достаточно знать следующее:

1. Каждый символ сообщения может быть представлен в виде символа "="и двузначного шестнадцатеричного кода символа. Например, символ "1"может быть представлен как'=49',а символ "="как'=61'.

2. Символы, чьи коды от 33до 60и от 62до 126представляются в видеASCII-символов,т. е. символ "1"в кодировке "quoted-printable" будет 'Г.

3. Остальные правила касаются представления знаков переноса строки, пробела и т. п. Все это вы можете найти, например, в RFC-1341.

Кодировка 'base64" используется, как правило, для представления "нечитаемой" части сообщения —изображений, бинарных файлов, видео и др. Алгоритм кодирования, чем-то напоминает процедуру сжатия (или архивации) данных наоборот. Описание алгоритма кодирования "base64" не входит в рамки данной книги, однако, следует отметить, что для по­нимания принципов его работы достаточно знать следующее:

1. Битовый поток разбивается на сегменты по 24бита, которые, в свою очередь, делятся на четыре части по 6бит.

2. Каждая такая часть кодируется одним из 64-х ASCII-символов (отсюда название — base64)в соответствии с таблицей, в которую входят прописные и заглавные буквы английского алфавита, цифры и знаки "+"и"/".

Кодировки "base64","quoted-printable", "Tbit" поддерживаются практически всеми почтовыми серверами.

Рассмотрим теперь возможности и спецификацию MIMEна примере сле­дующей части сообщения:

. . .

Date: 03 Jun 1997 10:28:00 +0300

Mime-Version: 1.0

From: johnUteam. fun. ru (john nuttor)

Subject: Hello!

To: zol@teaml.mcs.tsi.ru (Sergey Zolotov)

Content-Type: multipart/mixed;

Boundary ="Boundary_3393cd7a29_Level0"

--Boundary 3393cd7a29 Level0

Content-Type: text/plain; charset=^"iso-8859-l"

Content-Transfer-Encoding: quoted-printable

=DE”D4=CF-=DO=CF”DO=CI=CC=CF, =C4=CF=D5=DE=C9=D7=CI-D4-=D8,

=C9 -D6=C4-CI=

=D4=D8, =-CB=CF=C7=C4=CI =C5=C7=CF =DO=C5=D2=C5=CD=CI=CE=DI-D4.

--Boundary_3393ed7a29_Level0

Content-Type: application/octet-stream; name =''Register.url"

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename ="Register.url"

WOIudGVybmVOa2hvcnRjdXRdDQpVakw9aHROcDovL3d3dy50ZWxlY29td2ViLmNvbS 9yZWdpc3Rlci5odGONCgOK

--Boundary_3393cd7a29_Level0--

Тип структуры данного сообщения определен как "multipart" с подтипом "mixed". Это означает, что сообщение состоит из нескольких частей разных форматов и на порядок представления частей не накладываются никакие 01раничения. Данный тип сообщения обязан содержать параметр 'boundary", который представляет собой строку, служащую разграничителем частей со­общения. Таким разделителем в данном сообщении является строка"Boundary_3393ed7a29_LevelO".Она делит сообщение на две части:

• Первая часть типа "text/plain" содержит закодированное текстовое сооб­щение в кодировке "charset="iso-8859-l"". Тип кодирования "quoted-printable". Это означает, что после декодирования первой части ее текст будет иметь кодировкуiso-8859-1 и содержать символы вне набораAS­CII, что следует из общего вида закодированной информации. Эта часть представляет собой обычное сообщение, которое мы читаем в окне тек­ста сообщения программы почтового клиента.

• Вторая часть сообщения имеет тип "application/octet-stream" —обозначе­ние типа информации в двоичных кодах, который программа почтового клиента не сумела сопоставить ни с одним из известных ей типов. Тип имеет название: параметр "name", который указывает, что данные со­держатURL(UniformResourseLocator, Универсальный указатель ресур­сов) какого-то объекта. Текст второй части сообщения закодирован в "base64", на что указывает строка "Content-Transfer-Encoding:base64" Эта часть содержит дополнительный параметр "Content-Disposition:", кото­рый определяет тип представления этой части данных. Тип представле­ния данных "attachment" с параметром "filename=Register.url" означает, что вторая часть нашего сообщения будет обозначена программой поч­тового клиента как присоединенный файл с именемRegister.url.

Теперь совсем не сложно представить, каким должно быть сообщение, что­бы оно содержало, например, текст с картинкой.

Первую часть сообщения можно оставить без изменения (разве что только изменить текст):

. . .

Content-Type: multipart/mixed; bound­ary" = "Boundary_example_boundary_picture"

--Boundary_example_boundary picture

Content-Type: text/plain; charset="iso-3859-l"

Content-Transfer-Encoding: quoted-printable

Look

а вторую представить так:

Boundary_exainple_boundary_picture

Content-Type: image/jpg

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename="look.jpg"

<. . . picture . . . >

--Boundary_3393cd7a29_Level0--

где <...picture...> —закодированное при помощи алгоритма base64содержа­ние картинки "look.jpg". Текст сообщения сокращен до одного слова:Look, поскольку в кодировке "quoted-printable" символыASCIIпередаются в своем "естественном" виде. Если вы хотите, чтобы картинка появлялась в самом тексте сообщения, достаточно установить параметр "Content-Disposition:in­line". Это означает, что программа почтового клиента разместит картинку рядом с текстом письма, т. е. пользователю не нужно будет предпринимать какие-либо дополнительные действия для того, чтобы увидеть картинку.

В разобранном выше примере сообщение состоит из двух частей. Однако каждая из описанных частей может быть самостоятельным сообщением и передаваться отдельно. Кроме того, каждая часть сообщения может вклю­чать в себя несколько других частей и т. д., образуя своеобразную иерархию вложенности. Манипулируя параметрами MIME, вы можете составлять практически любые конструкции объектов и передавать их по электронной почте.

Рамки данной книги не позволяют более детально остановиться на обсуж­дении значений MIME-параметрови их комбинаций. Для того чтобы более обстоятельно познакомиться с возможностямиMIMEи форматами писем электронной почты, вам следует изучить соответствующиеRFC, например,RFC-1341,RFC-1342,RFC-1521,RFC-2045,RFC-2046,RFC-2047,RFC-2048,RFC-2049.

Теперь, после знакомства с составом и форматами передаваемых сообще­ний, перейдем к рассмотрению протокола передачи этих сообщений.