3.2. Электронная почта в Internet

Электронная почта - один из важнейших информационных ресурсов Internet. Она является самым массовым средством электронных коммуникаций. Любой из пользователей Internet имеет свой почтовый ящик в сети. Если учесть, что через Internet можно принять или послать сообщения еще в два десятка международных компьютерных сетей, некоторые из которых не имеют on-line сервиса вовсе, то становится понятным, что почта предоставляет возможности, в некотором смысле даже более широкие, чем просто информационный сервис Internet. Через почту можно получить доступ к информационным ресурсам других сетей. Хорошим примером может служить доступ к архивам сети BITNET - документам и телеконференциям, которые ведутся на серверах списков (LISTSERVER) BITNET.

3.2.1. Принципы организации

Электронная почта во многом похожа на обычную почтовую службу. Корреспонденция, подготавливается пользователем на своем рабочем месте либо программой подготовки почты, либо просто обычным текстовым редактором. Обычно, программа подготовки почты вызывает текстовый редактор, который пользователь предпочитает всем остальным программам этого типа. Затем пользователь должен вызвать программу отправки почты (программа подготовки почты вызывает программу отправки автоматически). Стандартной программой отправки является программа sendmail. Sendmail работает как почтовый курьер, который доставляет обычную почту в отделение связи для дальнейшей рассылки. В Unix-системах sendmail сама является отделением связи. Она сортирует почту и рассылает ее адресатам. Для пользователей персональных компьютеров, имеющих почтовые ящики на своих машинах и работающих с почтовыми серверами через коммутируемые телефонные линии, могут потребоваться дополнительные действия. Так, например, пользователи почтовой службы Relcom должны запускать программу UUPC, которая осуществляет доставку почты на почтовый сервер.

Для работы электронной почты в Internet разработан специальный протокол Simple Mail Transfer Protocol (SMTP), который является протоколом прикладного уровня и использует транспортный протокол TCP. Однако, совместно с этим протоколом используется и Unix-Unix-CoPy (UUCP) протокол. UUCP хорошо подходит для использования телефонных линий связи. Большинство пользователей электронной почты Relcom реально пользуются для доставки почты на узел именно этим протоколом. Разница между SMTP и UUCP заключается в том, что при использовании первого протокола sendmail пытается найти машину-получателя почты и установить с ней взаимодействие в режиме on-line для того, чтобы передать почту в ее почтовый ящик. В случае использования SMTP почта достигает почтового ящика получателя за считанные минуты и время получения сообщения зависит только от того, как часто получатель просматривает свой почтовый ящик. При использовании UUCP почта передается по принципу "stop-go", т.е. почтовое сообщение передается по цепочке почтовых серверов от одной машины к другой пока не достигнет машины-получателя или не будет отвергнуто по причине отсутствия абонента-получателя. С одной стороны, UUCP позволяет доставлять почту по плохим телефонным каналам, т.к. не требуется поддерживать линию в течении времени доставки от отправителя к получателю, а с другой стороны бывает обидно получить возврат сообщения через сутки после его отправки из-за того, что допущена ошибка в имени пользователя. В целом же общие рекомендации таковы: если имеется возможность надежно работать в режиме on-line и это является нормой, то следует настраивать почту для работы по протоколу SMTP, если линии связи плохие или on-line используется чрезвычайно редко, то лучше использовать UUCP.

Рис. 3.14. Структура взаимодействия участников почтового обмена

Основой любой почтовой службы является система адресов. Без точного адреса невозможно доставить почту адресату. В Internet принята система адресов, которая базируется на доменном адресе машины, подключенной к сети. Например, для пользователя paul машины с адресом polyn.net.kiae.su почтовый адрес будет выглядеть как:

paul@polyn.net.kiae.su.

Таким образом, адрес состоит из двух частей: идентификатора пользователя, который записывается перед знаком "коммерческого @", и доменного адреса машины, который записывается после знака "@". Адрес UUCP был бы записан как строка вида:

net.kiae.su!polyn!paul

Программа рассылки почты Sendmail сама преобразует адреса формата Internet в адреса формата UUCP, если доставка сообщения осуществляется по этому протоколу.

3.2.2. Формат почтового сообщения (RFC-822)

