Типы доступа "ftp" и "tftp" Тип доступа по FTP или TFTP означает, что тело сообщения доступно как внешний файл по протоколу FTP [RFC-959] или TFTP [RFC-783] соответственно. Для этих типов доступа обязательны следующие дополнительные параметры:
NAME -- Имя файла, содержащего данные тела письма.
SITE -- Полный доменный адрес или псевдоним компьютера, с которого файл может быть получен по указанному протоколу.
Перед тем, как начнется считывание данных по 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" Этот способ доступа идентичен "ftp", за исключением того, что пользователю не требуется указывать свой логин и пароль для удаленной машины. FTP-протокол будет использоваться с логином "anonymous" и email-адресом получателя вместо пароля.
Способы доступа "local-file" и "afs" Способ доступа "local-file" означает, что тело письма доступно как файл на локальной машине. "afs" означает, что тело доступно как файл через общую файловую систему AFS. В обоих случаях требуется единственный обязательный параметр:
NAME -- Имя файла, содержащего данные тела письма.
Следующий необязательный параметр может быть использован для локализации ссылки на файл и содержит адрес сайта или сайтов, на которых данный файл виден:
SITE -- Доменный адрес машины или машин, на которых возможен доступ к файлу данных. Допускаются маски с использованием звездочки вместо части доменного имени, например, "*.bellcore.com", для обозначения набора машин, на которых файл виден напрямую. Единственная звездочка вместо всего доменного имени может означать, что файл, где би он ни был, виден через глобальную файловую систему.
Способ доступа "mail-server" Применяется, когда тело письма доступно через почтовый сервер. Обязательный параметр для этого способа доступа:
SERVER -- email-адрес mail-сервера, с которого могут быть запрошены данные тела письма.
Так как почтовые серверы предполагают множество различных синтаксисов, некоторые из них могут быть многострочными, полная команда, которую нужно послать на mail-сервер, не включается как параметр в однострочное поле 'content-type'. Вместо этого она помещается в мнимое тело, когда значением поля 'content-type' является 'message/external-body', и параметр 'access-tyoe' имеет значение 'mail-server'.
Необязательный параметр для этого способа доступа:
SUBJECT -- Subject, который будет использован в заголовке письма-запроса, которое почторый клиент получателя пошлет на указанный почтовый сервер для получения данных тела письма. Заметьте, что помещение адреса сервера в subject не рекомендуется, однако, известны mail-серверы, требующие этого.
MIME-стандарт не определяет синтаксиса обращения к почтовому серверу. Поэтому он допускает включение полной команды для mail-сервера в мнимое тело.
В отличие от других способов доступа, доступ через mail-сервер не синхронен, и данные могут быть получены в непредсказуемый момент в будущем. По этой причине важно иметь механизм, обеспечивающий вставку полученных от mail-сервера данных в исходное письмо. Mail-сервер при отправке запрошенных данных должен использовать то же самое значение поля Content-ID в заголовке письма с возвращаемыми данными, какое было в первоначальном "бестелесном" письме, чтобы облегчить работу этого механизма.
Стандартным подтипом типа "message" является "rfc822".Этот подтип указывает, что тело письма содержит вложенное письмо в стандарте RFC 822, однако, в отличие от заголовка RFC 822 верхнего уровня, для каждой части, являющейся письмом RFC 822, не требуется наличия полей "From", "Subject" и, по крайней мере, одного поля "To".
Не смотря на использование числа "822", тело, имеющее подтип 'message/rfc822', может включать дополнительную информацию в соответствии со стандартом MIME. Другими словами, письмо 'message/rfc822' может быть MIME-письмом.
В заключение опишем формальный синтаксис поля заголовка 'content-type' для данных типа 'message'
message_тип := "message" "/" message_подтип
message_подтип := "rfc822"
/ "partial" 2-3 partial_параметра
/ "external-body" 1 external_параметр
/ расширение (не предопределенный подтип)
partial_параметр := (";" "id" "=" значение)
/ (";" "number" "=" 1*ЦИФРА)
/ (";" "total" "=" 1*ЦИФРА)
; id и number требуются всегда; total требуется для последнего фрагмен-
; та послания.
external_параметр := (";" "access-type" "=" тип_доступа)
/ (";" "expiration" "=" дата-время)
; Дата-время должны быть экранированы кавычками
/ (";" "size" "=" 1*Цифра)
/ (";" "permission" "=" ("read" / "read-write"))
; Значение permission нечувствительно к регистру букв
/ (";" "name" "=" значение)
/ (";" "site" "=" значение)
/ (";" "dir" "=" значение)
/ (";" "mode" "=" значение)
/ (";" "server" "=" значение)
/ (";" "subject" "=" значение)
; access-type требуется всегда; все остальное - в зависимости от значе-
; ния access-type
тип_доступа := "ftp" / "anon-ftp" / "tftp" / "local-file"
/ "afs" / "mail-server" /
/ расширение (непредопределенный параметр)
; Нечувствителен к регистру букв
Типы описания нетекстовой информации.
Таких типов имеется четыре:
Назначение данных типов ясно из названия - обозначение данных для последующей обработки как данных в форматах, определяемых подтипом.
Тип "Application"
Этот тип используется для данных, неподпадающих под
остальные категории, в частности, для данных, обрабатываемых прикладными
почтовыми программами. Это информация, которая должна быть обработана
соответствующим приложением для того, чтобы принять наглядную либо
исполняемую для получателя форму. Предполагаемое использование для этого
типа включает в себя пересылку файлов по почте, таблицы, данные для
почтовых систем расписания, языки лдя "активной" (вычислительной) почты.
(Последняя, в частности, может поднять проблемы безопасности, которые
должны быть поняты разработчиками ПО и рассмотрены ниже в параграфе
"Application/PostScript").
Например, тот, кто занимается расписанием встреч, может определить стандартное представление информации о датах запланированных встреч. "Умный" пользовательский почтовый агент может использовать эту информацию для проведения диалога с пользователем, и может затем посылать в дальнейшем почту, основанную на том диалоге. Вообще, существует несколько "активных" почтовых языков, разработанных для специализированных программ, которые посылаются по почте и автоматчески запускаются в системе получателя.
Подобные приложения могут быть определены как подтипы для типа "application". Изначально предопределено два подтипа: "octet-stream" и "PostScript".
В общем, подтип для 'application' зачастую может быть именем приложения, для которого предназначены пересылаемые данные. Однако, это не означает, что любое имя прикладной программы может свободно использоваться как подтип для 'application'. Такие употребления (кроме подтипов, начинающихся с "x-") должны быть зарегестрированы в IANA.
Основной подтип 'Application/Octet-Stream'
Используется для обозначения того, что тело содержит бинарные данные. Набор возможных параметров включает следующие (но не ограничивается ими):
TYPE -- обобщенный тип или категория двоичных данных, эта информация больше предназначена для получателя, чем для автоматической обработки.
PADDING -- число заполняющих битов, добавленных к битовому потоку, содержащему данные, для формирования байтно-ориентированных данных. Полезно при заключении в тело битового потока, когда общее число битов не кратно восьми, то есть, размеру байта.
Дополнительный параметр, "conversions", определенный в [RFC-1341], был исключен в последствии.
В RFC 1341 также определен параметр "NAME", указывающего имя файла, которое должно быть использовано при сохранении данных на диск. Но он опять же был отменен в ожидании введения отдельного поля заголовка Content-Disposition, которое будет определено в ближайшем будущем.
Рекомендуемое действие для почтовой программы, получившей почту типа application/octet-stream, - просто предложить записать данные в файл без какого-либо преобразования, или. возможно, произвести его в соответствии с указанием пользователя.
Для уменьшения опасности передачи вирусных и других намеренно разрушающих систему программ по почте, строго рекомендуется, чтобы почтовая программа получателя не производила запуск программы, заданной в параметре поля "Content-Type" (например, в параметре "interpreter="), использующей в качестве входных данных тело письма.
Подтип "Aplication/PostScript" Тип "application/postscript" означает, что пересылается PostScript-документ и требует специальной программы для его обработки. В настоящий момент используются два языка - level 1 и более поздний - level 2.
PostScript-документы представляют собой интерпретируемые программы, которые могут содержать операторы обращения к диску и действий с файлами. Поэтому PostScript-документы представляют потенциальную опасность для системы получателя.
В некоторых интерпретаторах PostScript могут иметь место ошибки, которые могут быть использованы хакерами для несанкционированного доступа к системе получателя, и нельзя предложить какого-либо специфического действия для предотвращения подобной возможности, кроме исправления со временем подобных ошибок (если они, конечно, есть) производителями соответствующего ПО.
Другие подтипы типа Application Ожидается, что многие подтипы типа 'Application' будут введены в будущем. MIME-совместимые почтовые программы должны интерпретировать любой незнакомый им подтип как эквивалент 'application/octet-stream'.
Формальный синтаксис дла поля 'content-type' для данных типа 'application' дается следующим образом.
application_тип := "application" "/" application_подтип
application_подтип := ("octet-stream" *stream_параметр)
/ "postscript" / расширение (непредопределенный под-
тип)
stream_параметр := (";" "type" "=" значение)
/ (";" "padding" "=" число_дополняющих_битов)
число_дополняющих_битов := "0" / "1" / "2" / "3" / "4" / "5" / "6" /
/ "7"
Тип 'Image'
Этот тип означает, что тело письма содержит графический
объект. Его подтипы соответствуют конкретным графическим форматам. Их
значения нечувствительны к регистру букв. Два предопределенных подтипа -
"jpeg" для формата JPEG с кодированием JFIF, и "gif" - для формата GIF.
Формальный синтаксис поля 'Content-Type':
image_тип := "image" "/" ("gif" / "jpeg" / подтип-расширение)
Тип 'Audio'
Этот подтип означает, что тело содержит аудио-данные. Хотя пока еще нет
консенсуса по "идеальному" аудио-формату для компьютеров, сейчас имеется
сильная потребность в универсальном формате.
Предопределенный подтип - "basic" введен в ответ на это требование, обеспечивая минимальный примитивный аудио-формат. Ожидается определение в дальнейшем более "богатых" форматов, обеспечивающих более высокое качество воспроизведения.
Содержимое тела, имеющего подтип "audio/basic", - аудио-данные в 8-битной форме, кодированные с использованием ISDN mu-law. Формат, соответствующий этому подтипу, предполагает максимальную частоту звучания 8000 Hz и единственный канал.
Формальный синтаксис лдя поля 'Content-Type':
audio_тип := "audio" "/" ("basic" / подтип-расширение)
Тип 'Video'
Этот тип означает, что в теле письма содержится
анимационное изображение, возможно, со звуком и цветом. Термин "video"
используется безотносительно к технологии получения подвижного во времени
изображения. Подтип "mpeg" указывает на видео, кодированное в соответствии
со стандартом MPEG.
Хотя MIME-стандарт запрещает смешение разнородных мультимедийных данных в одном теле (письма или части письма), многие так называемые "video"-форматы включают синхронизированный звук, что допускается для подтипов типа "video".
Формальный синтаксис лдя поля 'Content-Type':
video-type := "video" "/" ("mpeg" / подтип-расширение)
Экспериментальные значения поля 'Content-Type'
Значение типа, начинающееся с "X-", считается частным,
предназначенным для использования по договоренности между двумя или более
почтовыми системами. Публично определенные (регестрированные) значения
никогда не должны начинаться с префикса "X-".
В общем, использование X-типов верхнего уровня не рекомендуется. Производители почтового ПО должны по возможности обходиться использованием X-подтипов для предопределенных типов. Во многих случаях использование экспериментального подтипа более приемлимо, нежели типа верхнего уровня.
| ТИП | ПОДТИП |
|---|---|
| text | plain |
| richtext | |
| enriched | |
| tab-separated-values | |
| multipart | mixed |
| alternative | |
| digest | |
| parallel | |
| appledouble | |
| header-set | |
| message | rfc822 |
| partial | |
| external-body | |
| news | |
| application | octet-stream |
| postscript | |
| oda | |
| atomicmail | |
| andrew-inset | |
| slate | |
| wita | |
| dec-dx | |
| dca-rft | |
| activemessage | |
| rtf | |
| applefile | |
| mac-binhex40 | |
| news-message-id | |
| news-transmission | |
| wordperfect5.1 | |
| zip | |
| macwriteii | |
| msword | |
| remote-printing | |
| image | jpeg |
| gif | |
| ief | |
| tiff | |
| audio | basic |
| video | mpeg |
| quicktime |
Значения полей Content-Type и subtype, а также другие параметры заголовка являются чувствительными к регистру букв, если только не оговорены исключения для конкретного значения параметра.
Дополнительные необязательные поля.
Стандарт определяет еще два дополнительных поля: "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 that understands 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 позволяет расширить область применения электронной почты, обеспечить доступ к другим информационным ресурсам сети в стандартных форматах.
