|
|
|
|
|
 |
|
|
|
|
|
|
На этой странице — конспект беседы ЯНЗ (Якова Наумовича Зайдельмана) с Куками по теме: Как устроено электронное письмо?ЯНЗ. Вид электронного письма в котором он должен передаваться по Сети описывает специальный стандарт RFC 2822, принятый в апреле 2001 года.
Петя. Неужели современные правила появились так недавно? Я думал, электронная почта существует значительно дольше. ЯНЗ. Ты думал правильно. С августа 1982 года и до принятия RFC 2822 действовал стандарт STD 11, чаще упоминаемый как RFC 822. Вася. STD — это, вероятно, сокращение от английского слова standard (стандарт)? ЯНЗ. Совершенно верно. Вася. А как расшифровывается RFC? И что означают числа? ЯНЗ. RFC — это Request For Comments, запрос комментариев. Так по традиции называют все вновь предлагаемые стандарты Интернета. Такое название подчёркивает, что разработчики рассматривают эти документы не как строгий закон на все времена, а как предложения, которые можно обсуждать, дорабатывать, исправлять. Все RFC нумеруются по порядку. Первый RFC был опубликован в апреле 1969 года, последний на сегодняшний день RFC 4109 в мае 2005 года. Петя. Много ли нововведений в правилах 2001 года по сравнению с предыдущей версией? ЯНЗ. Это может показаться странным и неожиданным, но серьёзных отличий практически нет. Изменения сводятся, в основном, к упрощению отдельных сложных конструкций и более чётким формулировкам некоторых положений. Не случайно номера старого и нового стандарта так похожи. Да и специалисты до сих пор чаще ссылаются на RFC 822, хотя он формально уже отменён. Вася. Неужели за 20 лет не потребовалось ничего изменить по существу? ЯНЗ. Стандарт оказался настолько удобным и хорошо проработанным, что практически без изменений действует до сих пор. Наиболее серьёзное дополнение к почтовым стандартам появилось в ноябре 1996 года. Это дополнение получило название MIME (Multipurpose Internet Mail Extensions) — многоцелевые расширения Интернет-почты. MIME описывает правила оформления писем на языках, отличных от английского и писем с нетекстовым содержанием (писем с вложениями). Петя. А что, до 1996 года можно было отправлять только тексты и писать только по-английски? ЯНЗ. Конечно, нет. Просто в RFC 822 не описаны стандартные правила для таких писем, поэтому использовались различные способы, не всегда совместимые между собой. MIME не отменил RFC 822, а дополнил его новыми соглашениями. Предложенные новшества прижились, и сегодня практически все почтовые клиенты работают с письмами в формате MIME. Петя. Наверное, MIME тоже описан в каком-то RFC. ЯНЗ. Конечно, и даже не в одном. Авторы MIME разделили его описание на 5 частей и поместили их в 5 отдельных RFC: с 2045 по 2049. Рассмотрим структуру письма на простом примере. Вот письмо, которое я написал сам себе с одного адреса на другой специально для такого анализа.
From yz100@yandex.ru Mon Jun 06 22:49:15 2005
Received: from mx18.yandex.ru ([213.180.200.18]:4363)
by pier.botik.ru with esmtp (Exim 4.34)
id 1DfMep-0005SR-G7
for yz@pereslavl.ru; Mon, 06 Jun 2005 22:49:14 +0400
Received: from yz.pereslavl.ru ([193.232.174.148]:45323 "EHLO yz.pereslavl.ru"
smtp-auth: "yz100" TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
by mail.yandex.ru with ESMTP id S3375477AbVFFSsy (ORCPT
<rfc822;yz@pereslavl.ru>); Mon, 6 Jun 2005 22:48:54 +0400
Date: Mon, 6 Jun 2005 22:48:49 +0400
From: Yakov Zaidelman <yz100@yandex.ru>
X-Mailer: The Bat! (v2.12.03) Business
X-Priority: 3 (Normal)
Message-ID: <938714119.20050606224849@yandex.ru>
To: yz@pereslavl.ru
Subject: Письмо для примера
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
X-Botik-Recipient: yz@yz.pereslavl.ru
Это письмо написано для примера.
--
ЯНЗ
Вася. Это не похоже на обычное письмо. ЯНЗ. Дело в том, что я показал письмо полностью — в том виде, в котором оно было принято моим почтовым клиентом, а вы привыкли видеть только содержательную часть, очищенную от служебной информации. А нас сейчас будет в первую очередь интересовать именно служебная информация. В соответствии с RFC 2822 любое письмо состоит из заголовков и тела. Заголовки — это всё, что расположено в письме до первой пустой строки, тело — после неё. Тело содержит собственно текст письма, подготовленный отправителем, а почти все заголовки формируются автоматически. Заголовки письма состоят из отдельных полей. Каждое поле начинается с новой строки, причём обязательно с первой позиции. Строка, которая начинается с пробела, содержит продолжение поля из предыдущей строки. Поле состоит из названия и значения, разделённых двоеточием. Название указывает, что находится в поле, а значение содержит конкретную информацию. Петя. Наверное, существует список возможных названий полей. ЯНЗ. Не совсем так. Стандарт описывает наиболее существенные поля (их сравнительно немного) и разрешает использовать дополнительные. Фактически все поля заголовков можно разделить на 3 группы:
Вася. Неужели нельзя пользоваться почтой, не разбираясь во всех этих тонкостях? ЯНЗ. Пользоваться, конечно, можно. Можно ведь пользоваться компьютером, не умея программировать, и водить автомобиль, ничего не понимая в его конструкции. Но во всех этих случаях у знающего человека есть преимущество: он не просто выполняет какие-то действия, он понимает, что при этом на самом деле происходит, а значит, может выбрать наиболее эффективный способ действия и найти решение в нестандартной ситуации, когда привычные методы не помогают. Давайте для начала разберём все поля из заголовков моего письма-примера. Поле Received (получено) можно сравнить с почтовым штемпелем. Это поле вставляет каждый сервер, через который проходит письмо при пересылке. В содержании поля указывается компьютер-отправитель, сервер-получатель, дата пересылки и некоторая дополнительная информация. В моём письме, например, два таких поля: первое (в письме оно записано вторым) описывает передачу письма с моего компьютера на сервер Яндекса mail.yandex.ru, второе (в письме — первое) — с Яндекса на pier.botik.ru. Pier — центральный сервер сети Ботик, с которого я принимаю почту на свой домашний компьютер. Поскольку мой компьютер к серверам не относится, он не вставляет в письмо свой штамп получения.
...
Received: from mx18.yandex.ru ([213.180.200.18]:4363)
by pier.botik.ru with esmtp (Exim 4.34)
id 1DfMep-0005SR-G7
for yz@pereslavl.ru; Mon, 06 Jun 2005 22:49:14 +0400
Received: from yz.pereslavl.ru ([193.232.174.148]:45323 "EHLO yz.pereslavl.ru"
smtp-auth: "yz100" TLS-CIPHER: <none> TLS-PEER-CN1: <none>)
by mail.yandex.ru with ESMTP id S3375477AbVFFSsy (ORCPT
<rfc822;yz@pereslavl.ru>); Mon, 6 Jun 2005 22:48:54 +0400
...
Обратите внимание на многострочную запись поля Received. Если всю информацию поместить в одной строке, читать её будет неудобно. Поэтому данные разбиты на несколько строк, причём строки продолжения обязательно начинаются с пробелов. Вася. А почему поля Received рассмотрены в таком странном порядке? Первое названо вторым, второе — первым. ЯНЗ. Дело в том, что каждый очередной сервер, через который проходит письмо, добавляет свой штемпель к началу письма. Поэтому первое поле Received всегда содержит сведения о последней пересылке, а последнее — о первой. Чтобы проследить хронологию передач письма, читать поля Received нужно в обратном порядке, снизу вверх. Продолжим разбор. Поле Date (дата) вставляет в письмо почтовый клиент-отправитель. Это поле содержит дату и время отправки письма. В данном случае письмо было отправлено 6 июня 2005, в 22:48.
...
Date: Mon, 6 Jun 2005 22:48:49 +0400
...
Вася А что означает число +0400? Я заметил, что оно стоит не только в поле Date, но и после каждой даты в поле Received. ЯНЗ. Эта запись (называть её числом не совсем правильно) означает часовой пояс, то есть разницу со стандартным временем по Гринвичу. Сдвиг в данном случае составляет 4 часа в большую сторону, что соответствует московскому летнему времени. Все серверы, через которые проходило моё письмо, находятся в зоне действия московского времени, поэтому и часовой пояс у них одинаковый. Если бы письмо прошло через сервер в Киеве, в соответствующем поле Received стоял бы пояс +0300, а если бы путь письма пролегал через Нью-Йорк, то -0400. Поле From (от) содержит данные об отправителе письма. Обычно здесь указывается имя отправителя и его e-mail.
...
From: Yakov Zaidelman <yz100@yandex.ru>
...
Петя Судя по названиям, следующие два поля к стандартным не относятся.
...
X-Mailer: The Bat! (v2.12.03) Business
X-Priority: 3 (Normal)
...
ЯНЗ. Это так. Их названия начинаются с X-, то есть заведомо не входят в список стандартных. Эти два поля относятся к разряду стандартов де-факто. Поле X-Mailer (мейлер) указывает, какой почтовый клиент (мейлер) использовался при написании письма. Многие мейлеры вставляют это поле в качестве своеобразной собственной подписи. Письмо, которое мы разбираем, было отправлено с помощью версии 2.12.03 мейлера The Bat! Поле X-Priority (приоритет) содержит уровень срочности (приоритет) письма. Чем меньше число в этом поле, тем более важным и срочным считается письмо. Стандартное поле Message-ID (код сообщения) содержит условный код письма. Обычно этот код формирует почтовый клиент-отправитель. Предполагается, что код должен получаться уникальным, то есть каждое из миллионов ежедневно создаваемых писем получает свой неповторимый код.
...
Message-ID: <938714119.20050606224849@yandex.ru>
...
Вася А зачем это нужно? ЯНЗ. Например, для того, чтобы найти письмо в архиве. Уникальный код даёт возможность однозначно выделить нужное сообщение. Поле To (кому) содержит e-mail и имя получателя, поле Subject (тема) — тему письма. Тему задаёт автор письма во время его создания.
...
To: yz@pereslavl.ru
Subject: Письмо для примера
MIME-Version: 1.0
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
X-Botik-Recipient: yz@yz.pereslavl.ru
Это письмо написано для примера.
--
ЯНЗ
Следующие 3 поля описывают параметры MIME. Поле MIME-Version (версия MIME) указывает, в соответствии с какой версией стандарта MIME оформлено данное письмо. Поля Content-Type (тип содержимого) и Content-Transfer-Encoding (кодирование содержимого при передаче) описывают важные технические характеристики письма. Например, в данном случае письмо содержит обычный текст (запись text/plain) в кодировке КОИ-8 (запись charset=koi8-r), переданный с помощью 8-битного кодирования (запись 8bit) и размещённый непосредственно в теле письма. Об этих полях, а точнее, о связанных с ними возможностях и проблемах, я расскажу немного позже. Последнее поле письма — X-Botik-Recipient (Ботик-получатель). Это нестандартное поле включается в письма почтовым сервером системы Ботик, услугами которого я пользуюсь. Вася Ничего не сказано о самой первой строке письма. Она находится среди заголовков, но не похожа на правильное поле, так как между названием и значением нет двоеточия.
From yz100@yandex.ru Mon Jun 06 22:49:15 2005
Received: from mx18.yandex.ru ([213.180.200.18]:4363)
by pier.botik.ru with esmtp (Exim 4.34)
id 1DfMep-0005SR-G7
for yz@pereslavl.ru; Mon, 06 Jun 2005 22:49:14 +0400
...
ЯНЗ. Эта необязательная строка иногда добавляется последним на пути письма сервером. Она может выглядеть по-разному, и мы не будем подробно с ней разбираться. Вася Когда я читаю письма, то вижу только текст, то есть тело. Сверху видны некоторые заголовки: отправитель, получатель, тема, дата, но они выглядят совсем не так, как в этом примере. ЯНЗ. Мы видим то, что показывает почтовая программа. Обычно пользователю видны только наиболее интересные для него заголовки, примерно те, которые перечислил Вася, и показывают их в удобном (по мнению авторов мейлера) для человека виде. Вот как, например, выглядит на моём компьютере рассмотренное письмо в программе The Bat!:
А вот так в Outlook Express:
Вася А можно ли увидеть письмо как есть, со всеми заголовками? ЯНЗ. Конечно. Практически все клиенты предоставляют такую возможность, хотя и с разной степенью удобства. Вот как можно увидеть заголовки письма в самых популярных мейлерах. The Bat! (способ 1)Вид/Показывать заголовки (RFC-822) (или аккорд Shift+Ctrl+K). В этом случае при просмотре письма будут показаны все заголовки. Основной текст декодируется, то есть показывается в удобном для чтения виде, а не так, как он выглядел при пересылке:
The Bat! (способ 2)Специальное/Исходный текст письма (или F9). Показывает всё письмо так, как оно выглядело при пересылке:
Outlook Express (способ 1)Файл/Свойства/Подробно Показывает заголовки письма. Тела при этом не видно:
Outlook Express (способ 2)Файл/Свойства/Подробно/Исходное сообщение Показывает всё письмо так, как оно выглядело при пересылке:
Вася Почему-то при таком просмотре искажается текст письма. ЯНЗ. Дело в том, что письмо было отправлено в кодировке КОИ-8, а оба мейлера используют кодировку Windows-1251. Когда человек читает письмо, мейлер, используя информацию из заголовка, перекодирует текст, но если мы просим показать письмо в исходном, необработанном виде, перекодировка отключается. Петя А можно ли в Outlook Express увидеть письмо с заголовками, но при этом перекодированным? Примерно так, как это делает The Bat! в первом показанном способе. ЯНЗ. Мне такой способ неизвестен. Правда, в меню окна письма Outlook Express есть пункт Вид/Все заголовки, который, похоже, предназначен как раз для этого, но мне не удалось заметить никакой зависимости внешнего вида письма от наличия или отсутствия галочки в этом пункте. Петя Разбиение письма на тело и заголовки описано в RFC 822, а MIME дополнил стандарт RFC 822 новыми заголовками. В приведённом примере мы видели два таких новых заголовка: Content-Type и Content-Transfer-Encoding. ЯНЗ. Это так. Но кроме этого MIME описывает принципиально новую конструкцию, которой не было в RFC 822 — составные письма, то есть состоящие из нескольких частей. Новые поля позволяют пересылать различные виды информации, а составные письма — сочетать их в одном и том же письме. Давайте рассмотрим структуру составного письма на примере. И на этот раз я тоже послал письмо самому себе: адреса отправителя и получателя совпадают. Письмо содержит 3 части: текст самого письма, дополнительный текстовый файл и небольшая фотография. Вот как выглядит полный текст полученного письма.
From yz@pereslavl.ru Tue Jun 07 09:53:47 2005
Received: from yz.pereslavl.ru ([193.232.174.148]:2695)
by pier.botik.ru with esmtp (Exim 4.34)
id 1DfX1u-000846-4O
for yz@pereslavl.ru; Tue, 07 Jun 2005 09:53:47 +0400
Date: Tue, 7 Jun 2005 09:53:38 +0400
From: Yakov Zaidelman <yz@pereslavl.ru>
X-Mailer: The Bat! (v2.12.03) Business
X-Priority: 3 (Normal)
Message-ID: <447522625.20050607095338@pereslavl.ru>
To: Yakov Zaidelman <yz@pereslavl.ru>
Subject: Письмо с приложениями
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----------AF51A524E1F0D9"
X-Botik-Recipient: yz@yz.pereslavl.ru
------------AF51A524E1F0D9
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Это основной текст письма.
В письме два приложения: текст и фотография.
------------AF51A524E1F0D9
Content-Type: text/plain; name="example.txt"
Content-transfer-encoding: base64
Content-Disposition: attachment; filename="example.txt"
/NTPINDSyczP1sXOztnKIMsg0MnT2M3VINTFy9PUz9fZyiDGwcrMLg0K
------------AF51A524E1F0D9
Content-Type: image/jpeg; name="yz.jpg"
Content-transfer-encoding: base64
Content-Disposition: attachment; filename="yz.jpg"
/9j/4AAQSkZJRgABAAEAlgCWAAD//gAfTEVBRCBUZWNobm9sb2dpZXMgSW5jLiBWMS4wMQD/
2wCEAB4VFxoXEx4aGBoiIB4kLkwxLioqLl5DRzdMb2F1c21ha2l6irCVeoKnhGlrmdGbp7a8
xcfFd5PY6NfA5rDBxb4BICIiLiguWjExWr5+a36+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+
vr6+vr6+vr6+vr6+vr6+vr6+vr6+vr6+vv/EAaIAAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYH
CAkKCwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoLEAACAQMDAgQDBQUEBAAAAX0BAgMA
BBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpD
REVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaan
qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+foRAAIB
AgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDTh
JfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWG
h4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm
5+jp6vLz9PX29/j5+v/AABEIAGsARQMBIQACEQEDEQH/2gAMAwEAAhEDEQA/AOhooAQsFGSc
ComuY1GeSPagASdHxtDc1IHVun8qAHUUAFFABQTgUAZjzS3Ep8lTsXgHtTlt3+87MT9elADG
UqcruHPr1p0rzQgP19SvYUAWbS4WdSUbIzVmgAooAKy/Pa+mZVJECHHB5Y0AaMShVACgY9KH
jDCgCq1tIDhcEGpgpWMqy5oAz7iNrGZbmLOxjh1rVRw6K68hhkUAOooAqajL5VlKw6kYHtWf
pbAQ7cc7s0AbMf3c06gAooAq3+PssoOOQcfWoNFlaS0KsfuNgfSgDRooAqaoAdPmGM8flWTp
5VInkJ4zQBoQ6gojy0MoUfxBc1Zt7qG5GYnDe2MUATO6Rrudgo9Sarf2hbk4jYyEddgzQBWu
7hbizlaMn5eoPGPwo0Ef6LI2Or/0FAGpRQBDcJvUdcZrGsowVeI9N5/lQBYaxnYHdPIp7YFW
YLfyShDE9BzQBYuYvOTZkge1Z8dnMiMFmkDk90oAkmhMdnKXHzlCD71NpkXlWUYzncA3580A
XKKAEIyCKxYyYtRdD9RQBso25AajDb5hj7o70ATelFAFDV5NlqAP4jircC+XBGn91QKAJKKA
CsTVyYtQhk5wV/kaALDagsES4XczCstr2dZ/NRip9O1AD01KczB5CWHTAOK2LS/iuWKAEMB0
oAqai4lu7eH+EsMn15rXoAKKACsjX0Jjhcfwkj88UAZkbh8B/THFaFrDAMqz7T9RQAtxaQlQ
Ffnv0H8qpwubaUvnpx9aALOmK1zfGZhlYx39T/k1uUAFFABWbrM8Udt5brvd/uD096AMBG2k
VL9objPagBwumwfU1HuaRgF5JNAGvo9wqM9m21WViQf71a9ABRQBRu9RgtgRuDyf3Rz+dc9P
NJPMZJWyxP5fSgBApfofmx+dRnj73agByqzfdUsSeoFbVpapZWbz3ABcrwPT2oAxy7CXerEN
nOfet6x1SOZQk5EcnTnoaANIcjjpRzQBx2ab3oAkC5/xrRtJomIW5jRsfdbFAGsphiTIVVUD
Ofasa9umu5M4xGv3R/WgDOc/OaBQBYjup412xzOo9A1O+23X/PxJ/wB9UAVTTaAJ4vmAqdcY
ye1AE0kMu0M025cfdPGKiIwKAKLdT9aUGgB1FADDTTQBYg+41PnOE4/vUAWZGP8AZ689VNV0
J8pee1AFSgUAPooA/9k=
------------AF51A524E1F0D9-
Вася Начало очень похоже на предыдущее письмо. А вот дальше что-то непонятное. Ровные строчки абракадабры — это, видимо, превращённая в текст фотография. Но почему в теле письма оказались поля заголовков? ЯНЗ. Заголовки в теле письма — это и есть основная идея, на которой построены составные письма. Содержание и кодирование каждой части определяется независимо и описывается отдельными заголовками. Давайте посмотрим, как устроено составное письмо. Как и в обычном письме, сначала идут заголовки. Но в составном письме в общие заголовки включаются только те поля, которые задают характеристики письма в целом, а не отдельных частей. Вася По сравнению с предыдущим письмом отличий не так уж много: изменилось значение поля Content-Type и пропало поле Content-Transfer-Encoding. ЯНЗ. Это очень важные отличия. Поле Content-Type в составных письмах обязательно содержит слово multipart, дословно означающее “из многих частей”. В этом же поле содержится параметр boundary (граница). Значение этого параметра — произвольная строка, которая не встречается в тексте письма. Обычно она автоматически формируется почтовым клиентом отправителя. Вася Я догадался, для чего нужна эта строка. Она отделяет друг от друга части письма. ЯНЗ. Совершенно верно. Если быть совсем точным, то разделитель частей получается из строки boundary добавлением спереди двух минусов. В нашем примере это не бросается в глаза, потому что заданная в заголовках граница начинается с большого числа минусов. Но если вы их аккуратно подсчитаете, то увидите, что строка в заголовках начинается с 10 минусов, а между частями письма — с 12. Петя А зачем понадобились эти два лишних минуса? ЯНЗ. Они появились по историческим причинам, чтобы обеспечить совместимость MIME с одним из более ранних форматов. Составное письмо может содержать произвольное число граничных строк. Строки, расположенные между двумя последовательными границами, образуют одну часть письма. При этом каждая часть устроена так же, как письмо в целом: она состоит из заголовков и тела, разделённых пустой строкой. Заголовки состоят из полей, которые записываются по уже известным вам правилам, и описывают характеристики каждой отдельной части. Петя В отдельных частях письма могут быть любые поля? ЯНЗ. Названия всех полей, определённых в MIME, начинаются с Content-. Использование других названий не запрещено, но их правильная обработка не гарантируется. Вася Было сказано, что MIME не противоречит стандарту RFC 822, а только расширяет его. Но если я правильно понял, RFC 822 не предусматривает заголовков в теле письма. Получается, что составное письмо противоречит стандарту. ЯНЗ. Вовсе нет. С точки зрения RFC 822 составное письмо, как и любое другое, включает заголовки и тело. При этом тело включает все части письма вместе с их заголовками и границами между ними. Например, с точки зрения MIME письмо, которые мы рассмотрели — это составное письмо из трёх частей, а с точки зрения RFC 822 — это обычное письмо, включающее 16 строк заголовков и 50 строк тела. Мейлер, не поддерживающий MIME, покажет тело такого письма в уже знакомом вам “первозданном” виде. Специально для таких мейлеров MIME разрешает вставлять в письма пролог: произвольные строки в начале тела письма до первого разделителя частей (на иллюстрации пролог выделен красным):
From yz@pereslavl.ru Tue Jun 07 09:53:47 2005
Received: from yz.pereslavl.ru ([193.232.174.148]:2695)
by pier.botik.ru with esmtp (Exim 4.34)
id 1DfX1u-000846-4O
for yz@pereslavl.ru; Tue, 07 Jun 2005 09:53:47 +0400
Date: Tue, 7 Jun 2005 09:53:38 +0400
From: Yakov Zaidelman <yz@pereslavl.ru>
X-Mailer: The Bat! (v2.12.03) Business
X-Priority: 3 (Normal)
Message-ID: <447522625.20050607095338@pereslavl.ru>
To: Yakov Zaidelman <yz@pereslavl.ru>
Subject: Письмо с приложениями
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----------AF51A524E1F0D9"
X-Botik-Recipient: yz@yz.pereslavl.ru
Это письмо написано по стандарту MIME,
но ваш мейлер этот стандарт не поддерживает.
------------AF51A524E1F0D9
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit
Это основной текст письма.
В письме два приложения: текст и фотография.
------------AF51A524E1F0D9
...
Пролог не принадлежит ни одной части письма (как мы знаем, часть располагается между двумя последовательными разделителями, а пролог находится до первого разделителя), и если мейлер поддерживает MIME (MIME-мейлер), то пролог вообще показан не будет, а в не MIME-мейлере он будет виден в самом начале письма. Поэтому некоторые MIME-мейлеры при отправке составных писем автоматически вставляют в пролог примерно такую фразу: “Это письмо написано по стандарту MIME, но ваш мейлер этот стандарт не поддерживает”. Петя Понятно. Получатель с MIME-мейлером этой фразы не увидит, а если она оказалась видна, значит, мейлер и в самом деле не понимает MIME. Остроумное решение!
|
|
|