При обсуждении примеров отправки и получения почтовых сообщений уже упоминался формат почтового сообщения. Разберем его подробнее. Формат почтового сообщения Internet определен в документе RFC-822 (Standard for ARPA Internet Text Message). Это довольно большой документ объемом в 47 страниц машинописного текста, поэтому рассмотрим формат сообщения на примерах. Почтовое сообщение состоит из трех частей: конверта, заголовка и тела сообщения. Пользователь видит только заголовок и тело сообщения. Конверт используется только программами доставки. Заголовок всегда находится перед телом сообщения и отделен от него пустой строкой. RFC-822 регламентирует содержание заголовка сообщения. Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ":". Минимально необходимыми являются поля Date, From, cc или To, например:

Date:   26 Aug 76 1429 EDT
From:   Jones@Registry.org
cc:
или
Date:   26 Aug 76 1429 EDT
From:   Jones@Registry.org
To:     Smith@Registry.org

Поле Date определяет дату отправки сообщения, поле From - отправителя, а поля сс и To - получателя(ей). Чаще заголовок содержит дополнительные поля:

Date:           26 Aug 76 1429 EDT
From:           George Jones<Jones@Registry.org>
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 <Kdavis@This-Host.This.net>
Subject:                Re: The Syntax in the RFC
Sender:         KSecy@Other-host
Reply-To:               Sam.Irving@Reg.Organization
To:                     George Jones <Jones@Registry.org>
cc:                     Important folks:
                        Tom Softwood <Balsa@Tree.Root>,
                        "Sam Irving"@Other-Host;,
                        Standard Distribution:
                        /main/davis/people/standard@Other-Host
