Национальный исследовательский институт

Московский Энергетический Институт (Технический Университет)

Институт автоматики и вычислительной техники

Кафедра Прикладной математики

Лабораторная работа №2

по дисциплине:

ВМСС

тема: «Работа с электронной почтой»

Выполнил:

Бочаров Иван Андреевич

Проверил:

к.т.н., доц. Куриленко Иван Евгеньевич

Москва

2012 г.

Подготовка к выполнению работы

Модель работы с электронной почтой

На сегодняшний день общепринятым стандартным протоколом по обмену почтой является протокол SMTP(SimpleMailTransferProtocol). Рассмотрим общий принцип работы электронной почты при обмене сообщениями по этому протоколу:

Все программы делятся на три больших класса:

• MUA(MailUserAgent– клиент электронной почты)

• MTA (Mail Transfer Agent – агент пересылки почты)

• MDA (Mail Delivery Agent – агент доставки почты)

Агент пересылки почты (MTA) – программа, которая передает сообщения от одного компьютера к другому. Обычно работа почтового сервера незаметна рядовому пользователю, сервер работает как бы «за кулисами». Часто программы соединяют в себе функции агентов пересылки и доставки сообщений, однако есть и специализированные программы, работающие только с пересылкой сообщений.

Агент доставки почты (MDA) – программа, принимающая входящие электронные письма и доставляющая их на почтовый ящик получателя (если он расположен на том же компьютере) или перенаправляющая их на другой почтовый сервер. Как уже было отмечено,MDAне всегда занимается пересылкой сообщений, зачастую на отдельныеMDA-программы возлагаются обязанности по фильтрации спама и т.п.

Пользовательский почтовый агент (MUA) – это программа, которую многие из нас привыкли видеть при работе с электронной почтой. Иногда такие программы называют почтовыми редакторами. В отличие отMTAклиент электронной почты обычно отправляет сообщение не прямо на сервер получателя, а на промежуточный сервер (называемый релеем). В качестве подобного сервера обычно выступает почтовый сервер компании или провайдера. Не всегдаMUAвыступает в виде отдельного приложения. Так, многие почтовые сервисы предоставляют веб-интерфейс для доступа пользователей к почтовым ящикам. В случае веб-интерфейсаMUAиMDAпрограммы объединяются. Обычно отправка почты осуществляется при помощи протоколаSMTP, а прием сообщений ведется с того же сервера при помощи протоколовPOP3 иIMAP.

Взаимоотношения между этими агентами можно проиллюстрировать следующим рисунком:

Формат электронного письма

С накоплением опыта работы с электронной почтой администрацией сети ARPANETбыло решено оформить предложения по работе с почтой в виде документов. Это решение вылилось в документыRFC821 (этот документ описывал протокол передачи) иRFC822 (в нем находилось описание формата сообщений). Впоследствии эти документы подверглись незначительной переработке, вылившись в документыRFC2821 иRFC2822. Тем не менее, многие до сих пор, говоря об электронной почте, ссылаются на документRFC822.

Интересным является тот факт, что эти стандарты были разработаны студентами и аспирантами, а стандарт X.400, предложенный комитетом по телефонии и телеграфу, достаточно быстро изжил себя.

Как уже было сказано, документом, регламентирующим формат электронных писем, является RFC2822.

Согласно этому документу сообщение делится на строки и состоит из секции заголовков и тела сообщения (возможно пустого). Формат тела сообщения не определяется, лишь говорится, что оно состоит из строк ASCII, точнее ANSI X3.4 (7-битные символы!), отделенных от секции заголовков пустой строкой (CRLF), которая должна присутствовать даже для пустого тела (чтобы отличить его от ошибочного сообщения с порезанным заголовком). Следует заметить, что хотя формат тела не определен, но передавать двоичные данные все же не следует, так как предполагается, что оно делится на строки, а символы конца строки могут модифицироваться при передаче в подсеть или при хранении. Существуют также правила "хорошего тона": при цитировании предыдущего письма, цитируемый текст предваряется знаком ">" (без пробела!); перед подписью вставляется строка "-- " (обратите внимание на пробел перед концом строки!). Длина строки должна быть не более 998 символов, но желательно не порождать строк длиной более 78 символов (не считая CRLF).

Приведем таблицу полей заголовка, в которой опишем их значение и особенности работы с ними:

