Система электронной почты позволяет доставить сообщение на любой компьютер, включенный в
сеть Интернет. Сообщение может содержать текст или файл практически любого
формата - графику, музыку и т. д. Все пользователи электронной почты имеют
уникальные адреса. Адрес пользователя зарегистрирован в определенном домене
Интернета. С каждым доменом связан почтовый сервер, управляющий адресами
пользователей. Пользователь набирает текст письма в специальной программе,
которая называется почтовым клиентом. Эта программа, в зависимости от
возможностей, позволяет создавать и редактировать новые письма, обрабатывать
пришедшие, хранить и систематизировать переписку и т. д. Почтовый клиент
помещает письмо в "почтовый ящик" пользователя, расположенный на почтовом
сервере. Сервер, в свою очередь, передает письмо на почтовый сервер
адресата.
11.3.1. Адрес электронной
почты В Интернете принята система адресов, которая базируется на
доменном адресе машины, подключенной к сети. Адрес пользователя состоит из двух
частей, разделенных символом "@": Например: Jones@Registry.org В данном
случае Jones - это имя пользователя. A Registry, org - адрес, доменное имя
почтового сервера.
11 .3.2. Формат сообщения электронной
почты Почтовое сообщение состоит из трех частей: конверта,
заголовка и тела сообщения. Пользователь видит только заголовок и тело
сообщения. Конверт используется только программами доставки. Заголовок всегда
находится перед телом сообщения и отделен от него пустой строкой. RFC-822
регламентирует содержание заголовка сообщения. Заголовок состоит из полей. Поля
состоят из имени поля и содержания поля. Имя поля отделено от содержания
символом ":". Минимально необходимыми являются поля Date, From, cc или То,
например: Date: 26 Aug 76 1429 EOT From:
Jones@Registry.org или Date: 26 Aug 76 1429 EOT From:
Jones@Registry.org To: Smith@Registry.org Поле Date определяет дату
отправки сообщения, поле From - отправителя, а поля ее и То - получателя или
нескольких получателей. Чаще заголовок содержит дополнительные поля: Date: 26
Aug 76 1429 EOT From: George Jones Sender: Secy@SHOST To:
Smith@Registry.org Message -ID: <4231.629.XYzi -
What@Registry.org> В данном случае поле Sender указывает, что George Jones
не является автором сообщения. Он только переслал сообщение, которое получил из
Secy@SHOST. Поле Message - ID содержит уникальный идентификатор сообщения и
используется программами доставки почты. Следующее сообщение демонстрирует все
возможные поля заголовка: Date: 27 Aug 76 0932 From: Ken Davis Subject:
Re: The Syntax in the RFC Sender: KSecy@Other - host Reply to: Sam.
Irving@Reg.Organization To: George Jones cc:Important folks: Tom Softwood
, "Sam Irving"@0ther - Host; Standard Distribution:
/main/davis/people/standard@0ther - Host Comment: Sam is away on
bisiness. In reply to: George's message X special action: This is a sample
of user - defined field - names. Message - ID: <4331.629.XYzi -
What@0ther - Host Поле Subject определяет тему сообщения, Reply to -
пользователя, которому отвечают, Comment - комментарий, In reply to -
показывает, что сообщение относится к типу "В ответ на Ваше сообщение,
отвечающее на сообщение, отвечающее ..", X special action - поле, определенное
пользователем, которое не определено в стандарте. Следует сказать, что формат
сообщения постоянно дополняется и совершенствуется. Так в RFC-1327 введены
дополнительные поля для совместимости с почтой Х.400. Кроме того, следует
обратить внимание на поля некоторых, довольно часто встречающихся заголовков,
которые не регламентированы в RFC-822. Так, первое предложение заголовка,
которое начинается со слова "From", содержит UUCP - путь сообщения, по которому
можно определить, через какие машины сообщение "пробиралось". Поле Received:
содержит транзитные адреса почтовых серверов с датой и временем прохождения
сообщения. Вся эта информация полезна при разборе трудностей с доставкой
почты. Возможности электронной почты не ограничиваются только пересылкой
корреспонденции. По почте можно получить доступ ко многим ресурсам Интернета,
которые используют почтовых роботов, отвечающих на запросы пользователей.
Поэтому имеет смысл более детально изучить программное обеспечение,
поддерживающее электронную почту. Стандарт MIME (или, в нотации Интернета,
RFC-1341) предназначен для описания тела почтового сообщения Интернета.
Предшественником MIME является Стандарт почтового сообщения ARPA (RFC-822).
Стандарт RFC-822 был разработан для обмена текстовыми сообщениями. С момента
опубликования стандарта возможности аппаратных средств и телекоммуникаций ушли
далеко вперед и стало ясно, что многие типы информации, которые широко
используются в сети, невозможно передать по почте без специальных
преобразований. Так, в тело сообщения нельзя включить графику, аудио, видео и
другие типы информации. RFC-822 не дает возможностей для передачи даже текстовой
информации, которую нельзя реализовать 7-битовой кодировкой ASCII. Естественно,
что при использовании RFC-822 не может быть и речи о передаче размеченного
текста для отображения его различными стилями. Ограничения RFC-822 становятся
еще более очевидными, когда речь заходит об обмене сообщениями в разных почтовых
системах. Например, для приема/передачи сообщений из/в Х.400 (новый стандарт
ISO), который позволяет иметь двоичные данные в теле сообщения, ограничения
старого стандарта могут стать фатальными, так как в этом случае не спасает
старый испытанный способ кодировки информации процедурой uuencode, так как эти
данные могут быть интерпретированы различным образом в Х.400 и в программе
рассылки почты в Интернете (mail-agent). В некотором смысле стандарт MIME
ортогонален стандарту RFC-822. Если последний подробно описывает в заголовке
почтового сообщения текстовое тело письма и механизм его рассылки, то MIME
ориентирован главным образом на описание в заголовке письма структуры тела
почтового сообщения и возможности составления письма из информационных единиц
различных типов. В стандарте зарезервировано несколько способов представления
разнородной информации. Для этого используются специальные поля заголовка
почтового сообщения: поле версии MIME, которое используется для идентификации
сообщения, подготовленного в новом стандарте; поле описания типа информации в
теле сообщения, которое позволяет обеспечить правильную интерпретацию
данных; поле типа кодировки информации в теле сообщения, указывающее на тип
процедуры декодирования; два дополнительных поля, зарезервированных для более
детального описания тела сообщения. Стандарт MIME разработан как расширяемая
спецификация, в которой подразумевается, что число типов данных будет расти по
мере развития форм представления данных. При этом следует учитывать, что анархия
типов (безграничное их увеличение) тоже недопустима. Каждый новый тип в
обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned
Numbers Authority). Остановимся подробнее на форме и назначении полей,
определяемых стандартом. Поле версии MIME (MIME - Version) указывается в
заголовке почтового сообщения и позволяет программе рассылки почты определить,
что сообщение подготовлено в стандарте MIME. Формат поля выглядит так: MIME -
Version: 1.0 Поле версии указывается в общем заголовке почтового сообщения и
относится ко всему сообщению целиком. Здесь уместно отметить, что в отличие от
стандарта RFC-822 стандарт MIME позволяет перемешивать поля заголовка сообщения
с телом сообщения. Поэтому все поля делятся на два класса: общие поля заголовка,
которые записываются в начале почтового сообщения, и частные поля заголовка,
которые относятся только к отдельным частям составного сообщения и записываются
перед ними. Поле типа содержания тела почтового сообщения (Content type)
используется для описания типа данных, которые содержатся в теле почтового
сообщения. Это поле сообщает программе чтения почты, какого сорта преобразования
необходимы для того, чтобы сообщение правильно проинтерпретировать. Эта же
информация используется и программой рассылки при кодировании/декодировании
почты. Стандарт MIME определяет семь типов данных, которые можно передавать в
теле письма: текст (text); смешанный тип (multipart); почтовое
сообщение (message); графический образ (image); аудиоинформация (audio);
фильм или видео (video); приложение (application). Остановимся
подробнее на каждом из типов, разрешенных стандартом MIME. Text. Этот тип
указывает на то, что в теле сообщения содержится текст. Основным подтипом типа
text является plain, что соответствует так называемому планарному тексту.
Понятие планарного текста появилось в связи с тем, что существует еще
размеченный текст, то есть текст со встроенными в него символами управления
отображением, и гипертекст, то есть текст, который можно просматривать не
последовательно, а произвольно, следуя гипертекстовым ссылкам. Для обозначения
размеченного текста используют подтип richtext, а для обозначения гипертекста -
подтип html. Вообще говоря, это специальный вид размеченного текста, который
используется для представления гипертекстовой информации в системе World Wide
Web, которая получила широкое распространение в Интернете. Понятие размеченного
текста требует более подробного обсуждения, так как его передача и интерпретация
являются одной из причин появления стандарта MIME. Richtext определяет текст со
встроенными в него специальными управляющими последовательностями, называемыми
тегами, в соответствии со стандартом языка разметки документов SGML (Standard
Generalized Markup Language). Теги представляют собой последовательность
символов типа <строка символов>. Разметка гипертекста строится по тому
же принципу, что и в тексте типа richtext. При этом могут применяться теги,
позволяющие описать гипертекстовые ссылки. К таким тегам относятся <А
HREF="......">.....</А>. Multipart. Этот тип почтового сообщения
определяет смешанный документ, который может состоять из данных разного типа.
Тип multipart имеет ряд подтипов. Подтип mixed может создавать сообщения,
состоящие из нескольких фрагментов, которые разделены между собой границей,
задаваемой в качестве параметра подтипа. Другим подтипом может быть подтип
alternative. Данный подтип позволяет организовать просмотр почтового сообщения с
возможностью выбора в зависимости от типа программы просмотра. Подтип digest
предназначен для многоцелевого почтового сообщения, когда различным частям хотят
приписать более детальную информацию, чем просто тип. Подтип parallel
предназначен для составления такого почтового сообщения, части которого должны
отображаться одновременно, что предполагает запуск сразу нескольких программ
просмотра. Синтаксис такого сообщения аналогичен рассмотренным ранее. Тип
message предназначен для работы с обычными почтовыми сообщениями, которые,
однако, не могут быть переданы по разного рода причинам, которые объясняются
подтипами данного типа. Подтип partial предназначен для передачи одного
большого сообщения по частям. Атрибуты подтипа определяют идентификатор
сообщения (id), номер порции (number) и общее число порций (total). Каждая часть
имеет свое поле Content type. Это означает, что все сообщение может состоять из
частей разных типов. Другим подтипом является External body, который позволяет
ссылаться на внешние относительно сообщения информационные
источники. Стандартным подтипом типа message является rfc822. Данный подтип
определяет типы описания нетекстовой информации по стандарту RFC-822. Таких
типов имеется четыре: image - для описания графических образов. Наиболее
часто используются файлы форматов GIF и JPEG; audio - для описания
аудиоинформации. Для воспроизведения сообщения данного типа требуется
специальное оборудование; video - для передачи видеоизображений. Наиболее
популярным является формат MPEG; application - для передачи данных любого
другого формата. Обычно используется для передачи двоичных данных с последующим
промежуточным преобразованием. Так, если на машине стоит видеокарта с 512 Кбайт
памяти, а графика подготовлена в 256 цветах, то сначала ее следует
преобразовать, и здесь может помочь тип application. Основной подтип данного
типа - octet stream, но существуют ODA и postscript; поле типа кодирования
почтового сообщения (Content-Transfer-Encoding) < pclass=just>. Многие
данные передаются по почте в их исходном виде. Это могут быть 7-битные символы,
8-битные символы, 64-base символы и т. п. Однако при работе в разнородных
почтовых средах необходимо определить механизм их представления в стандартном
виде - US - ASCII. Для этого существуют процедуры кодирования такого рода
данных. Наиболее широко применяемая - uuencode. Для того чтобы при получении
данные были правильно распакованы, в стандарт введено поле
Content-Transfer-Encoding. Синтаксис этого поля
следующий: Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" / "8ВГГ
/ "7ВГГ / "BINARY" / x-token Каждая из альтернатив применяется в подходящем
случае. Альтернативы 8bit, 7bit, BINARY реально никакого преобразования не
требуют, так как почта передается байтами и SMTP не делает различия между ними.
Однако они введены для строгости описания типов. BASE64 обычно используется в
связке с типом text/ ISO - 8859 - 1. Элемент x-token позволяет пользователю
описать свою процедуру преобразования. Дополнительные необязательные поля:
как уже говорилось ранее, стандарт определяет еще два дополнительных поля:
Content-ID и Content-Description. Первое поле определяет уникальный
идентификатор содержания, а второе служит для комментария. Ни то, ни другое
программами просмотра обычно не отображаются. Подводя итоги обсуждения, еще
раз следует отметить, что стандарт MIME позволяет расширить область применения
электронной почты, обеспечить доступ к Другим информационным ресурсам сети в
стандартных форматах.
Знаете ли Вы, что cогласно релятивистской мифологии "гравитационное линзирование - это физическое явление, связанное с отклонением лучей света в поле тяжести. Гравитационные линзы обясняют образование кратных изображений одного и того же астрономического объекта (квазаров, галактик), когда на луч зрения от источника к наблюдателю попадает другая галактика или скопление галактик (собственно линза). В некоторых изображениях происходит усиление яркости оригинального источника." (Релятивисты приводят примеры искажения изображений галактик в качестве подтверждения ОТО - воздействия гравитации на свет) При этом они забывают, что поле действия эффекта ОТО - это малые углы вблизи поверхности звезд, где на самом деле этот эффект не наблюдается (затменные двойные). Разница в шкалах явлений реального искажения изображений галактик и мифического отклонения вблизи звезд - 1011 раз. Приведу аналогию. Можно говорить о воздействии поверхностного натяжения на форму капель, но нельзя серьезно говорить о силе поверхностного натяжения, как о причине океанских приливов. Эфирная физика находит ответ на наблюдаемое явление искажения изображений галактик. Это результат нагрева эфира вблизи галактик, изменения его плотности и, следовательно, изменения скорости света на галактических расстояниях вследствие преломления света в эфире различной плотности. Подтверждением термической природы искажения изображений галактик является прямая связь этого искажения с радиоизлучением пространства, то есть эфира в этом месте, смещение спектра CMB (космическое микроволновое излучение) в данном направлении в высокочастотную область. Подробнее читайте в FAQ по эфирной физике.
