Полный курс лекций 2009-го года (1130357), страница 88
Текст из файла (страница 88)
Для создания сообщения может бытьиспользован любой текстовый процессор либо текстовый редактор, встроенный в агент пользователя. Всепараметры должны быть заданы в формате, который понимает и с которым может работать агентпользователя. Большинство агентов пользователя ожидает адрес назначения в формате DNS:mailbox@location.Следует отметить, что существуют и другие форматы, например, X.400.
Этот формат предполагаетдовольно сложное описание адреса назначения. В частности, сообщение с адресом может быть доставлено,даже если адрес назначения выписан не полностью. Однако агенты пользователя, поддерживающие такойформат, стали доступны не скоро, как результат – такой формат адреса не прижился.Агент пользователя также поддерживает лист рассылки.
Этот лист позволяет рассылать одно и то жесообщение сразу нескольким пользователям. Причем сообщение размножается не обязательно самимагентом, а там, где поддерживается лист рассылки.7.4.2.2. Чтение почтыПрежде чем агент пользователя (далее АП) что-либо высветит на экране при загрузке, он просмотритпочтовый ящик на предмет того, что нового туда поступило. Затем он высветит на экране его содержимое скраткой аннотацией каждого сообщения.
В таблице 7-49 показан пример содержимого почтового ящика втом виде, как это предоставляет АП. В простых почтовых АП высвечиваемые поля встроены в АП, вразвитых – пользователь сам определяет, что показывать, а что нет. (Эта информация содержится в файле«user profile».)Таблица 7-49. Пример дисплея с содержимым почтового ящикаПосле того как содержимое ящика показано пользователю, последний может выполнять любую изимеющихся команд. Типичный состав команд показан в таблице 7-50.Таблица 7-50.
Типичный состав команд почтового ящикаКомандаПараметрh№Отобразить заголовки на экранеct№Отобразить только текущий заголовокВывести сообщение на экранsfaddress№a№Ответить на сообщениеdu№№Удалить сообщениеВосстановить ранее удаленное сообщениеm№Переместить сообщение в другой почтовый ящикkr№mailboxnbg№eОписаниеОтправить сообщениеПереслать сообщениеОставить сообщение после выходаПросмотреть другой почтовый ящикПерейти к следующему сообщениюВернуться к предыдущему сообщениюПерейти к конкретному сообщению, но не отображать егоВыйти и обновить почтовый ящик7.4.3. Формат сообщенийРассмотрим формат самого сообщения.
Начнем с формата по RFC 822, а потом перейдем кмультимедийному расширению этого документа.7.4.3.1. RFC 822Сообщение состоит из простейшего конверта (описанного в RFC 821), полей заголовка, пустой строкии тела сообщения. Каждая строка заголовка – это строка ASCII-текста, содержащая название поля,двоеточие и какое-то значение. Стандарт 822 не различал четко заголовок и конверт. В современныхпочтовых системах это различие проведено лучше, и агент пользователя имеет дело с заголовком, а агентпередачи – с конвертом, который он формирует на основе заголовка.Важные поля заголовка перечислены в таблице 7-51.Таблица 7-51.
Поля заголовка RFC 822ЗаголовокЗначениеПоля, относящиеся к транспортировке сообщенияTo:Адрес основного получателяCc:Адрес дополнительного получателяBcc:Адрес для «слепых» копийFrom:Создатель данного сообщенияSender:Адрес отправителяReceived:Строка, добавляемая каждым агентом на пути сообщенияReturn-Path:Может использоваться для определения обратного пути к отправителюНекоторые поля, используемые в заголовке сообщенияDate:Дата и время отправки сообщенияReply-To:Адрес, на который нужно отправлять ответMessage-Id:Уникальный номер сообщения для использования в дальнейшемIn-Reply-To:Идентификатор сообщения, ответом на которое является текущее сообщениеReferences:Другие релевантные идентификаторы сообщенияKeywords:Ключевые слова, выбранные пользователемSubject:Краткий отрывок сообщения для отображения одной строкой7.4.3.2.
MIME – Multipurpose Internet Mail ExtensionКогда Интернет только начинал развиваться, почтовые системы способны были передавать толькотекстовые сообщения на английском языке в формате ASCII. Для этих целей RFC 822 подходило вполне.
Внаши дни такой подход уже не годится. Необходимо, чтобы почтовая система умела работать:1.с сообщениями на европейских языках (французском, немецком и т.д.)2.с сообщениями не в латинском алфавите (русском, арабском и т.д.)3.с сообщениями не в алфавите (японский, китайский)4.с сообщениями, не содержащими текст (звук, видео, графика)Такое решение предложено в RFC 1341 и RFC 1521. Это решение называется MIME – многоцелевоерасширение почтовой службы в Internet. Основная идея MIME – расширение RFC 822 в целях введенияструктуры в тело сообщения и правил кодировки ASCII-сообщений. Естественно, что это повлияло напрограммы доставки и отправки сообщений.MIME определяет пять новых заголовков, показанных в таблице 7-52.
Первый сообщает агентупользователя, что он имеет дело с MIME-сообщением, и то, какая версия MIME используется. Второй итретий характеризуют сообщение. Например, второе поле можно использовать для фильтрации сообщений.Таблица 7-52. Пять заголовков RCF 822, определенных в MIMEЗаголовокЗначениеMIME-Version:Идентифицирует версию MIMEContent-Description:Строка, описывающая содержимое сообщенияContent-Id:Уникальный идентификаторContent-Transfer-Encoding:Способ подготовки тела письма к передачеContent-Type:Тип сообщенияЗаголовок Content_Transfer_Encoding определяет, как сообщение должно быть подготовлено дляпередачи через сеть. Для этого используется пять основных схем.
Простейшая схема – для передачиASCII-текста – 7 бит на символ. Однако для учета национальных алфавитов используется 8 битная схема.Однако ни первая, ни вторая схемы не должны превышать 1000 символов в строке.Сложная ситуация с передачей двоичных данных. Для корректной передачи такого типа данных(исполняемый код программ) используется схема base64 encoding. Эта схема разбивает сообщение наблоки по 24 бита.
Каждый блок разбивается на 4 группы по 6 бит каждая. Для сообщений, которыеявляются «почти» ASCII-сообщениями с небольшими исключениями, используется другая схема – quotedprintable encoding. Можно указать и какую-то особую схему в поле Content-Transfer-Encoding.Последнее поле заголовка указывает тип сообщения.
Возможные значения этого поля указаны втаблице 7-53.Таблица 7-53. Типы и подтипы сообщений MIMEТипTextПодтипОписаниеPlainНеформатированный текстRichtextТекст с простым форматированиемGifИзображение в формате GIFImageJpegИзображение в формате JPEGAudioBasicЗвукVideoMpegФильм в формате MPEGOctet-stream Неинтерпретируемая последовательность байтовApplicationMessageMultipartPostscriptГотовый к печати документ в формате PostScriptRfc822Сообщение MIME RFC 822PartialСообщение перед передачей было разбито на несколько частейExternal-body Непосредственно сообщение следует передать через сетьMixedНезависимые части в определенной последовательностиAlternativeВышеупомянутое сообщение в различных форматахParallelЧасти сообщения необходимо просматривать вместеDigestКаждая часть является самостоятельным сообщением RFC 8227.4.4.
Передача сообщенийОсновная задача системы передачи почтовых сообщений – надежно доставить сообщение ототправителя к получателю. Самый простой способ сделать это – установить транспортное соединение и понему передавать почту.7.4.4.1. SMTP (Simple Mail Transfer Protocol) – Простой протоколпередачи почтыВ Internet почта передается следующим образом. Машина отправитель устанавливает ТСРсоединение с 25-м портом машины получателя. На 25 порту находится почтовый демон, который работаетпо протоколу SMTP. Он принимает соединение и распределяет поступающие сообщения по почтовымящикам машины-получателя.SMTP - это простой ASCII-протокол. После установления соединения машина-отправитель работаеткак клиент, а машина-получатель – как сервер.
Сервер шлет текстовую строку, идентифицирующую его иготовность принимать почту. Если он не готов принимать почту, то клиент разрывает соединение иповторяет всю процедуру позже.Если сервер подтвердил свою готовность, то клиент сообщает, от кого и кому предназначеноочередное сообщение. Если сервер подтвердил наличие получателя, то он дает команду клиенту, исообщение передается без контрольных сумм и подтверждений, так как ТСР-соединение обеспечиваетнадежный поток байтов. Если сообщений несколько, то все они передаются.
Обмен по соединениюпроисходит в обоих направлениях.На рисунке 7-54 показан пример мультимедийного сообщения. Обратите внимание, что заголовокContent type встречается трижды. Первый раз он указывает, что сообщение состоит из альтернативныхмультимедиа-частей. Одна часть, у нее свой заголовок - это текст.
Другая, у нее свой заголовок - аудиочасть.Рисунок 7-54. (а) Сообщение, содержащее сложный текст и его аудио-вариант;(b) Передача этого сообщенияЗамечание. Клиент всегда посылает 4-символьные команды. Команды сервера в основном цифровые.На рисунке 7-54 сообщение передается только одному получателю. Однако их может бытьнесколько, тогда используют несколько RCTP-команд.У SMTP протокола, несмотря на то что он хорошо описан в RFC 821, есть несколько проблем. Первая– длина сообщения не может превосходить 64 Кбайт. Другая – time out. Если время ожиданияподтверждения у отправителя и получателя не согласовано, то один будет разрывать соединение, недождавшись, тогда как другой просто очень загружен. Третья – почтовый ураган.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
