Это заголовок документа

 ­ Это параграф.          Это пример гипертекстовой ссылки.           Это встроенный image.          Это "якорь" внутри текста документа. "Multipart". Этот тип содержания тела почтового сообщения определяет смешанный  документ. Смешанный документ может состоять из фрагментов данных разного типа.  Данный тип имеет ряд подтипов. Подтип "mixed" ­ задает сообщение, состоящее из нескольких фрагментов, которые  разделены между собой границей, задаваемой в качестве параметра подтипа. Приведем  простой пример: From: Nathaniel Borenstein          To: Ned Freed          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 readers.         ­­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  To: Ned Freed  Subject: Formatted text mail         MIME­Version: 1.0 Content­Type: multipart/alternative; boundary=boundary42 ­­boundary42 1 фрагмент Content­Type: text/plain; charset=us­ascii...plain text version of message goes here.... ­­boundary42 2 фрагмент         Content­Type: text/richtext         .... richtext version of same message goes here ...         ­­boundary42 3 фрагмент         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 mailMIME­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", который позволяет ссылаться на внешние,  относительно сообщения, информационные источники. Этот подтип похож на  гипертекстовую ссылку из типа "text".Приведем конкретный пример: 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". Данный подтип определяет  сообщения стандарта RFC822. Типы описания нетекстовой информации. Таких типов имеется четыре:  "image" для описания графических образов. Наиболее часто используются файлы  форматов GIF и JPEG. "audio" для описания аудио информации. Для воспроизведения сообщения данного типа требуется специальное оборудование.  "video" для передачи фильмов. Наиболее популярным является формат MPEG.  "application" для передачи данных любого другого формата, обычно используется  для передачи двоичных данных для последующего промежуточного  преобразования. Так если на машине стоит видео­карта с 512Kb памяти, а графика  подготовлена в 256 цветах, то сначала ее следует преобразовать и здесь может  помочь тип "application". Основной подтип данного типа ­ "octet­stream", но  существуют "ODA" и "Postscript". Назначение данных типов ясно из названия ­ обозначение данных для последующей  обработки как данных в форматах, определяемых подтипом. Поле типа кодирования почтового сообщения (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", "BINARY" реально никакого преобразования не требуют, так как почта передается байтами и SMTP не делает различия между ними. Однако они введены для строгости  описания типов. "BASE64" обычно используется в связке с типом "text/ISO­8859­1", "x­ token" позволяет пользователю описать свою процедуру преобразования. Дополнительные необязательные поля. Как уже говорилось ранее, стандарт определяет еще два дополнительных поля: "Content­ID" и "Content­Description". Первое поле  определяет уникальный идентификатор содержания, а второе служит для комментария  содержания. Ни то, ни другое программами просмотра обычно не отображаются. В заключении обсуждения стандарта MIME комплексный пример без комментариев:MIME­Version: 1.0 From: Nathaniel Borenstein  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 implicittyping 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/richtextThis is richtext. Isn't it cool? ­­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 позволяет  расширить область применения электронной почты, обеспечить доступ к другим  информационным ресурсам сети в стандартных форматах. Программное обеспечение почтового обмена Согласно схеме почтового обмена (рисунок 2.1) взаимодействие между участниками  этого обмена строится по классической схеме "клиент­сервер". При этом схему можно  подразделить на несколько этапов. Первый ­ взаимодействие по протоколу SMTP между  почтовым клиентом (Internet Mail, Netscape Messager, Eudora и т.п.) и почтовым  транспортным агентом (sendmail, smail, ntmail и т.п.), второй ­ взаимодействие между  транспортными агентами в процессе доставки почты получателю, результатом которого  является доставка почтового сообщения в почтовый ящик пользователя и третий ­  выборка сообщения из почтового ящика пользователя почтовым клиентом в почтовый  ящик пользователя на машине пользователя по протоколу POP3 или IMAP. Программа SendmailОсновным средством рассылки почты в Internet является программа sendmail. Она  обеспечивает работу модульной системы рассылки, которая предназначена для получения и отправки корреспонденции, а также управления программами подготовки и просмотра  почтовых сообщений. Sendmail позволяет организовать почтовую службу локальной сети  и обмениваться почтой с другими серверами почтовых служб через специальные шлюзы.  Sendmail может быть сконфигурирована для работы с различными почтовыми  протоколами. Обычно это протоколы UUCP (Unix­Unix­CoPy) и SMTP (Simple Mail  Transfer Protocol). Sendmail работает как "отделение связи" обычной почтовой службы, которое принимает и пересылает почтовые сообщения. Sendmail может интерпретировать два типа почтовых  адресов:  почтовые адреса SMTP;  почтовые адреса UUCP. Первые являются стандартными адресами Internet и, фактически, являются стандартом  де­факто. Именно этот адрес обычно указан на визитных карточках. Sendmail можно настроить для поддержки:  списка адресов­синонимов;  списка адресов рассылки пользователя;  автоматической рассылки почты через шлюзы;  очередей сообщений для повторной рассылки почты в случае отказов при рассылке;  работы в качестве SMTP­сервера;  доступа к адресам машин через сервер доменных имен BIND;  доступа к внешним серверам имен. Принцип работы программы sendmail Sendmail отправляет почту в два приема: сначала почтовые сообщения собираются в  очереди, а затем отсылаются. Каждое сообщение состоит из трех частей: конверта, заголовка и тела сообщения.Конверт. Конверт состоит из адреса отправителя, адреса получателя и информации  рассылки, которая используется программами подготовки, рассылки и получения почты.  Конверт остается невидимым для отправителя и получателя почтового сообщения. Заголовок. Заголовок состоит из стандартных текстовых строк, которые содержат  адреса, информацию о рассылке и данные. Заголовок может быть частью подготовленного пользователем текстового файла, а может быть подготовлен и добавлен к телу сообщения программой подготовки почты. Данные из заголовка могут быть использованы для  оформления конверта сообщения. Тело сообщения. Первая пустая строка в файле почтового сообщения отделяет заголовок от тела сообщения. Все, что следует после этой строки, называется телом сообщения и  передается по почте без изменений. Sendmail может быть вызвана:  программой подготовки сообщений для отправки уже подготовленных сообщений;  программой получения почты для пересылки полученной из сети почты;  непосредственно пользователем для отправки по почте файла или короткого  сообщения;  почтовым демоном, которым обычно является сама sendmail. После того, как почта собрана, начинается ее рассылка. При этом выполняются  следующие действия:  адреса отправителя и получателя преобразуются в формат сети­получателя почты;  если необходимо, то в заголовок сообщения добавляются строки, позволяющие  получателю отвечать на принятое сообщение (например: FROM: <адрес>);  почта передается одной из программ рассылки почты. На рисунке 3.1 представлена схема функционирования почтового сервера на базе  программы sendmail. Когда программа приема почты получает сообщение, она передает его программе  sendmail для последующей рассылки. Если сообщение достигло машины адресата, то оно  отправляется программой местной рассылки в почтовый ящик пользователя. Первый этап рассылки ­ сбор сообщений. Sendmail получает почтовые сообщения из  трех источников: командной строки или стандартного ввода;  через SMTP­протокол (из сети);  из очереди сообщений. При получении сообщений из командной строки или стандартного ввода, sendmail  вызывается пользователем с указанием адреса доставки сообщения. При этом  выполняются следующие действия: определяется адрес отправителя, выбирается из  командной строки адрес получателя и оба адреса преобразуются в соответствии с  описанием файла конфигурации, определяется способ доставки сообщения, размещается  заголовок в оперативной памяти для последующих преобразований, а тело сообщения  размещается во временном файле для отправки без изменений. При получении сообщений по протоколу SMTP, sendmail используется как программа  клиента и сервера протокола. Протокол определен в RFC­821 и является основным для  рассылки почты в Internet. В этом случае sendmail запускается как демон, который  "слушает" порт TCP и в случае получения сообщения устанавливает соединение с  удаленным клиентом SMTP. Как правило, таким клиентом является другая программа  sendmail. Программа подготовки почты на локальной машине также может использовать SMTP.  Для этого sendmail открывает канал (pipe) межпроцессного обмена. При получении сообщений из очереди используются временные файлы очередей. Эти  очереди используются для хранения неразосланных сообщений. Сообщение хранится в  двух файлах. В одном файле хранится тело сообщения, а в другом конверт и заголовок  сообщения. Обычно sendmail опрашивает очереди через определенные администратором  почтового сервера промежутки времени, на предмет наличия в них неразосланных  сообщений.Рис. 3.1. Схема почтового взаимодействия на базе программы Sendmail Вторая стадия рассылки почты ­ рассылка сообщений. Как только одним из описанных выше способов sendmail получила сообщение, делается  попытка его отправить по адресу. Для этого sendmail определяет три параметра:  программу рассылки, узел сети и получателя. Эта процедура производится по правилам,  которые содержатся в файле конфигурации. Sendmail сохраняет одну копию тела  сообщения во временном файле, а заголовок загружает в оперативную память. Длякаждого сообщения программа доставки (рассылки) сообщений вызывается отдельно.  Если сообщение должно быть доставлено на разные машины, то для каждой из машин  также вызывается своя программа доставки. Некоторые программы могут обслуживать  сразу несколько абонентов одной машины, если это невозможно, то для каждого абонента  вызывается также своя программа доставки. Рассматривают два типа рассылки: на  удаленную машину и местную рассылку. Рассылка на удаленную машину. Для вызова программы рассылки sendmail открывает  pipe и запускает программу рассылки, командная строка которой находится в файле  конфигурации. Sendmail записывает заголовок и тело сообщения в pipe. Если программа  рассылки не использует протокол SMTP, то адрес получателя передается через pipe. Если используется SMTP, то открывается двунаправленный канал для интерактивного  взаимодействия с удаленным сервером SMTP. Если в качестве транспортного протокола  используется TCP, то sendmail не запускает внешнюю программу рассылки, а сама  инициирует TCP­соединение с удаленным сервером SMTP. Доставка местной почты. Если sendmail определяет, что адреса доставки местные, то  происходит обращение к файлу адресных синонимов и производится преобразование  адресов (расширение). Файл адресных синонимов можно использовать для  перенаправления почты в файлы или для обработки местными программами.  Пользователь может иметь и свой собственный файл адресных синонимов для управления рассылкой персональной почты. После преобразования адресов почта отправляется  программе местной рассылки (например rmail). Важным моментом при работе sendmail является алгоритм определения типа адресов.  При использовании стандартного файла конфигурации применяются следующие правила:  почта рассылается в соответствии с форматом адреса получателя, адреса при этом  бывают местные, UUCP и SMTP. Местные адреса имеют вид: user user@localhost user@localhost.localdomain user@alias user@alias.localdomain user@[local.host.internet.address]localhost!user localhost!localhost!user user@localhost.uucp Местный адрес ­ это адрес, который распознается как адрес машины, с которой  осуществляется отправка почты. Адреса UUCP имеют вид: host!user host!host!user user@host.uucp Если машина, с которой отправляется почта, имеет прямую линию связи по протоколу  UUCP со следующей машиной (в адресе), то почта передается на эту машину, если такого  соединения нет, то почта не рассылается и выдается сообщение об ошибке. Файл  конфигурации должен содержать детальное описание маршрутов для пересылки  сообщений на машины по протоколу UUCP. Адреса SMTP ­ это адреса, описанные в стандарте RFC­822 или стандартные адреса  Internet. Эти адреса имеют вид: usr@host usr@host.domain <@host1,@host2,@host3:user@host4> user@[remote.host`s.internet.address] Почта с адресами SMTP рассылается по протоколу SMTP. Если в системе для адресации используется Berkeley Internet Name Domain (BIND) сервер, то sendmail может определять адреса получателей, используя сервис BIND. Если BIND не используется, то sendmail сама определяет адреса. При рассылке почты можно использовать и смешанную адресацию: user%hostA@hostB ­ почта отправляется с машины hostB на машину hostA user!hostA@hostB ­ почта отправляется с машины hostB на машину hostAhostA!user%hostB ­ почта отправляется с hostA на hostB Подводя итог обсуждению принципов работы sendmail, следует специально подчеркнуть  тот факт, что почта реально рассылается двумя принципиально разными способами. При  использовании протокола UUCP почта рассылается по принципу "stop­go", т.е. сообщения передаются от машины к машине по указанному в адресе пути. Следует ясно  представлять, если почта ушла с машины отправителя, то это не означает, что она  поступит получателю. Промежуточная машина может вернуть почту назад, если не  сможет разослать. Электронная почта действительно работает как система обычной  почты, физически перемещая и храня сообщения на промежуточных почтовых станциях.  При работе по протоколу SMTP почта реально отправляется только тогда, когда  установлено интерактивное соединение с программой­сервером на машине­получателе  почты. При этом происходит обмен командами между клиентом и сервером протокола  SMTP в режиме on­line. При смешанной адресации доставка почты происходит по  смешанному сценарию. Как шла доставка и как маршрутизировалось сообщение можно  определить из заголовка сообщения, которое вы получили. Анализ типа адресов в программе sendmail ­ это самый главный процесс, т.к. по типу  адреса получателя sendmail определяет каким способом сообщение будет разослано.  Вызов программы доставки вмонтирован в правила преобразования адресов отправителя и получателя. При этом как только система решит, что дальнейшее преобразование адреса  нецелесообразно, так сразу вызывается программа доставки. Наибольшее число  сообщений об ошибках при рассылке сообщений связано как раз с определением адреса  получателя. В этом процессе принимают участие, по крайней мере, два сервиса Internet:  система рассылки почтовых сообщений и служба доменных имен. Sendmail постоянно  обращается к службе доменных имен на предмет канонизации имен электронной почты  сверяет эти имена с теми, которые закреплены за компьютером, на котором данная  система установлена. Если имена совпадают, то осуществляется местная рассылка по  адресам местной почты.