|
глава 28 smtp: простой протокол передачи почты электронная почта (e-mail), несомненно, одно из самых популярных приложений. [caceres et al. 1991] показывает, что примерно половина всех tcp соединений занята передачей почтовых сообщений с исполььзованием простого протокола передачи почты (smtp - simple mail transfer protocol). (с точки зрения количества переданных байт, по ftp соединениям передается значительно больше данных.) [paxson 1993] обнаружил, что среднее почтовое сообщение содержит примерно 1500 байт данных, однако некоторые сообщения содержат мегабайты данных, потому что электронная почта иногда используется для посылки файлов. на рисунке 28.1 показан обмен почтой с использованием tcp/ip.
рисунок 28.1 доставка электронной почты в internet.
пользователи общаются с пользовательскими агентами (user agent). в настоящее время существует очень много реализаций пользовательских агентов. популярные пользовательские агенты для unix это mh, berkeley mail, elm и mush. обмен почтой с использованием tcp осуществляется посредством агентов передачи сообщений (mta - message transfer agent). наиболее распространенные mta для unix систем это sendmail. пользователи обычно не общаются с mta. в задачу системного администратора входит установка локального mta. в этой главе рассматривается обмен электронной почтой между двумя mta с использованием tcp. мы не будем рассматривать функционирование или принципы работы пользовательских агентов. rfc 821 [postel 1982] описывает протокол smtp. а именно то, как два mta общаются друг с другом по tcp соединению. rfc 822 [crocker 1982] приводит формат сообщения электронной почты, которое передается между двумя mta в соответствии с rfc 821. при общении между двумя mta используется nvt ascii. команды посылаются клиентом серверу, а сервер отвечает с помощью цифровых кодов и опциональных текстовых строк (для чтения человеком). это несколько напоминает сценарий, который мы видели для ftp в предыдущей главе. клиент может послать серверу небольшое количество команд: меньше дюжины. (для сравнения, ftp имеет более сорока команд.) вместо того чтобы описывать команды одну за другой, мы начнем с простого примера, для того чтобы показать что происходит, когда отправляется почта. пошлем простое сообщение размером в одну строку и посмотрим, как осуществляется smtp соединение. для этого воспользуемся нашим пользовательским агентом с флагом -v, который передается транспортному агенту почты (sendmail в данном случае). когда указан этот флаг, mta отображает все, что посылается и принимается по smtp соединению. строки, начинающиеся с >>>, это команды, посылаемые smtp клиентом, а строки, начинающиеся с 3-циферного кода отклика, приходят от smtp сервера. ниже приводится интерактивная сессия:
для отправки почты было использовано всего пять smtp команд: helo, mail, rcpt, data и quit. команда mail запускает пользовательского агента. затем необходимо ввести тему сообщения, после чего можно печатать тело сообщения. ввод точки в начале строки завершает сообщение, и пользовательский агент передает почту в mta для доставки. клиент осуществляет активное открытие на tcp порт 25, после чего ожидает приветственного сообщения (отклик с кодом 220) от сервера. ответ сервера должен начинаться с полного имени домена хоста сервера: noao.edu в данном примере. (обычно вместе с цифровым кодом отклика возвращается необязательный текст. здесь требуется имя домена.) затем клиент идентифицирует себя с использованием команды helo. в качестве аргумента указывается полное имя домена хоста клиента: sun.tuc.noao.edu. команда mail идентифицирует автора сообщения (или отправителя). следующая команда, rcpt, идентифицирует получателя. если сообщение предназначено нескольким получателям, может быть исполнено несколько команд rcpt. клиент отправляет содержимое почтового сообщения с использованием команды data. строка, содержащая только точку, указывает на конец сообщения. последняя команда, quit, прекращает обмен почтой. на рисунке 28.2 приведена временная диаграмма smtp соединения между отправителем smtp (клиент) и получателем smtp (сервер). мы удалили все связанное с установлением и разрывом соединения, а также объявления размера окна. в этом примере пользовательский агент отправляет сообщение длиной в одну строку ("1, 2, 3."), однако в сегменте 12 передается 393 байта данных. следующие 12 строк включают в себя 393 байта, которые были посланы клиентом:
рисунок 28.2 принцип доставки почты smtp.
mta добавляет первые три строки, а также received: и message-id:, а следующие девять строк генерируются пользовательским агентом. минимальные smtp реализации поддерживают восемь команд. мы видели пять из них в предыдущем примере: helo, mail, rcpt, data и quit. команда rset прекращает текущую передачу почты и заставляет оба конца "сброситься". любая сохраненная информация об отправителе, получателе или содержимое почты уничтожается. команда vrfy позволяет клиенту попросить отправителя проверить адрес получателя, не отправляя ему почту. этим часто пользуются системные администраторы, чтобы вручную определить проблемы с доставкой почты. мы увидим, как это делается, в следующем разделе. команда noop не делает ничего, однако заставляет сервер ответить, что все нормально, а именно откликом с кодом 200. существуют также дополнительные, необязательные команды. expn расширяет список почты и часто используется системными администраторами, так же как и vrfy. более того, большинство версий sendmail обрабатывают эти две команды одинаково. версия 8 sendmail в 4.4bsd больше не обрабатывает одинаково эти две команды. vrfy не расширяет псевдонимы и не отслеживает файлы .forward.
команда turn позволяет клиенту и серверу поменяться ролями, чтобы послать почту в обратном направлении, не разрывая tcp соединение и не создавая новое. (sendmail не поддерживает эту команду.) существуют еще три команды (send, soml и saml), которые очень редко реализуются и призваны заменить собой команду mail. эти три команды в своих комбинациях позволяют доставлять почту непосредственно на пользовательский терминал (если пользователь находится терминалом в системе) или складывать ее в почтовый ящик получателя. конверты, заголовки и тело электронная почта состоит из трех частей. mail from:<rstevens@sun.tuc.noao.edu>rcpt to:<rstevens@noao.edu> rfc 821 определяет содержимое и интерпретацию конверта, а также протокол, который используется для обмена почтой по tcp соединению.
затем пользовательский агент берет то, что было указано в качестве тела сообщения, добавляет некоторые заголовки и передает результат в mta. mta добавляет свои заголовки, добавляет конверт и посылает результат другому mta. термин содержимое часто используется, чтобы описать комбинацию заголовков и тела. содержимое посылается клиентом с использованием команды data. первая информационная строка от локального mta в примере была следующей: "connecting to mailhost via ether". это объясняется тем, что система автора сконфигурирована таким образом, чтобы посылать всю нелокальную исходящую почту на транслирующую машину для дальнейшей доставки. так сделано по двум причинам. во-первых, упрощается конфигурацию всех mta, кроме mta транслирующей системы. (конфигурация mta не проста, каждый, кто когда-либо работал с sendmail, может это подтвердить.) во-вторых, одна система в организации может выступать в роли почтового ретранслятора, возможно пряча тем самым все остальные индивидуальные системы. в нашем примере транслирующая система имеет имя хоста mailhost в локальном домене (.tuc.noao.edu), а все индивидуальные системы сконфигурированы таким образом, чтобы посылать свою почту на этот хост. мы можем исполнить команду host, чтобы посмотреть, как это имя определено в dns:
если хост, который используется в качестве ретранслирующего, в будущем изменится, необходимо только сменить его dns имя - конфигурация почты всех индивидуальных систем не изменится. большинство организаций в настоящее время используют транслирующие системы. на рисунке 28.3 показана упрощенная схема почты в internet (рисунок 28.2), причем сделано предположение, что большинство отправляющих хостов и окончательные получающие хосты используют транслирующие хосты. между отправителем и получателем присутствует четыре mta. локальный mta на хосте отправителя просто доставляет почту на свой транслирующий mta. (этот транслирующий mta должен иметь имя mailhost в домене организации.) здесь smtp использует локальные сети организации. затем транслирующий mta организации отправителя посылает почту по internet на транслирующий mta организации получателя. другие транслирующие mta доставляют почту на хост получателя после общения с локальными mta хоста получателя. все mta в примере используют smtp, хотя существует возможность того, что на этом пути могут встретиться и другие протоколы доставки. nvt ascii одна из характеристик smtp заключается в том, что он использует nvt ascii абсолютно везде: в конверте, заголовке и теле сообщения. как мы сказали в разделе "протокол telnet" главы 26, nvt ascii это 7-битная кодировка символов, символы при этом передаются как 8-битные байты, у которых старший бит установлен в 0.
рисунок 28.3 электронная почта по internet с транслирующими системами на обоих концах.
в разделе "будущее smtp" этой главы мы обсудим некоторые более новые характеристики почты в internet, расширенный smtp и мультимедийную почту (mime), которая позволяет отправлять и принимать звуковую и видео информацию. мы увидим, что mime использует nvt ascii в качестве конверта, заголовка и тела, а изменения касаются только пользовательских агентов. интервалы между ретрансляциями когда пользовательский агент передает новое почтовое сообщение своему mta, попытка доставить сообщение обычно осуществляется немедленно. если доставить сообщение не удалась, mta поставит сообщение в очередь и повторит попытку позже. требования к хостам host requirements rfc рекомендует устанавливать первоначальный тайм-аут по крайней мере в 30 минут. отправитель должен повторять свои попытки по меньшей мере 4-5 дней. более того, если сбои в доставке происходят часто (получатель вышел из строя или произошла временная потеря сетевого соединения), имеет смысл делать две попытки установить соединение в течение первого часа, когда сообщение находится в очереди. в предыдущем разделе показана обычная доставка почты; сейчас рассмотрим, как для доставки почты записи используются mx, а также проиллюстрируем работу команд vrfy и expn. записи mx: хост не подключен непосредственно к internet в разделе "записи ресурсов" главы 14 мы сказали, что один из типов записи ресурса в dns используется для обмена почты и называется записями mx. в следующем примере мы покажем, как используются записи mx, для отправки почты на хосты, не подключенные к internet непосредственно. rfc 974 [partridge 1986] описывает, как mta обрабатывает записи mx. хост mlfarm.com не подключен к internet, однако имеет mx запись, указывающую на перенаправителя почты, который, в свою очередь, находится в internet:
здесь показаны две записи mx, каждая с различной степенью предпочтительности. мы ожидаем, что mta начнет с меньшего из двух значений предпочтительности. следующий скрипт показывает, как почта будет послана этому хосту:
mta определил, что хост назначения имеет mx запись и использует mx запись с минимальным значением предпочтительности. перед запуском этого примера на хосте sun была изменена конфигурация таким образом, чтобы при отправке почты не использовался обычный транслирующий хост, поэтому мы видим обмен почтой с хостом назначения. также в конфигурации было сказано использовать dns сервер на хосте noao.edu (к которому можно получить доступ через slip канал с дозвоном). благодаря этому, с использованием tcpdump, мы можем посмотреть и передачу почты, и dns траффик на slip канале. на рисунке 28.4 показана начальная часть вывода команды tcpdump.
рисунок 28.4 посылка почты на хост, который использует mx записи.
в строке 1 mta запрашивает свой dns сервер о mx записи для mlfarm.com. знак плюс, следующий за 2, означает, что установлен флаг "необходима рекурсия". отклик в строке 2 имеет установленным бит полномочности (звездочка, следующая за 2) и содержит 2 записи ресурса (rr) ответа (два имени mx хостов), 0 записей ресурса rr прав доступа и две дополнительные rr (ip адреса двух хостов). в строках 3-5 устанавливается tcp соединение с smtp сервером на хосте mercury.hsi.com. первоначальный отклик сервера (220) показан в строке 6. каким-либо образом хост mercury.hsi.com должен доставить это почтовое сообщение в пункт назначения - mlfarm.com. протокол uucp является распространенным способом обмена почтой с mx узлами для систем, которые не подключены к internet. в этом примере mta запрашивает mx запись, получает ее и посылает почту. к сожалению, взаимодействие между mta и dns может отличаться в зависимости от реализации. rfc 974 указывает, что mta должен сначала запросить mx записи, и если они не найдены, попробовать доставить почту на хост назначения (то есть запросить dns на предмет записи a для хоста, его ip адрес). mta должен также поинтересоваться записями cname в dns (канонические имена). например, если мы пошлем почту хосту rstevens@mailhost.tuc.noao.edu с bsd/386 хоста, mta (sendmail) проделает следующее.
mailhost.tuc.noao.edu cname noao.edu noao.edu mx noao.edu
запрос cname не осуществляется для данных, возвращенных в mx записи (noao.edu). данные в mx записи не могут быть псевдонимами - они должны быть именем хоста, который имеет запись a. версия sendmail, распространяемая с sunos.4.1.3, обращается к dns только с запросами о существовании mx записей и сразу прекращает все попытки, если mx запись не найдена.
mx записи: хосты, которые выключены другое использование mx записи заключается в том, чтобы найти альтернативного получателя почты, если хост назначения выключен. если мы посмотрим dns записи для нашего хоста sun, то увидим, что он имеет две mx записи:
mx запись с минимальным уровнем предпочтительности указывает, что сначала надо попробовать доставить почту непосредственно на хост. следующее значение предпочтительности указывает на необходимость осуществить доставку почты на хост noao.edu. в следующем скрипте мы посылаем почту сами себе на хост sun.tuc.noao.edu, с хоста vangogh.cs.berkeley.edu, предварительно выключив smtp сервер назначения. когда на порт 25 прибывает запрос на соединение, tcp должен ответить сбросом (rst), так как не существует процесса, который может осуществить пассивное открытие для этого порта.
мы видим, что mta старается установить контакт с sun.tuc.noao.edu, затем прекращает попытки и устанавливает контакт с noao.edu. на рисунке 28.5 показан вывод команды tcpdump, где показано, как tcp отвечает сбросом (rst) на входящие syn.
рисунок 28.5 попытки установить контакт с неработающим smtp сервером.
в строке 1 vangogh отправляет syn на порт 25 на первый ip адрес хоста sun: 140.252.1.29. в строке 2 мы видим отказ. smtp клиент на vangogh пробует следующий ip адрес sun: 140.252.13.33 (строка 3), что также вызывает возврат rst (строка 4). smtp клиент не старается изменить свое поведение в результате ошибки, полученной на активное открытие, которое он осуществлял в строке 1, именно поэтому он старается обратиться к другому ip адресу в строке 2. если ошибка была подобна "хост недоступен" (host unreachable) для первой попытки, возможно, что вторая попытка сработает. если причина, по которой активное открытие smtp клиента не сработало, заключается в том, что хост выключен, мы увидим, что клиент будет повторно выдавать syn на ip адрес 140.252.1.29 в течение 75 секунд (примерно так же, как на рисунке 18.6), затем отправит еще три syn на ip адрес 140.252.13.33 в течение других 75 секунд. после 150 секунд клиент перейдет к следующей mx записи с более высоким значением предпочтительности. команды vrfy и expn команда vrfy проверяет, в порядке ли адрес получателя, не посылая при этом реальной почты. expn предназначена для расширения почтового псевдонима до почтового адреса. большинство smtp реализаций (такие как sendmail) воспринимают эти команды абсолютно одинаково, однако мы уже отмечали, что более новые версии sendmail проводят различие между ними. в качестве простого теста мы можем подсоединиться к более новой версии sendmail и посмотреть эти различия. (мы удалили вывод клиента telnet.)
во-первых, обратите внимание на то, что мы специально напечатали неверное имя хоста для команды helo: bsdi вместо sun. большинство smtp серверов берут ip адрес клиента и осуществляют запрос указателя dns (глава 14, раздел "запросы указателя"), после чего сравнивают имена хостов. это позволяет серверу зарегистрировать соединение клиента, основываясь на его ip адресе, а не на имени, которое пользователь может указать неверно. некоторые серверы отвечают юмористическими сообщениями, такими как "вы шарлатан" или "почему бы вам не позвонить самому себе...". в этом примере мы видели, что сервер просто напечатал реальное имя домена из запроса указателя вместе с ip адресом. затем мы вводим команду vrfy для несуществующего имени, на что сервер отвечает ошибкой 550. затем мы печатаем существующее имя, а сервер отвечает именем пользователя на локальном хосте. затем мы пробуем команду expn и получаем другой отклик. команда expn определяет, что почта для этого пользователя будет перенаправлена и печатает адрес перенаправления. на многих хостах команды vrfy и expn отключены, может быть с точки зрения секретности и иногда из-за того, что администраторы считают, что в этом находится какая-то дырка в секретности. например, мы можем попробовать воспользоваться этими командами на smtp сервере белого дома (сша):
в настоящее время почта internet заметно меняется. вспомните, что почта internet состоит из трех частей: конверт, заголовки и тело сообщения. появляются новые smtp команды, которые изменяют конверт, в заголовках могут быть использованы не-ascii символы, а к телу добавляются структуры (mime). в этом разделе мы по порядку рассмотрим расширение каждой из трех частей. изменения в конверте: расширенное smtp rfc 1425 [klensin et al. 1993a] определяет основные расширения для smtp. в результате получилось то, что называется расширенным smtp (esmtp - extended smtp). как и другие новые характеристики (уже описанные в тексте), эти изменения добавляются таким образом, что новые версии совместимы со старыми. клиент, которому необходимо использовать новые характеристики, открывает сессию с сервером с использованием команды ehlo вместо команды helo. совместимый сервер отвечает откликом с кодом 250. этот отклик обычно содержит несколько строк, причем каждая строка содержит ключевое слово и дополнительный аргумент. ключевые слова указывают на расширения smtp, поддерживаемые сервером. (в случае многострочного отклика во всех строках кроме последней, между цифровым кодом и текстом стоит дефис. в последней строке между цифровым кодом и текстом стоит пробел.) вновь появляющиеся расширения будут описаны в rfc и будут зарегистрированы в iana. ниже показаны начальные стадии соединений с четырьмя smtp серверами, три из которых поддерживают расширенный smtp. соединение осуществляется с помощью telnet, однако весь вывод telnet клиента удален. sun % telnet vangogh.cs.berkeley.edu 25 220-vangogh.cs.berkeley.edu sendmail 8.1c/6.32 ready at mon, 2 aug 1993 15:47:48 -0700 220 esmtp spoken here ehlo sun.tuc.noao.edu 250-vangogh.cs.berkeley.edu hello sun.tuc.noao.edu [140.252.1.29], pleased to meet you 250-expn 250-size 250 help
этот сервер выдает многострочный отклик 220 в виде приветственного сообщения. расширенные команды, приведенные в отклике 250, на команду ehlo это expn, size и help. первая и последняя из исходной спецификации rfc 821, однако они являются дополнительными командами (необязательными). сервера esmtp помимо дополнительных команд из rfc 821 поддерживают также и более новые команды. ключевое слово size означает, что сервер поддерживает то, что описано в rfc 1427 [klensin, freed, and moore 1993]. подобное расширение позволяет клиенту указывать размер сообщения в байтах в командной строке mail from. это позволяет серверу проверить, что он воспримет сообщение определенного размера, перед тем как клиент начнет его посылать. эта команда была добавлена, так как в последнее время появляется все больше почтовых сообщений содержащих не-ascii строки (например, бинарные или звуковые файлы). следующий хост также поддерживает esmtp. отклик 250 указывает, что поддерживаемое ключевое слово size содержит дополнительный аргумент. он указывает на то, что этот сервер может воспринимать сообщения размером до 461 мегабайта. sun % telnet ymir.claremont.edu 25 220 ymir.claremont.edu -- server smtp (pmdf v4.2-13 #4220) ehlo sun.tuc.noao.edu 250-ymir.claremont.edu 250-8bitmime 250-expn 250-help 250-xadr 250 size 461544960
ключевое слово 8bitmime определено в rfc 1426 [klensin et al. 1993b]. оно позволяет клиенту добавить ключевое слово body к команде mail from, указывая тем самым, содержит ли тело сообщения nvt ascii символы (по умолчанию) или 8-битные данные. если клиент не получил ключевое слово 8bitmime от сервера в ответ на команду ehlo, клиенту запрещено посылать любые другие символы кроме nvt ascii. (когда мы будем говорить о mime в этом разделе, то увидим, что для mime не требуется 8-битный smtp транспорт.) этот сервер также объявил ключевое слово xadr. любое ключевое слово, которое начинается на x, обозначает местное расширение smtp. следующий сервер также поддерживает esmtp, объявляя ключевые слова help и size, которые мы уже видели. он также поддерживает три локальных расширения, которые начинаются на x. sun % telnet dbc.mtview.ca.us 25 220 dbc.mtview.ca.us sendmail 5.65/3.1.090690, it's mon, 2 aug 93 15:48:50 -0700 ehlo sun.tuc.noao.edu 250-hello sun.tuc.noao.edu, pleased to meet you 250-help 250-size 250-xone 250-xvrb 250 xque
и в конце мы посмотрим, что произойдет, когда клиент пытается использовать esmtp, выдав команду ehlo на сервер, который это не поддерживает. sun % telnet relay1.uu.net 25 220 relay1.uu.net sendmail 5.61/uunet-internet-primary ready at mon, 2 aug 93 18:50:27 -0400 ehlo sun.tuc.noao.edu 500 command unrecognized rset 250 reset state
вместо того чтобы получить отклик 250 на команду ehlo, клиент получил отклик 500. затем клиент должен исполнить команду rset, а уже затем команду helo. изменения в заголовках: использование не-ascii символов rfc 1522 [moore 1993] указывает способы передачи не-ascii символов в заголовках сообщений, основанных на rfc 822. основное назначение - разрешить использовать дополнительные символы в именах отправителя и получателя, а также в теме сообщения. поле заголовка может содержать закодированные слова. при этом формат следующий:
=? charset ? encoding ? encoded text ?=
charset это спецификация набора символов. приемлемые значения это две строки us-ascii и iso-8859-x, где x это одна цифра, как, например, iso-8859-1. encoding это один символ, который указывает метод кодирования. поддерживаются два значения.
рисунок 28.6 кодирование 6-битных значений (кодирование на основе 64).
когда количество символов, которые необходимо кодировать, не кратно трем, в качестве символов заполнения используются знаки равно.
следующий пример этих двух типов кодирования взят из rfc 1522: from: =?us-ascii?q?keith_moore?= <moore@cs.utk.edu> to: =?iso-8859-1?q?keld_j=f8rn_simonsen?= <keld@dkuug.dk> cc: =?iso-8859-1?q?andr=e9_?= pirard <pirard@vm1.ulg.ac.be> subject: =?iso-8859-1?b?swygew91ignhbibyzwfkihroaxmgew8=?= =?iso-8859-2?b?dsb1bmrlcnn0yw5kihrozsblegftcgxllg==?=
пользовательский агент имеет возможность обработать эти заголовки, в результате чего получится следующий вывод: from: keith moore <moore@cs.utk.edu> to: keld jorn simonsen <keld@dkuug.dk> cc: andre pirard <pirard@vm1.ulg.ac.be> subject: if you can read this you understand the example.
для того чтобы посмотреть, как работает кодирование на основе 64, посмотрите на первые 4 закодированных символа в строке темы: swyg. напишем 6-битные значения для этих 4 символов в соответствии с рисунком 28.6 (s=0x12, w=0x16, y=0x18 и g=0x20) в двоичном виде: 010010 010110 011000 100000
затем перегруппируем эти 24 бита в три 8-битных байта:
которые в виде ascii представляют собой i, f и пробел. изменения в теле сообщения: многофункциональные расширения почты internet (mime - multipurpose internet mail extensions) мы говорили, что rfc 822 описывает тело сообщения как строки nvt ascii текста, без структуры. rfc 1521 [borenstein and freed 1993] определяет расширения, которые позволяют вводить структуру в тело сообщения. это называется многофункциональным расширением почты internet (mime - multipurpose internet mail extensions). mime не требует тех расширений, что мы описали ранее в этом разделе (расширенный smtp или не-ascii заголовки). mime просто добавляет некоторые новые заголовки (в соответствии с rfc 822), которые сообщают получателю о структуре тела сообщения. тело сообщения может передаваться с использованием nvt ascii, вне зависимости от содержимого почты. несмотря на это некоторые из расширений, которые мы только что описали, могут быть вполне уместны при использовании вместе с mime - команда size расширенного smtp, так как mime сообщения могут быть довольно большими, и не-ascii заголовки, эти расширения не требуются для mime. все что требуется для обмена mime сообщениями с другой стороной - необходимо, чтобы на обоих концах присутствовали пользовательские агенты, которые понимают mime. на промежуточных mta не требуется никаких изменений. mime определяет пять новых полей заголовков: mime-version: content-type: content-transfer-encoding: content-id: content-description:
в качестве примера, приведены две строки заголовка, которые могут присутствовать в почтовом сообщении internet: mime-version: 1.0 content-type: text/plain; charset=us-ascii
текущая версия mime - 1.0, в которой сообщения выглядят как простой ascii текст, что является форматом по умолчанию для почты internet. слово plain определяет подтип типа содержимого (text), а строка charset=us-ascii это параметр. text это всего лишь один из семи определенных в mime типов содержимого. на рисунке 28.7 приводится краткое описание 16 различных типов содержимого и подтипов, определенных в rfc 1521. для конкретных типов содержимого и подтипов может быть определено большое количество параметров. тип содержимого и кодирование при передаче, применяемое к телу сообщения, независимы друг от друга. здесь указаны поле заголовка content-type (тип содержимого) и поле заголовка content-transfer-encoding (кодирование содержимого при передаче). в rfc 1521 определено пять различных форматов кодирования.
рисунок 28.7 типы и подтипы содержимого mime.
только первые три из приведенных приемлимы для mta работающих по правилам rfc 821, так как в этих трех случаях генерируется содержимое тела сообщения в виде только nvt ascii символов. при использовании расширенного smtp с 8bitmime, поддерживается 8bit кодирование. так как тип содержимого и кодирование независимы, rfc 1521 рекомендует quoted-printable для text с не-ascii данными, и base64 для данных типа image, audio, video и octet-stream приложений. при этом гарантируется максимальная совместимость с mta, работающими по правилам rfc 821. типы содержимого multipart и message должны быть кодированы как 7bit. на рисунке 28.8 показано почтовое сообщение, содержащее список распространяемых rfc, тип содержимого - multipart. подтип - mixed, это означает, что каждая часть должна быть обработана последовательно, разделители между частями выглядят как строка nextpart, перед которой стоят два дефиса в начала строки. за каждым разделителем может следовать строка, содержащая поля заголовка для следующей части. часть сообщения перед первым разделителем игнорируется, так же как и часть следующая за последним разделителем. так как за первым разделителем следуют пустые строки и не указаны поля заголовка, между первым и вторым разделителями подразумевается тип содержимого данных text/plain с набором символов us-ascii. это текстовое описание нового rfc. за вторым разделителем, однако, следуют поля заголовков. они определяют следующее сообщение как multipart, с разделителем otheraccess. подтип - alternative, причем присутствует два альтернативных варианта. первый otheraccess предназначен для получения rfc с использованием электронной почты, а второй для получения с использованием анонимного ftp. пользовательский агент mime предоставляет список из двух возможных вариантов, что позволяет автоматически получить копию rfc с использованием либо почты, либо анонимного ftp.
рисунок 28.8 пример mime сообщения, состоящего из нескольких частей.
этот раздел является кратким описанием mime. для получения более подробной информации и примеров mime можно обратиться к rfc 1521 и [rose 1993]. в работе электронной почты принимают участие пользовательские агенты на обоих концах (отправитель и получатель), а также два или несколько агентов передачи сообщения. мы можем поделить почтовое сообщение на три части: конверт, заголовки и тело сообщения. мы видели, как происходит обмен этими частями с использованием smtp, который является стандартом в internet. все три состоят из символов nvt ascii. также мы рассмотрели новые расширения этих трех частей: расширенный smtp для конверта, не-ascii заголовки и дополнительная структура для тела сообщения с использованием mime. структура и кодирование, используемые mime, позволяют обмениваться двоичными данными с использованием существующих 7-битных mta smtp. упражнения
|