Comment:                Sam is away on bisiness.
In-Reply-To:    <some.string@DBM.Group>, George`s message
X-Special-action: This is a sample of user-defined field-
                        names.
Message-ID:     <4331.629.XYzi-What@Other-Host

Поле Subject определяет тему сообщения, Reply-To - пользователя, которому отвечают, Comment - комментарий, In-Reply-To - показывает, что сообщение относится к типу "В ответ на Ваше сообщение, отвечающее на сообщение, отвечающее ...", X-Special-action - поле, определенное пользователем, которое не определено в стандарте.

Следует сказать, что формат сообщения постоянно дополняется и совершенствуется. Так в RFC-1327 введены дополнительные поля для совместимости с почтой X.400. Кроме этого, следует обратить внимание на поля некоторых довольно часто встречающихся заголовков, которые не регламентированы в RFC-822. Так первое предложение заголовка, которое начинается со слова From, содержит UUCP-путь сообщения, по которому можно определить, через какие машины сообщение "пробиралось". Поле Received: содержит транзитные адреса почтовых серверов с датой и временем прохождения сообщения. Вся эта информация полезна при разборе трудностей с доставкой почты.

В заключении хотелось бы отметить, что возможности почты не ограничиваются только пересылкой корреспонденции. По почте можно получить доступ ко многим ресурсам Internet, которые имеют почтовых роботов, отвечающих на запросы страждущих. Поэтому имеет смысл более детально изучить программное обеспечение, поддерживающее e-mail. Время, затраченное на чтение документации и опыты, окупятся возможностью получения информации из информационных архивов сети.

3.2.3. Формат представления почтовых сообщений MIME и его влияние на информационные технологии Internet

Стандарт MIME (или в нотации Internet, RFC-1341) предназначен для описания тела почтового сообщения Internet. Предшественником MIME является Стандарт почтового сообщения ARPA (RFC-822). Стандарт RFC-822 был разработан для обмена текстовыми сообщениями. С момента опубликования стандарта возможности аппаратных средств и телекоммуникаций ушли далеко вперед и стало ясно, что многие типы информации, которые широко используются в сети, невозможно передать по почте без специальных преобразований. Так в тело сообщения нельзя включить графику, аудио, видео и другие типы информации. RFC-822 не дает возможностей для передачи даже текстовой информации, которую нельзя реализовать 7-битовой кодировкой ASCII. Естественно, что при использовании RFC-822 не может быть и речи о передаче размеченного текста для отображения его различными стилями. Ограничения RFC-822 становятся еще более очевидными, когда речь заходит об обмене сообщениями в разных почтовых системах. Например, для приема/передачи сообщений из/в X.400 (новый стандарт ISO), который позволяет иметь двоичные данные в теле сообщения, ограничения старого стандарта могут стать фатальными, так как не спасает старый испытанный способ кодировки информации процедурой uuencode, так как эти данные могут быть по различному проинтерпретированы в X.400 и в программе рассылки почты в Internet (mail-agent).

В некотором смысле стандарт MIME ортогонален стандарту RFC-822. Если последний подробно описывает в заголовке почтового сообщения текстовое тело письма и механизм его рассылки, то MIME, главным образом, ориентирован на описание в заголовке письма структуры тела почтового сообщения и возможности составления письма из информационных единиц различных типов.

В стандарте зарезервировано несколько способов представления разнородной информации. Для этого используются специальные поля заголовка почтового сообщения:

поле версии MIME, которое используется для идентификации сообщения, подготовленного в новом стандарте;
поле описания типа информации в теле сообщения, которое позволяет обеспечить правильную интерпретацию данных;
поле типа кодировки информации в теле сообщения, указывающее на тип процедуры декодирования;
два дополнительных поля, зарезервированных для более детального описания тела сообщения.

Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. При этом следует учитывать, что анархия типов (безграничное их увеличение) тоже не допустима. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers Authority). Остановимся подробнее на форме и назначении полей, определяемых стандартом.

3.2.3.1. Поле версии MIME (MIME-Version)

Поле версии указывается в заголовке почтового сообщения и позволяет программе рассылки почты определить, что сообщение подготовлено в стандарте MIME. Формат поля выглядит как:

MIME-Version: 1.0

Поле версии указывается в общем заголовке почтового сообщения и относится ко всему сообщению целиком. Здесь уместно отметить, что в отличии от стандарта RFC-822 стандарт MIME позволяет перемешивать поля заголовка сообщения с телом сообщения. Поэтому все поля делятся на два класса: общие поля заголовка, которые записываются в начале почтового сообщения и частные поля заголовка, которые относятся только к отдельным частям составного сообщения и записываются перед ними.

3.2.3.2. Поле типа содержания тела почтового сообщения (Content-Type)

Поле типа используется для описания типа данных, которые содержатся в теле почтового сообщения. Это поле сообщает программе чтения почты, какого сорта преобразования необходимы для того, чтобы сообщение правильно проинтерпретировать. Эта же информация используется и программой рассылки при кодировании/декодировании почты. Стандарт MIME определяет семь типов данных, которые можно передавать в теле письма:

текст (text);
смешанный тип (multipart);
почтовое сообщение (message);
графический образ (image);
аудио-информация (audio);
фильм или видео (video);
приложение (application).

Общая форма записи поля выглядит в записи Бекуса-Наура следующим образом:

  Content-Type := type "/" subtype *[";" parameter]
  type :=     "application"     / "audio"
            / "image"           / "message"
            / "multipart"       / "text"
            / "video"           / x-token
  x-token := <Два символа "X-", за которыми без пробела
             следует последовательность любых символов>
  subtype := token
  parameter := attribute "=" value
  attribute := token
  value := token / quoted-string
  token := 1*<любой символ кроме пробела и управляющего символа,
    или tspecials>
    tspecials :=  "(" / ")" / "<" / ">" / "@"  ; Обязательно
               /  "," / ";" / ":" / "\" / <">  ; должны быть,
               /  "/" / "[" / "]" / "?" / "."  ; заключены в
               /  "="                          ; кавычки.

Остановимся подробнее на каждом из типов, разрешенных стандартом MIME.

Text. Этот тип указывает на то, что в теле сообщения содержится текст. Основным подтипом типа "text" является "plain", что обозначает так называемый планарный текст. Понятие планарного текста появилось в связи с тем, что существует еще размеченный текст, т.е. текст со встроенными в него символами управления отображением, и гипертекст, т.е. текст, который можно просматривать не последовательно, а произвольно, следуя гипертекстовым ссылкам. Для обозначения размеченного текста используют подтип "richtext", а для обозначения гипертекста - подтип "html". Вообще говоря, "html" - это специальный вид размеченного текста, который используется для представления гипертекстовой информации в системе World Wide Web, которая получила в последнее время широкое распространение в Internet. Понятие размеченного текста требует более подробного обсуждения, так как его передача и интерпретация являются одной из причин появления стандарта MIME.

"Richtext" определяет текст со встроенными в него специальными управляющими последовательностями, которые в соответствии со стандартом языка разметки документов SGML (Standard Generalized Markup Language) называются тагами. Таги представляют из себя последовательность символов типа "<строка-символов>". "Строка-символов" определяет управляющее действие. Таги делятся на таги начала элемента текста ("<......>") и таги конца элемента текста ("</......>"). В качестве примера такой разметки можно привести следующий фрагмент текста:

      <bold>Now</bold> is the time for
      <italic>all</italic> good men
      <smaller>(and <lt>women>)</smaller> to
      <ignoreme></ignoreme> come
      to the aid of their
      <nl>

В этом фрагменте <bold> означает выделение "жирным" шрифтом, <italic> - курсив, <smaller> - мелкий шрифт, <lt> - знак "<", игнорирование обозначено как <ignoreme>, новая строка как <nl>. Далее приведен полный перечень управляющих последовательностей:

Bold "жирный" шрифт

Italic курсив

Fixed causes the subsequent text to be in a fixed width font

Smaller уменьшенный шрифт

Bigger увеличенный шрифт

Underline подчеркнутый текст

Center отцентрированный текст

FlushLeft выровненный по левому краю

FlushRight выровненный по правому краю

Indent отступ от левого края

IndentRight отступ от правого края

Outdent отмена левого отступа

OutdentRight отмена правого отступа

SamePage размещение текста на одной странице

Subscript подстрочный текст

Superscript надстрочный текст

Heading заголовок

Footing текст ссылки

ISO-8859-X текст в кодировке ISO-8859-X

US-ASCII текст в кодировке US-ASCII

Excerpt цитата

Paragraph параграф

Signature автограф (подпись)

Comment комментарий (не отображается)

No-op нет операции

lt знак "меньше"("<")

nl новая строка

np новая страница

Специальный тип разметки задается подтипом "html". Это так называемый гипертекст. Разметка гипертекста строится по тому же принципу, как и в тексте типа "richtext". Однако применяются таги, позволяющие описать гипертекстовые ссылки. К таким тагам относятся "<A HREF="......">.....</A>", <IMG ....>, <A NAME="...."></A>. Таг "<A HREF="......"> .......</A>" определяет следующий фрагмент текста, который будет просматриваться. При этом текст между тагом начала и тагом конца выделяется в программе просмотра цветом или другим способом и используется как контекстная гипертекстовая ссылка. Таг <IMG .....> задет встроенный в текст документа графический образ. В некотором смысле этот таг аналогичен "multipart", который разрешает комбинировать сообщение из нескольких фрагментов разного типа. Таг <A NAME...> определяет "якорь", т.е. место внутри документа, на которое можно сослаться как на метку. В качестве примера такой разметки текста можно привести следующий фрагмент:

Это пример разметки документа в формате HTML.
<H1> Это заголовок документа</H1>
<P> - Это параграф.
<A HREF="test.html#mark1"> Это пример гипертекстовой ссылки.</A>
<IMG SRC="test.gif" ALIGN=Bottom> Это встроенный image.
<A NAME="mark1"></A> Это "якорь" внутри текста документа.

Multipart. Этот тип содержания тела почтового сообщения определяет смешанный документ. Смешанный документ может состоять из фрагментов данных разного типа. Данный тип имеет ряд подтипов.

Подтип "mixed" может создавать сообщения, состоящие из нескольких фрагментов, которые разделены между собой границей, задаваемой в качестве параметра подтипа. Приведем простой пример:

     From:       Nathaniel Borenstein <nsb@bellcore.com>
     To:         Ned Freed <ned@innosoft.com>
     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 read ers.
     --simple boundary
     This is implicitly typed plain ASCII text.
     It does NOT end with a linebreak.
     --simple boundary
     Content-type: text/plain; charset=us-ascii
     This is explicitly typed plain ASCII text.
     It DOES end with a linebreak.
     --simple boundary--
     This is the epilogue.  It is also to be ignored.

В данном примере поле "Content-Type" определяет подтип "mixed" и границу между фрагментами, как строку "--simple boundary--". В начале каждого фрагмента может быть задана своя строка с полем "Content-Type". Как видно из примера, существует два фрагмента, которые не отображаются: преамбула и эпилог, в которые можно поместить комментарии.

Другим подтипом может быть подтип "alternative". Данный подтип позволяет организовать вариабельный просмотр почтового сообщения в зависимости от типа программы просмотра. Приведем пример:

    From:  Nathaniel Borenstein <nsb@bellcore.com>
    To: Ned Freed <ned@innosoft.com>
    Subject: Formatted text mail
    MIME-Version: 1.0
    Content-Type: multipart/alternative; boundary=boundary42
    --boundary42
    Content-Type: text/plain; charset=us-ascii
    ...plain text version of message goes here....
    --boundary42
    Content-Type: text/richtext
    .... richtext version of same message goes here ...
    --boundary42
    Content-Type: text/x-whatever
    .... fanciest formatted version of same  message  goes  here
    ...
    --boundary42--

В этом примере для работы с планарным текстом при использовании алфавитно-цифровых программ просмотра предназначен первый фрагмент текста. Для просмотра размеченного текста используется второй фрагмент, для специальной программы просмотра может быть подготовлен специальный вариант (фрагмент 3).

Подтип "digest" предназначен для многоцелевого почтового сообщения, когда различным частям хотят приписать более детальную информацию, чем просто тип:

    From: Moderator-Address
    MIME-Version: 1.0
    Subject:  Internet Digest, volume 42
    Content-Type: multipart/digest;
         boundary="---- next message ----"
    ------ next message ----
    From: someone-else
    Subject: my opinion
    ...body goes here ...
    ------ next message ----
    From: someone-else-again
    Subject: my different opinion
    ... another body goes here...
    ------ next message ------

Приведенный пример показывает как можно воспользоваться подтипом "digest" для рассылки разным пользователям и по разному поводу почты, используя поля "From" и "Subject" в качестве частных заголовков.

Подтип "parallel" предназначен для составления такого почтового сообщения, части которого должны отображаться одновременно, что предполагает запуск сразу нескольких программ просмотра. Синтаксис такого сообщения аналогичен рассмотренным выше.

Тип "message" предназначен для работы с обычными почтовыми сообщениями, которые однако не могут быть переданы по почте по разного рода причинам. Эти причины объясняются подтипами данного типа.

Подтип "partial" предназначен для передачи одного большого сообщения по частям для последующей автоматической сборки у получателя. Приведем пример передачи аудио-сообщения разбитого на части:

          X-Weird-Header-1: Foo
          From: Bill@host.com
          To: joe@otherhost.com
          Subject: Audio mail
          Message-ID: id1@host.com
          MIME-Version: 1.0
          Content-type: message/partial;
               id="ABC@host.com";
               number=1; total=2
          X-Weird-Header-1: Bar
          X-Weird-Header-2: Hello
          Message-ID: anotherid@foo.com
          Content-type: audio/basic
          Content-transfer-encoding: base64
          ... first half of encoded audio data goes here...
     and the second half might look something like this:
          From: Bill@host.com
          To: joe@otherhost.com
          Subject: Audio mail
          MIME-Version: 1.0
          Message-ID: id2@host.com
          Content-type: message/partial;
               id="ABC@host.com"; number=2; total=2
          ... second half of encoded audio data goes here...

Атрибуты подтипа определяют идентификатор сообщения (id), номер порции (number) и общее число порций (total). Следует обратить внимание на то, что каждая часть имеет свое поле "Content-Type". Это означает, что все сообщение может состоять из частей разных типов.

Другим подтипом является "External-Body", который позволяет ссылаться на внешние, относительно сообщения, информационные источники. Приведем конкретный пример:

         From: Whomever
         Subject: whatever
         MIME-Version: 1.0
         Message-ID: id1@host.com
         Content-Type: multipart/alternative; boundary=42
         --42
         Content-Type: message/external-body;
              name="BodyFormats.ps";
              site="thumper.bellcore.com";
              access-type=ANON-FTP;
              directory="pub";
              mode="image";
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
         Content-type: application/postscript
         --42
         Content-Type: message/external-body;
              name="/u/nsb/writing/rfcs/RFC-XXXX.ps";
              site="thumper.bellcore.com";
              access-type=AFS
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
         Content-type: application/postscript
         --42
         Content-Type: message/external-body;
              access-type=mail-server
              server="listserv@bogus.bitnet";
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
         Content-type: application/postscript
         get rfc-xxxx doc
         --42--

В данном примере использованы "External-Body" и "multipart/alternative". Все сообщение разбито на несколько фрагментов. В каждом из фрагментов находится ссылка на внешний файл. Реально, тела почтового сообщения нет (границы программами просмотра не отображаются). Однако, если программа просмотра способна работать с внешними протоколами, то можно ссылки разрешить автоматически, запуская соответствующий сервис.

Стандартным подтипом типа "message" является "rfc822". Данный подтип определяет сообщения стандарта RFC-822.

Типы описания нетекстовой информации. Таких типов имеется четыре:

"image" для описания графических образов. Наиболее часто используются файлы форматов GIF и JPEG.
"audio" для описания аудио-информации. Для воспроизведения сообщения данного типа требуется специальное оборудование.
"video" для передачи фильмов. Наиболее популярным является формат MPEG.
"application" для передачи данных любого другого формата. Обычно используется для передачи двоичных данных с последующим промежуточным преобразованием. Так, если на машине стоит видео-карта с 512Kb памяти, а графика подготовлена в 256 цветах, то сначала ее следует преобразовать и здесь может помочь тип "application". Основной подтип данного типа - "octet-stream", но существуют "ODA" и "Postscript". Назначение данных подтипов ясно из названия - обозначение данных для последующей обработки как данных в форматах, определяемых подтипом.

3.2.3.3. Поле типа кодирования почтового сообщения (Content-Transfer-Encoding)

Многие данные передаются по почте в их исходном виде. Это могут быть 7bit символы, 8bit символы, 64base символы и т.п. Однако, при работе в разнородных почтовых средах необходимо определить механизм их представления в стандартном виде - US-ASCII. Для этого существуют процедуры кодирования такого сорта данных. Наиболее широко применяемая - uuencode. Для того, чтобы при получении данные были бы правильно распакованы, в стандарт введено поле "Сontent-Transfer-Encoding". Синтаксис этого поля следующий:

    Content-Transfer-Encoding := "BASE64" / "QUOTED-PRINTABLE" /
                                 "8BIT"   / "7BIT" /
                                 "BINARY" / x-token

Каждая из альтернатив применяется в своем подходящем случае. Альтернативы "8bit", "7bit", "BI-NARY" реально никакого преобразования не требуют, так как почта передается байтами и SMTP не делает различия между ними. Однако они введены для строгости описания типов. "BASE64" обычно используется в связке с типом "text/ISO-8859-1". Элемент "x-token" позволяет пользователю описать свою процедуру преобразования.

3.2.3.4. Дополнительные необязательные поля

Как уже говорилось ранее, стандарт определяет еще два дополнительных поля: "Content-ID" и "Content-Description". Первое поле определяет уникальный идентификатор содержания, а второе служит для комментария содержания. Ни то, ни другое программами просмотра, обычно, не отображаются.

В заключении обсуждения стандарта MIME приведем комплексный пример без комментариев:

  MIME-Version: 1.0
  From: Nathaniel Borenstein <nsb@bellcore.com>
  Subject: A multipart example
  Content-Type: multipart/mixed;
       boundary=unique-boundary-1
  This is the preamble area of a multipart message.
  Mail readers that understand multipart format should ignore this 
  preamble. If you are reading this text, you might want to consider
  changing to a mail reader thatunderstands how to properly display 
  multipart messages.
  --unique-boundary-1
    ...Some text appears here...
  [Note that the preceding blank line means no header fields were given 
  and this is text, with charset US ASCII.  It could have been done 
  with explicit typing as in the next part.]
  --unique-boundary-1
  Content-type: text/plain; charset=US-ASCII
  This could have been part of the previous part, but illustrates 
  explicit versus implicit
  typing of body parts.
  --unique-boundary-1
  Content-Type: multipart/parallel;
       boundary=unique-boundary-2
  --unique-boundary-2
  Content-Type: audio/basic
  Content-Transfer-Encoding: base64
  ... base64-encoded 8000 Hz single-channel
      u-law-format audio data goes here....
  --unique-boundary-2
  Content-Type: image/gif
  Content-Transfer-Encoding: Base64
  ... base64-encoded image data goes here....
  --unique-boundary-2--
  --unique-boundary-1
  Content-type: text/richtext
  This is <bold><italic>richtext.</italic></bold>
  <nl><nl>Isn't it
  <bigger><bigger>cool?</bigger></bigger>
  --unique-boundary-1
  Content-Type: message/rfc822
  From: (name in US-ASCII)
  Subject: (subject in US-ASCII)
  Content-Type: Text/plain; charset=ISO-8859-1
  Content-Transfer-Encoding: Quoted-printable
  ... Additional text in ISO-8859-1 goes here ...
  --unique-boundary-1--

Подводя итоги обсуждения, еще раз следует отметить, что стандарт MIME позволяет расширить область применения электронной почты, обеспечить доступ к другим информационным ресурсам сети в стандартных форматах.

Назад | Содержание | Вперед