При пересиланні пошти часто виникає необхідність включити всередину листа інший лист. Для цього і використовується тип 'message'.
Основний підтип - "rfc822" - не вимагає параметрів в поле Content-Type. Додаткові підтипи - "partial" і "External-body" - припускають наявність параметрів.
Основний підтип 'message / rfc822'
Цей підтип вказує, що тіло листа містить вкладене лист в стандарті RFC 822, однак, на відміну від заголовка RFC 822 верхнього рівня, для кожної частини, що є листом RFC 822, не потрібно наявності полів "From", "Subject" і, по крайней міру, одного поля "To".
Не дивлячись на використання числа "822", тіло, що має підтип 'message / rfc822', може включати додаткову інформацію відповідно до стандарту MIME. Іншими словами, лист 'message / rfc822' може бути MIME-листом.
Підтип 'message / partial'
Цей підтип визначено з метою забезпечення можливості пересилання дуже великих об'єктів у вигляді декількох роздільних частин, автоматічскі "склеюються" поштовою програмою одержувача. Цей механізм може стати в нагоді, коли проміжні поштові шлюзи обмежують індивідуальний розмір пересилаються листів. Т.ч. цей підтип говорить про те, що лист містить лише частина великого послання.
Для цього підтипу необхідно вказівку трьох параметрів:
- "Id" - унікальний ідентифікатор, що дозволяє виявити інші частини послання.
- "Number" - ціле число, що означає номер частини послання.
- "Total" - ціле число, що означає загальну кількість частин. Потрібно лише в останній частині і не обов'язковий (хоча рекомендується) для попередніх частин. Ці параметри можуть слідувати в довільному порядку.
Приклад: частина 2 3-х приватного послання має наступні варіанти заголовка:
Але частина 3 обов'язково повинна містити параметр "total":
Необхідно зауважити, що нумірація частин починається з 1, а не з 0.
Коли подібним чином розбиті частини збираються разом, вони утворюють повне MIME-лист, вміст якого може мати будь-який інший тип і, відповідно, своє поле заголовка Content-Type, що описує цей тип.
Семантика partial-листи повинна бути та ж, як в звичайному листі з вмістом даного типу, а не як в листі, що містить "внутрішнє" лист. Це дозволяє, наприклад, переслати великий аудіо-файл у вигляді кількох дрібніших, що залишаються, проте, видимими одержувачу як звичайні аудіо-листи, а не як вкладені аудіо-листи.
При "збірці" таких послань в пункті призначення повинні враховуватися наступні правила:
(1) Усі поля заголовка частини 1, крім починаються з "Content-" і спеціальних "Message-ID", "Encrypted" і "MIME-Version" повинні бути скопійовані в заголовок нового (загального) листи.
(2) Тільки поля заголовка вкладення листа, що починаються з "Content-", а також поля "Message-ID", "Encrypted" і "MIME-Version", повинні бути додані до заголовку нового спільного листа, всі інші поля повинні ігноруватися.
(3) Заголовки другої і наступних частин цілком ігноруються.
Наприклад, якщо лист з аудіо-даними було розбите на дві частини, перша з них може виглядати наступним чином:
А друга може виглядати так:
Після того, як розколоте послання відтворено заново для відображення одержувачу, воно має виглядати наступним чином:
Зауваження з кодування тіла MIME-листи, укладеного всередині тіла message / partial: так як дані типу "message" ніколи не можуть бути кодовані в Base64 або Quoted-Printable, наступна проблема може виникнути в разі, якщо тіла листів типу message / partial створені в системі, яка підтримує 8-бітний транспорт. Двійкові дані будуть розбиті на декілька message / partial-об'єктів, кожному з яких потрібно транспортування в двійковому вигляді. Якби таких об'єктів довелося пройти через шлюз в 7-бітну транспортну середу, їх неможливо було б перекодувати в сеімбітную форму без очікування прибуття всіх частин послання, збирання їх воєдино і потім кодування цілого послання в 7-бітну систему кодування (base64 або quoted-printable) . Поскльку існує ймовірність, що різні частини підуть різними шляхами (через різні шлюзи), то подібне рішення не типово. Тому MIME визначає, що листи типу message / partial повинні мати 7-бітну систему кодування і відповідне їй значення поля content-transfer-encoding. Навіть для систем з транспортом, що підтримує "8-біт" і "binary", забороняється їх використання для даних message / partial.
Багато поштові агенти можуть автоматично фрагментировать великі листи.
Включення поля "References" в заголовки другої і наступних частин, що посилається на ідентифікатор попередній частині, може виявитися корисним для поштових програм, які розуміють і обробних посилання. Однак, наявність цього поля не обов'язково.
Поле заголовка "Encrypted" вийшло з ужитку, але вищенаведені правила забезпечують коректну його інтерпретацію, якщо воно зустрічається при обробці фрагментів типу message / partial.
Підтип 'Message / External-Body'
Лист (частина листа) цього підтипу складається з заголовка, двох послідовних решт рядки і заголовка вкладеного листи. Якщо зустрічається інша пара кінців рядка, вона означає кінець заголовка вкладеного листи. Однак, оскільки тіло вкладеного листи є зовнішнім, воно не слід за кінцем заголовка. наприклад,
Область в кінці, яку можна назвати "примарним тілом", ігнорується для більшості листів підтипу 'external-body'. Однак, в неї можна поміщати додаткову інформацію, як наприклад, в разі, коли параметр 'access-type' дорівнює "mail-server". У всіх інших випадках примарне тіло ігнорується.
Єдиний завжди обов'язковий параметр для 'message / external-body' - "access-type". Інші параметри можуть бути чи не бути обов'язковими в залежності від значення параметра "access-type".
Значення цього параметра - слово, нечувствительное до регістру букв, що означає механізм доступу, за допомогою якого файл або дані можуть бути отримані. Значення можуть бути наступними (але не обмежуються цим поруч): "FTP", "ANON-FTP", "TFTP", "AFS", "LOCAL-FILE" та "MAIL-SERVER". Майбутні можливі значення, крім експериментальних, що починаються з "X-", повинні бути зареєстровані в IANA.
Додатково, наступні три параметри є необов'язковими для всіх способів доступу:
EXPIRATION - Дата (RFC 822 "date-time" синтаксис допускає 4 цифри в цьому полі), після якої існування зовнішніх даних не гарантується.
SIZE - розмір (в байтах) даних. Дозволяє одержувачеві вирішити, витрачати чи ресурси на зчитування зовнішніх даних. Розмір вказується для канонічної форми даних (тобто, до застосування будь-яких перетворень).
PERMISSION - нечувствительное до регістру букв поле, яке говорить про те, очікується чи ні, що клієнт може перезаписувати дані. За замовчуванням або коли цей параметр має значення "read", потрібно було, що клієнт не має на це права, і що якщо дані одного разу лічені, то більше вони не знадобляться. Якщо PERMISSION має значення "read-write", будь-яка локальна копія може розглядатися лише як кеш. "Read" і "write" - єдині зумовлені значення для PERMISSION.
Вкладені заголовки у ВСІХ тілах типу message / external-body ПОВИННІ включати поле заголовка Content-ID для завдання унікального ідентифікатора, що вказує на зовнішні дані.
Позначення, що описують дані типу external-body, такі як імена файлів або команди mail-сервера, повинні бути в символьному наборі US-ASCII.
Як і для типу message / partial, тіло типу message / external-body має мати значення content-transfer-encoding "7-bit" (за замовчуванням). Зокрема, навіть в системах, поддержіавющіх 8-бітний транспорт, застосування content-transfer-encoding "8-bit" і "binary" заборонено для даних типу message / external-body.
Типи доступу "ftp" і "tftp"
Тип доступу по FTP або TFTP означає, що тіло повідомлення є як зовнішній файл по протоколу FTP [RFC-959] або TFTP [RFC-783] відповідно. Для цих типів доступу обов'язкові такі додаткові параметри:
NAME - Ім'я файлу, що містить дані тіла листи.
Перед тим, як почнеться зчитування даних по FTP, користувач зазвичай має бути запитаний на предмет логіна і пароля для машини, зазначеної в секції "Тайм site '. З причин безпеки логін і пароль не вказуються як параметри Content-Type і повинні бути отримані від одержувача листа.
Додатково визначені наступні необов'язкові параметри:
DIRECTORY - каталог, що містить тіло листа на віддаленій машині.
MODE - нечутливість до регістру букв рядок, яка вказує режим передачі даних. Допустимі еначенія для типу доступу TFTP:
NETASCII, OCTET і MAIL. Для типу доступу FTP: ASCII, EBCDIC, IMAGE і LOCALn, де n - десяткове ціле число, зазвичай 8. Ці значення відповідають типам уявлення A, E, I і Ln. певним FTP-протоколом. Зауважте, що "BINARY" і "TENEX" не є допустимими значеннями для параметра MODE. Замість них повинні використовуватися "OCTET", "IMAGE" або "LOCAL8". Якщо параметр MODE відсутня, значенням за замовчуванням є "NETASCII" для TFTP і "ASCII" для FTP.
Спосіб досуп "anon-ftp"
Способи доступу "local-file" і "afs"
Спосіб доступу "local-file" означає, що тіло листа є як файл на локальній машині. "Afs" означає, що тіло є як файл через загальну файлову систему AFS. В обох випадках потрібно єдиний обов'язковий параметр:
NAME - Ім'я файлу, що містить дані тіла листи.
Спосіб доступу "mail-server"
Застосовується, коли тіло листа доступно через поштовий сервер. Обов'язковий параметр для цього способу доступу:
Так як поштові сервери припускають безліч різних синтаксисів, деякі з них можуть бути багаторядковими, повна команда, яку потрібно послати на mail-сервер, не включається як параметр в однорядкове поле 'content-type'. Замість цього вона поміщається в уявне тіло, коли значенням поля 'content-type' є 'message / external-body', і параметр 'access-tyoe' має значення 'mail-server'.
Необов'язковий параметр для цього способу доступу:
MIME-стандарт не визначає синтаксису звернення до поштового сервера. Тому він допускає включення повної команди для mail-сервера в уявне тіло.
На відміну від інших способів доступу, доступ через mail-сервер не синхронний, і дані можуть бути отримані в непередбачуваний момент в майбутньому. З цієї причини важливо мати механізм, що забезпечує вставку отриманих від mail-сервера даних в початковий лист. Mail-сервер при відправці запитаних даних повинен використовувати те ж саме значення поля Content-ID в заголовку листа з повертаються даними, яке було в первісному "безтілесному" листі, щоб полегшити роботу цього механізму.
Приклади і додаткові пояснення
Якщо зовнішнє тіла листи є за допомогою декількох різних механізмів, відправник може включити кілька частин типу message / external-body в лист типу multipart / alternative.
Заголовки загального і вкладеного (їх) листів (мають зовнішнє тіло) повинні задовольняти тим же правилам, що і для типу message / partial щоб уникнути плутанини.
Оскільки зовнішнє тіло не пересилається у вигляді пошти, то вона не зобов'язана задовольняти вимогам довжини рядків і мати 7-бітну форму, воно може бути просто бінарним файлом. Тому поле Content-Transfer-Encoding не є необхідним, хоча його наявність допускається.
Тіло листа типу "message / external-body" обробляється у відповідності з основним синтаксисом стандарту RFC 822, зокрема, все, що йде до першої послідовної пари решт рядки (CRLF), є заголовком листи, а все, що йде після, є " уявним "тілом листа, який ігнорується для більшості типів доступу.
Формальний синтаксис поля заголовка 'content-type' для даних типу 'message' - наступний: