LAB2 Бочаров И.A. (544695)
Текст из файла
Национальный исследовательский институт
Московский Энергетический Институт (Технический Университет)
Институт автоматики и вычислительной техники
Кафедра Прикладной математики
Лабораторная работа №2
по дисциплине:
ВМСС
тема: «Работа с электронной почтой»
Выполнил:
Бочаров Иван Андреевич
Проверил:
к.т.н., доц. Куриленко Иван Евгеньевич
Москва
2012 г.
Подготовка к выполнению работы
Модель работы с электронной почтой
На сегодняшний день общепринятым стандартным протоколом по обмену почтой является протокол SMTP(Simple Mail Transfer Protocol). Рассмотрим общий принцип работы электронной почты при обмене сообщениями по этому протоколу:
Все программы делятся на три больших класса:
-
MUA (Mail User Agent – клиент электронной почты)
-
MTA (Mail Transfer Agent – агент пересылки почты)
-
MDA (Mail Delivery Agent – агент доставки почты)
Агент пересылки почты (MTA) – программа, которая передает сообщения от одного компьютера к другому. Обычно работа почтового сервера незаметна рядовому пользователю, сервер работает как бы «за кулисами». Часто программы соединяют в себе функции агентов пересылки и доставки сообщений, однако есть и специализированные программы, работающие только с пересылкой сообщений.
Агент доставки почты (MDA) – программа, принимающая входящие электронные письма и доставляющая их на почтовый ящик получателя (если он расположен на том же компьютере) или перенаправляющая их на другой почтовый сервер. Как уже было отмечено, MDA не всегда занимается пересылкой сообщений, зачастую на отдельные MDA-программы возлагаются обязанности по фильтрации спама и т.п.
Пользовательский почтовый агент (MUA) – это программа, которую многие из нас привыкли видеть при работе с электронной почтой. Иногда такие программы называют почтовыми редакторами. В отличие от MTA клиент электронной почты обычно отправляет сообщение не прямо на сервер получателя, а на промежуточный сервер (называемый релеем). В качестве подобного сервера обычно выступает почтовый сервер компании или провайдера. Не всегда MUA выступает в виде отдельного приложения. Так, многие почтовые сервисы предоставляют веб-интерфейс для доступа пользователей к почтовым ящикам. В случае веб-интерфейса MUA и MDA программы объединяются. Обычно отправка почты осуществляется при помощи протокола SMTP, а прием сообщений ведется с того же сервера при помощи протоколов POP3 и IMAP.
Взаимоотношения между этими агентами можно проиллюстрировать следующим рисунком:
Формат электронного письма
С накоплением опыта работы с электронной почтой администрацией сети ARPANET было решено оформить предложения по работе с почтой в виде документов. Это решение вылилось в документы RFC821 (этот документ описывал протокол передачи) и RFC822 (в нем находилось описание формата сообщений). Впоследствии эти документы подверглись незначительной переработке, вылившись в документы RFC2821 и RFC 2822. Тем не менее, многие до сих пор, говоря об электронной почте, ссылаются на документ 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
To: John Doe
Reply-To: "Mary Smith: Personal Account"
Subject: Re: Saying Hello
Характеристики
Тип файла документ
Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.
Будьте внимательны на мобильных устройствах, так как там используются упрощённый функционал даже в официальном приложении от Microsoft, поэтому для просмотра скачивайте PDF-версию. А если нужно редактировать файл, то используйте оригинальный файл.
Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.