Название поля	Значение	Обязательное	Примечания
Date	Время, когда автор сообщения заявил, что оно готово к отправке	Обязательное поле	MUAможет отложить отправку до следующего соединения с Интернет (дата останется прежней)
From	Отправитель сообщения (человек или процесс); указывается адрес почтового ящика или список адресов	Обязательно хотя бы одно из полей From,Sender,Reply-To	Если отсутствует Sender, то в полеFromдолжен быть один адрес. Если полеSenderприсутствует в заголовке, то в поле может быть несколько адресов через запятую (автор указан в полеSender)
Sender	Определяет отправителя письма; указывается адрес почтового ящика	Обязательно хотя бы одно из полей From,Sender,Reply-To	Обязательно, если в поле From указано несколько адресов. Сообщения об ошибках доставки почты посылаются ему (но не ответы на сообщения!)
Reply-To	Может содержать список адресов или групп адресов для ответа через запятую	Обязательно хотя бы одно из полей From,Sender,Reply-To	Если присутствует, то ответ на сообщение не должен посылаться по адресу, указанному в поле From или Sender.
To	Адреса основных получателей сообщения или группы адресов через запятую	Должен быть хотя бы один адрес в поле To, Cc или поле Bcc, даже пустое
Cc	Адреса дополнительных получателей сообщения или группы адресов через запятую	Должен быть хотя бы один адрес в поле To, Cc или поле Bcc, даже пустое	Используется, если в тексте письма к ним не обращаются напрямую
Bcc	Адреса третьей группы получателей или группы адресов через запятую	Должен быть хотя бы один адрес в поле To, Cc или поле Bcc, даже пустое	Список может быть пустым. Данные адреса не включаются в копии сообщений, отправляемых первым двум группам. Либо поле Bcc изымается из письма вовсе, либо удаляется тело поля, либо оно изымается из тех копий письма, которые отсылаются первым двум группам, при этом каждый получатель из списка Bcc получает свою копию, из которой удалены все остальные адреса
Message-ID	Уникальный идентификатор этой версии этого сообщения	Нет, но крайне желательно	Уникальность гарантируется генерирующим хостом. Заключается в угловые скобки и состоит из части, однозначно идентифицирующей хост (доменное имя или явный адрес в квадратных скобках), и части, однозначно идентифицирующей сообщение внутри хоста, разделенных знаком "@"
In-Reply-To	Уникальный идентификатор сообщения (сообщений) через пробел или фраза (фразы), на которые дается ответ в данном сообщении.	Необязательно	Фразы удалены из RFC 2822
References	Уникальный идентификатор сообщения (сообщений) через пробел или фраза (фразы), на которые ссылается данное сообщение (содержимое полей Message-ID, In-Reply-To и References исходного сообшения)	Необязательно	Фразы удалены из RFC 2822
Keywords	Ключевые слова или фразы в кавычках, разделенные запятыми.	Необязательно
Subject	Тема сообщения. Неструктурированный текст. Ответное сообщение обычно имеет ту же тему, перед которой стоит строка "Re: "	Необязательно
Comments	Неструктурированный текст	Необязательно
Return-Path	Представляет собой адрес почтового ящика в угловых скобках, перед которым может быть записана цепочка имен хостов, предваряемых знаком "@" и двоеточие. Адрес может быть пустым (<>), используется для предотвращения зацикливания сообщений об ошибках	Необязательное поле, но если есть, то также должно быть хотя бы одно поле Received	RFC 2822 оставляет определение синтаксиса и семантики данного поля за стандартом SMTP (RFC 2821) Согласно RFC 822 поле добавляется последней транспортной системой (MTA), которая отправляет сообщение получателю, и содержит информацию достаточную этому MTA для определения обратного маршрута (совершенно необходимо для протоколов типа UUCP).
Received	Добавляется каждым MTA по пути следования сообщения.	Необязательно	RFC 2822 оставляет определение синтаксиса и семантики данного поля за стандартом SMTP (RFC 2821). Согласно RFC 822 тело поля содержит информацию, приведенную ниже
Encrypted	Первое слово определяет программу шифрования, второе - индекс в таблице ключей	Необязательно	Удален в RFC 2822
Content-Type	Введено RFC 1049 для автоматического распознавания типа содержимого тела сообщения	Необязательно
Encoding-Type	Введено RFC 1505 для автоматического распознавания типа содержимого тела сообщения	Необязательно

Информация, которая может содержаться в поле Received(обязательно толькоwith):

• from домен(от какого хоста получено данным MTA, полное каноническое имя; записывается имя, сообщенное отправившим MTA и затем (в скобках) его реальный IP-адрес и имя; при несовпадении прямой и обратной проверки DNS записывается предупреждение)

• by домен(на каком хосте работает данный MTA, полное каноническое имя; здесь же обычно записывается название MTA и номер версии)

• via атом(физическая сеть: Internet, JANET, хотя встречаются и слова типаHTTP)

• with атом(почтовый протокол - SMTP, ESMTP)

• id идентификатор-сообщения(внутренний идентификатор принимающего MTA, если он хранит сообщение в очереди)

• for адрес(если принимающий MTA преобразует адрес получателя, то здесь сохраняется исходная форма)

• время-получения(формат такой же, как у поляDate)

