Лабораторная работа 2 (LAB2 Бочаров И.A.)

Посмотреть архив целиком

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

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

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

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





Лабораторная работа №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 для автоматического распознавания типа содержимого тела сообщения

Необязательно



Случайные файлы

Файл
59626.rtf
103967.rtf
178211.rtf
24550-1.rtf
71379-1.rtf




Чтобы не видеть здесь видео-рекламу достаточно стать зарегистрированным пользователем.
Чтобы не видеть никакую рекламу на сайте, нужно стать VIP-пользователем.
Это можно сделать совершенно бесплатно. Читайте подробности тут.