Формат даты унаследован с 1970-х годов и выглядит так: Tue, 5 Feb 02 00:59:59 +0300. День недели с запятой и секунды с двоеточием можно опускать. Последнее слово определяет смещение локальной временной зоны относительно UTC в часах и минутах. Иногда используются сокращенные наименования временных зон вместо смещения, но это не рекомендуется (а в RFC 2822 явно запрещается). Для временной зоны UTC должно указываться смещение +0000. Смещение -0000 обозначает отсутствие информации о временной зоне.

Часть синтаксиса описывается в RFC 2822 как "устаревший" (определенный в RFC 822 или исторически сложившийся). Сообщения с устаревшим синтаксисом не должны создаваться, но должны обрабатываться, если уж встретились.

Пример сообщения:

----

From: Mary Smith <mary@example.net>

To: John Doe <jdoe@machine.example>

Reply-To: "Mary Smith: Personal Account" <smith@home.example>

Subject: Re: Saying Hello

Date: Fri, 21 Nov 1997 10:01:10 -0600

Message-ID: <3456@example.net>

In-Reply-To: <1234@local.machine.example>

References: <1234@local.machine.example>

This is a reply to your hello.

----

На заре существования сети ARPANET электронная почта состояла исключительно из текстовых сообщений, написанных на английском языке и представленных символами ASCII. Для подобного применения стандарта RFC 822 было вполне достаточно: он определял формат заголовков, но оставлял содержимое сообщения полностью на усмотрение пользователей. На сегодняшний день такой подход уже не удовлетворяет пользователей, привыкших к Интернету. Требовалось обеспечить возможность оправления сообщений со следующими характеристиками:

• Сообщения на языках с надстрочными знаками (например, на французском, немецком, испанском и т. д.).

• Сообщения на языках, использующих алфавиты, отличные от латинского (например, на иврите или русском).

• Сообщения на языках без алфавитов (например, китайском, японском, корейском).

• Сообщения, вообще не являющиеся текстом (например, аудио или видео).

Решение было предложено в документе RFC 1341, а более новая редакция была опубликована в RFC 2045-2049. Это решение, получившее название MIME (MultipurposeInternetMailExtensions, — многоцелевые расширения электронной почты в Интернете), широко применяется в настоящий момент.

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

Заголовок	Описание
MIME-Version:	Указывает версию стандартов MIME
Content-Description:	Описание содержимого. Строка обычного текста, информирующая о содержимом сообщения
Content-Id:	Уникальный идентификатор
Content-Transfer-Encoding:	Указывает способ кодировки тела сообщения для его передачи
Content-Type:	Тип и формат содержимого сообщения

Типы и подтипы MIME:

Тип	Подтипы	Описание
Text	Plain Enriched	Неформатированный текст Текст с включением простых команд форматирования
Image	Gif Jpeg	Неподвижное изображение в формате GIF Неподвижное изображение в формате JPEG
Audio	Basic	Слышимый звук
Video	Mpeg	Видео в формате MPEG
Application	Octet-stream Postscript	Неинтерпретируемая последовательность байтов Документ для печати в формате PostScript
Message	Rfc822 Partial External-body	Сообщение MIME RFC 822 Сообщение разбито на части для передачи Само сообщение должно быть получено по сети
Multipart	Mixed Alternative Parallel Digest	Независимые части в указанном порядке То же сообщение в другом формате Части сообщения следует просматривать одновременно Каждая часть является законченным сообщением стандарта RFC 822

Примеры MIME-сообщений:

From: Nathaniel Borenstein 

To: Ned Freed 

Subject: Sample message

MIME-Version: 1.0

Content-type: multipart/mixed;             

              boundary="simple boundary"

This is the preamble.  It is to be ignored, though it is

a handy place for mail composers to include an

explanatory note to non-MIME compliant readers.

--simple boundary

This is implicitly typed plain ASCII text.

--simple boundary

Content-type: text/plain; charset=us-ascii

This is explicitly typed plain ASCII text. It DOES end

with a line break.

--simple boundary--

This is the epilogue.  It is also to be ignored.

From: elinor@abc.coni

То: carolyn@xyz.com

MIME-Version: 1.0

Message-Id: <0704760941.AA00747@abc.com>

Content-Type: multipart/alternative: boundary=qwertyuiopasdfghjklzxcvbnm

Subject: Земля обошла вокруг Солнца целое число раз

Это преамбула. Пользовательский агент игнорирует ее.

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

--qwertyuiopasdfghjklzxcvbnm

Content-Type: text/enriched

Happy birthday to you

Happy birthday to you

Happy birthday dear <bold> Carolyn </bold>

Happy birthday to you

--qwertyuiopasdfghjklzxcvbnm ,

Content-Type: message/external-body:

access-type="anon-ftp":

site="bicycle.abc.com":

directory="pub";

name="birthday.snd"

content-type: audio/basic

content-transfer-encoding: base64

--qwertyuiopasdfghjklzxcvbnm--