Понятие протокола, и связанные с ним понятия

Вид материалаДокументы

Содержание


Системы передачи электронной почты.
Протоколы POP3 та SMTP.
Схема взаимодействия по протоколу SMTP
MAIL, идентифицирующей отправителя: MAIL
TURN. Команда RESET (RSET
HELP требует послать справочную информацию. Может содержать аргумент (имя команды). Не изменяет состояния таблиц или буферов. Ко
NOOP (не использует каких-либо аргументов). При реализации этой команды сервер не делает ничего, лишь посылает положительный отк
Дополнительные возможности электронной почты. Спецификация MIME. Протоколы IMAP.
Сообщение MIME (комплексный пример)
Исходные тексты программ
Подобный материал:
1   ...   12   13   14   15   16   17   18   19   20

Системы передачи электронной почты.

Назначение систем передачи электронной почты.


Электронная почта, пожалуй, древнейшая служба, поддерживаемая компьютерными сетями. Еще в операционных системах первых многопользовательских ЭВМ присутствовала какая-нибудь команда, чаще всего SEND, позволявшая отправить сообщение на терминал другому пользователю той же многопользовательской системы.

В последующем именно из такой услуги и развилась электронная почта Сперва сообщение можно было отправить только активному пользователю, затем – и неактивному (при входе в систему он получал сообщение вроде «Для Вас есть почта – 1 письмо. Забрать?»), затем появилась возможность пересылать не только краткие текстовые сообщения, а любые данные (письма с вложениями).

Появились развитые системы автоматической обработки почтовых сообщений (почтовые роботы). Некоторые сети, например, FIDO, целиком были построены на почтовом обмене.

В настоящее время, когда можно подумать, что Internet – WWW., WWW. и только WWW., необходимость изучать системы электронной почты не столь очевидна. Тем не менее, системы передачи электронной почты и сейчас находят широкое применение. Во многих случаях, когда время доставки информации некритично, передача ее через систему электронной почты – разумное и эффективное решение. Кроме того, протоколы обмена электронной почты Internet и другие протоколы уровня приложений этого же стека, такие как протоколы передачи гипертекста HTTP, передачи файлов FTP и другие, имеют много общего. Они, как правило, также используют простые текстовые команды, очень похожие на те, которые мы рассмотрим ниже на примере протоколов электронной почты SMTP и POP3. Так что их изучение полезно и для понимания других прикладных протоколов стека TCP/IP24.

При рассмотрении информационных технологий Internet следует также принимать во внимание тот факт, что они все взаимосвязаны, и почти всегда можно получить доступ к одной из них через другую. Так, например, к FTP-архиву можно обратиться через электронную почту или использовать для доступа к FTP-архиву Web-броузер. Письмо электронной почты тоже можно отправить, а в большинстве систем и забрать через браузер. Все эти возможности предполагают использование программ-шлюзов, включенных в состав программных пакетов Web-броузеров, и это создает иллюзию поглощения традиционных технологий WWW. Но на самом деле это следствие многопротокольности браузера.

Более того, хотя HTTP и выступает в роли интегратора доступа к любым ресурсам сети, трафик традиционных протоколов – FTP, Prospero (поиск файлов в FTP-архивах), электронной почты и новостей, наконец, Telnet – и сейчас значительно превосходит трафик HTTP. Они никуда не делись, и если пользователь может их и не замечать «под оболочкой WWW», то администратору от этого никуда не уйти.

Электронная почта и сейчас – один из важнейших информационных ресурсов Internet. Она является самым массовым средством электронных коммуникаций. Любой из пользователей Internet имеет свой почтовый ящик в сети, и чаще всего не один. А если учесть, что через Internet можно принять или послать сообщения еще в два десятка международных компьютерных сетей, некоторые из которых не имеют on-line сервиса вовсе, то становится понятным, что почта предоставляет возможности в некотором смысле даже более широкие, чем просто информационный сервис Internet. Через почту можно получить доступ к информационным ресурсам других сетей. Хорошим примером может служить доступ к архивам сети BITNET – документам и телеконференциям, которые ведутся на серверах списков (LISTSERVER) BITNET. Другой пример – доступ к конференциям FIDO. Через службы, имеющие «почтовых роботов» – программы, анализирующие запросы в сообщениях и отвечающие на них – электронная почта позволяет в ряде случаев заказывать и получать из сети практически любую информацию, хотя целесообразность использования именно почты в каждом конкретном случае – вопрос спорный.

Электронная почта, в соответствии со своим названием, действительно во многом похожа на обычную почтовую службу. Корреспонденция подготавливается пользователем на своем рабочем месте либо программой подготовки почты, либо просто обычным текстовым редактором. Программа подготовки почты вызывает свой встроенный текстовый редактор, иногда допускается его замена редактором, который пользователь предпочитает остальным программам этого типа. Затем пользователь должен вызвать программу отправки почты (программа подготовки почты вызывает программу отправки автоматически). Устанавливается соединение с почтовым сервером и сообщение передается ему, а он далее передает его получателю – непосредственно или через промежуточные узлы.

В принципе, как мы далее убедимся, можно обойтись и без почтовой программы, скажем, воспользоваться программой telnet, но так обычно не делают.

Протоколы доставки электронной почты являются протоколами прикладного уровня модели OSI, и в TCP/IP сетях обычно используют в качестве транспортного протокола TCP.

Основой любой почтовой службы является система адресов. Без точного адреса невозможно доставить почту адресату. В Internet принята система адресов, которая базируется на доменном адресе машины, подключенной к сети. Например, для пользователя jki машины (почтового сервера) ukrpost.net почтовый адрес будет выглядеть так: jki@ukrpost.net

В сетях, отличных от Internet, адреса могут быть другими, например, вместо @ может использоваться, скажем !, иным может быть и порядок следования имен машины и пользователя.

Протоколы POP3 та SMTP.


Протокол SMTP (Simple Mail Transfer Protocol) был разработан для обмена почтовыми сообщениями в сети Internet. В качестве транспортного протокола используется TCP, порт 25. Но SMTP как таковой не зависит от транспортной среды и может использоваться для доставки почты в сетях с протоколами, отличными от TCP/IP, например, Х.25. Достигается это за счет концепции IPCE (Inter Process Communication Environment). IPCE позволяет взаимодействовать процессам, поддерживающим SMTP, в интерактивном режиме, а не в режиме "STOP-GO".

Взаимодействие в рамках SMTP строится по принципу двусторонней связи клиент-сервер. Отправитель выступает в роли клиента, а получатель – сервера. Отправитель инициирует соединение и посылает запросы на обслуживание, а получатель на эти запросы отвечает.



Схема взаимодействия по протоколу SMTP

Канал связи устанавливается непосредственно между отправителем и получателем сообщения. При таком взаимодействии почта достигает абонента в течение нескольких секунд после отправки.

Обмен сообщениями и инструкциями в SMTP ведется в ASCII-кодах. В протоколе определено несколько видов взаимодействия между отправителем почтового сообщения и его получателем, которые здесь называются дисциплинами.

Наиболее распространенной дисциплиной является отправка почтового сообщения, которая начинается по команде MAIL, идентифицирующей отправителя:

MAIL FROM: paul@quest.polyn.kiae.su

Следующей командой определяется адрес получателя:

RCPT TO: paul@apollo.polyn.kiae.su

После того, как определен отправитель и получатель почтового сообщения, можно отправлять само сообщение:

DATA

Команда DATA вводится без параметров и идентифицирует начало ввода почтового сообщения. Сообщение вводится до тех пор, пока не будет введена строка с точкой в первой позиции. Согласно стандарту почтового сообщения RFC-822 отправитель передает заголовок и тело сообщения, которые разделены пустой строкой. Сам протокол SMTP не накладывает каких-либо ограничений на информацию, которая заключена между командой DATA и "." в первой позиции последней строки – он ее просто не анализирует (разумеется, кроме первой позиции каждой строки – не точка ли). Однако гарантированной, согласно RFC-822, является только доставка текста в коде ASCII. Расширенные (с установленным в единицу старшим битом), и управляющие (01F16) коды могут подвергнуться искажению. Приведем пример обмена сообщениями при дисциплине отправки почты:

S: MAIL FROM:


R: 250 Ok

S: RCPT TO:

R: 250 Ok

S: DATA

R: 354 Start mail input; end with .

S: Это текст почтового сообщения

S:.

R: 250

Другой дисциплиной, определенной в протоколе SMTP является перенаправление почтового сообщения (forwarding). Если получатель не найден, но известно его местоположение, то сервер может выдать сообщение:

R: 251 User not local;

Will forward to

Если сервер может сделать только предположение о дальнейшей рассылке, то ответ будет несколько иным:

R: 551 User not local;

Please try

Верификация и расширение адресов составляют дисциплину верификации. В ней используются команды VRFY и EXPN. По команде VRFY сервер подтверждает наличие или отсутствие указанного пользователя:

S: VRFY paul

R: 250-Paul Khramtsov


Используя команду EXPN можно получить список местных пользователей:

S: EXPN Example-People

R: 250-Paul Khramtsov


R: 250-Vladimir Drach-Gorkunov

В список дисциплин, разрешенных протоколом SMTP, входит кроме отправки почты еще и прямая рассылка сообщений. В этом случае сообщение будет отправляться не в почтовый ящик, а непосредственно на терминал пользователя, если пользователь в данный момент находится за своим терминалом. Прямая рассылка осуществляется по команде SEND, которая имеет такой же синтаксис, как и команда MAIL. Кроме SEND прямую рассылку осуществляют SOML (Send or Mail) и SAML (Send and Mail). Назначение этих команд легко понять из их названия.

Для инициализации канала обмена почтой и его закрытия используются команды HELO и QUIT соответственно. Первой командой сеанса должна быть команда HELO.

Протокол допускает рассылку почтовых сообщений в режиме оповещения. Для этой цели отправитель в адресе получателя может указать несколько пользователей или групповой адрес. Обычно, программное обеспечение SMTP выбирает эту информацию из заголовка почтового сообщения и на ее основе формирует параметры команд протокола.

Если сообщение по какой-либо причине не может быть разослано, то получатель формирует сообщение о не разосланном сообщении:

S: MAIL FROM:<>

R: 250 Ok

S: RCPT TO: <@host.domain:JOE@host.domain>

R: 250 Ok

S: DATA

R: 354 send the mail data, end with .

S: Date 23 Oct 95 11:23:30

S: From: SMTP@remote.domain

S: To:

S:

S: Undelivered message. Your message lost. 550 No such user.

S:.

При использовании доменных имен следует использовать канонические имена, т.к. некоторые системы не могут определить синоним по базе данных named.

SMTP позволяет отправителю и получателю меняться ролями друг с другом. Происходит это по команде TURN.

Команда RESET (RSET) прерывает текущую процедуру отправки почтового сообщения. Все буферы и таблицы очищаются, получатель должен послать отклик 250 OK.

Команда HELP требует послать справочную информацию. Может содержать аргумент (имя команды). Не изменяет состояния таблиц или буферов.

Команда NOOP не оказывает влияния на какие-либо параметры или результаты предшествующих команд, она только вынуждает получателя послать отклик 250 OK. Может использоваться для проверки работоспособности TCP-канала.

Допустимо написание команд строчными или прописными символами, например: MAIL, Mail, mail, MaIl или mAIl.

Для того чтобы программа SMTP-сервера была работоспособна, она должна понимать следующий минимум команд: HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT.

Любое почтовое сообщение можно разделить на три части: "конверт" (RFC-821), заголовки (RFC-822) и собственно текст. Конверт используется почтовым сервером и содержит две команды: MAIL From: и RCPT To:

Существует девять полей заголовка, используемые почтовой программой пользователя: Received, From, To, Date, Subject, Message-Id, X-Phone, X-Mailer, Reply-To. Каждое из этих полей содержит имя, за которым после двоеточия следует его значение. Документ RFC-822 определяет формат и интерпретацию полей заголовка. Заголовки, начинающиеся с X- являются полями, определяемые пользователем.

Тело сообщения определяется просто как последовательность строк символов ASCII.

Протокол POP3 (Post Office Protocol, RFC-1939) Если по протоколу SMTP пользователи отправляют корреспонденцию через Internet, то по протоколу POP3 пользователи получают корреспонденцию из своих почтовых ящиков на почтовом сервере в локальные файлы. Это позволяет передавать сообщения почтовым серверам на хранение, а затем адресат забирает почту из ящика. Протокол обмена почтовой информацией POP3 предназначен для разбора почты из почтовых ящиков пользователей на их рабочие места при помощи программ-клиентов. Этот протокол обеспечивает доступ узла к базовому почтовому серверу. POP3 не ставит целью предоставление широкого списка манипуляций с почтой, он лишь получает и стирает почтовые сообщения.

POP3-сервер прослушивает TCP-порт 110. Если ЭВМ-клиент хочет воспользоваться услугами POP3-сервера, то устанавливает с ним TCP связь. По установлении связи POP3-сервер посылает клиенту уведомление (например, +OK POP3 server ready) и сессия переходит в фазу авторизации (RFC-1734, -1957). В процессе авторизации клиент должен представить себя серверу, передав имя и пароль (возможен вариант посылки команды APOP). Если авторизация успешно завершена, сессия переходит в состояние транзакции (TRANSACTION). После этого может производиться обмен командами и откликами. При получении от клиента команды QUIT сессия переходит в состояние UPDATE, при этом все ресурсы освобождаются и TCP соединение разрывается. POP3 сервер может быть снабжен таймером пассивного состояния (10 мин.), который осуществляет автоматическое прерывание сессии. Приход любой команды со стороны клиента сбрасывает этот таймер в нуль.

Команды POP3 состоят из ключевых слов (3-4 символа), за которыми могут следовать аргументы. Каждая команда завершается парой символов . Как ключевые слова, так и аргументы могут содержать только печатаемые ASCII-символы. В качестве разделителя используются символы пробела. Каждый аргумент может содержать до 40 символов.

Сигнал отклика в POP3 содержит индикатор состояния и ключевое слово, за которым может следовать дополнительная информация. Отклик также завершается кодовой последовательностью . Длина отклика не превышает 512 символов, включая . Существует два индикатора состояния: положительный - "+OK" и отрицательный "-ERR" (все символы прописные).

Отклики на некоторые команды могут содержать несколько строк. В этом случае последняя строка содержит код завершения 046 ("."), за которым следует .

На практике многострочные отклики для исключения имитации завершаются последовательностью ..

Команды:

LIST [сообщение]

Возможный аргумент номер сообщения, который не может относиться к сообщению, помеченному как удаленное. Команда может быть выдана только в режиме TRANSACTION. При наличии аргумента сервер выдает положительный отклик, содержащий информационную строку сообщения. Такая строка называется скэн-листингом сообщения (scan listing). scan listing состоит из номера сообщения, за которым следует пробел и число байт в сообщении. Сообщения, помеченные как удаленные, не пересылаются. Примером отрицательного отклика может служить: -ERR no such message.

Примеры использования команды LIST:

Клиент выдает команду: LIST

Сервер откликается: +OK 2 messages (320 octets)

Сервер: 1 120

Сервер: 2 200

Сервер: .

...

Клиент: LIST 2

Сервер: +OK 2 200

...

К: LIST 3

С: -ERR no such message, only 2 messages in maildrop

Здесь и далее символом К обозначается клиент, а символом С - сервер.

STAT – аргументов не использует, возможный отклик +OK nn mm, где nn - номер сообщения, а mm - его длина в байтах. Пример использования:

К: STAT

С: +OK 2 320

QUIT – аргументов не использует, возможный отклик +OK.

Сервер POP3 удаляет все сообщения, помеченные как удаленные из почтового ящика, посылает соответствующий отклик и разрывает TCP связь.

RETR msg (msg – номер сообщения). Если POP3-сервер выдал положительный отклик, то за начальным +OK следует сообщение с номером, указанным в аргументе. Отрицательный отклик имеет вид -ERR no such message.

DELE msg (msg - номер сообщения) Сервер POP3 помечает сообщение как удаленное. Любая ссылка на это сообщение в будущем вызовет ошибку. Но само сообщение не удаляется пока сессия не войдет в режим UPDATE.

NOOP (не использует каких-либо аргументов). При реализации этой команды сервер не делает ничего, лишь посылает положительный отклик.

RSET (не использует каких-либо аргументов). Если какие-либо сообщения помечены как удаленные, сервер POP3 удаляет эту пометку и возвращает положительный отклик.

Если сессия завершается не по команде клиента, то перехода в состояние UPDATE не производится, а сообщения не удаляются из почтового ящика.

Ряд команд не входят в перечень обязательных (являются опционными).

TOP msg n, где msg - номер сообщения, а n - число строк (используется только в режиме TRANSACTION).

При положительном отклике на команду TOP сервер посылает заголовки сообщений и вслед за ними n строк их текста. Если n больше числа строк в сообщении, посылается все сообщение.

UIDL [msg], где msg - номер сообщения является опционным (Unique-ID Listing).

Если сервер выдаст положительный отклик, будет выдана строка, содержащая информацию о данном сообщении. Эта строка называется уникальным идентификатором сообщения ("unique-id listing"). При отсутствии аргумента аналогичная информация выдается для каждого из сообщений в почтовом ящике. Уникальный идентификатор сообщения состоит из 1-70 символов в диапазоне от 0x21 до 0x7E. Сообщения в почтовом ящике должны характеризоваться различными идентификаторами. Пример использования команды:

К: UIDL

С: +OK

С: 1 whqtswO00WBw418f9t5JxYwZ

С: 2 QhdPYR:00WBw1Ph7x7

USER name, где name – характеризует почтовый ящик сервера.

Команда используется на фазе авторизации или после неудачного завершения команд USER или PASS. При авторизации клиент должен сначала послать команду USER и лишь после получения положительного отклика команду PASS. Команда может вызвать следующие отклики:

+OK name is a valid mailbox

-ERR never heard of mailbox name

PASS string (string - пароль для доступа к почтовому серверу)

Команда работает в режиме авторизации сразу после команды USER. Когда клиент выдает команду PASS, сервер использует аргументы команд USER и PASS для определения доступа клиента к почтовому ящику. На команду PASS возможны следующие отклики:

+OK maildrop locked and ready

-ERR invalid password

-ERR unable to lock maildrop

APOP name digest, где name – идентификатор почтового ящика, а digest - дайджест сообщения - MD5 (RFC-1828). Команда используется только на стадии авторизации.

Обычно любая сессия начинается с обмена USER/PASS. Но так как в некоторых случаях подключения к серверу POP3 может осуществляться достаточно часто, возрастает риск перехвата пароля. Альтернативным методом авторизации является использование команды APOP. Сервер, который поддерживает применение команды APOP, добавляет временную метку в свое стартовое уведомление. Синтаксис временной метки соответствует формату идентификаторов сообщений, описанному в RFC-822 и должны быть уникальными для всех заголовков уведомлений.

Клиент POP3 фиксирует временную метку и выдает команду APOP. Параметр `name' идентичен параметру `name' команды USER. Параметр `digest' вычисляется с использованием алгоритма MD5 RFC-1321 для строки, состоящей из временной метки (включая угловые скобки) за которой следует строка пароля, которая известна только клиенту и серверу. Параметр `digest' содержит 16 байт, которые пересылаются в шестнадцатеричном формате с использованием строчных ASCII символов. Сервер, получив команду APOP, проверяет принятый дайджест и если он корректен, посылает положительный отклик клиенту. Сессия при этом переходит в состояние транзакции. В противном случае посылается отрицательный отклик и состояние сессии не изменяется. С целью обеспечения безопасности для каждого конкретного пользователя и сервера должен использоваться либо метод доступа USER/PASS, либо APOP, но не в коем случае оба метода попеременно.

Сервер перед закрытием канала по команде QUIT должен удалить из почтового ящика все сообщения, которые были перенесены с помощью команд RETR.

Дополнительные возможности электронной почты. Спецификация MIME. Протоколы IMAP.


Протоколы SMTP и POP3, спецификация формата почтового сообщения “стандарт почтового сообщения ARPA” (RFC-822), изначально предполагали обмен только текстовыми сообщениями в формате ASCII (7 бит). Это с одной стороны удобно, поскольку позволяет передавать и принимать почту с любого алфавитно-цифрового терминала, даже с телеграфного аппарата. Но, с другой стороны, это ограничивает содержимое почтового отправления только англоязычным текстом. Не только кириллица, но и ряд западноевропейских языков используют нестандартные символы с установленным старшим битом, и уж нечего говорить о том, чтобы передавать таким образом хотя бы размеченный текст, тем более графику или двоичные данные.

Проблема передачи по электронной почте произвольных данных решалась посредством кодирования таких данных программой uuencode, преобразующей любые данные в символы ASCII (не управляющие) и упаковки полученной информации в почтовое сообщение для передачи. На приеме данные извлекались из почтового сообщения и преобразовывались к исходному виду программой uudecode. Но это решение “за неимением лучшего”. Особенно его недостаточность сказывается, когда осуществляется почтовое взаимодействие с другими сетями, где этот сервис более развит (еще бы – при отсутствии on-line!), и их почтовые службы поддерживают вложение двоичных данных в почту. Отсутствие единого стандарта при этом чрезвычайно осложняло взаимодействие.

Спецификация MIME (Multipurpose Internet Mail Extension) решает эту проблему.

MIME дополняет RFC-822. Если последний подробно описывает заголовок почтового сообщения и механизм его рассылки, то MIME сориентирован на описание в заголовке письма структуры тела почтового сообщения и возможности составления письма из информационных единиц различных типов.

В стандарте зарезервировано несколько способов представления разнородной информации. Для этой цели используются специальные поля заголовка почтового сообщения:

•поле версии MIME;

•поле описания типа информации в теле сообщения;

•поле типа кодировки информации в теле сообщения;

•два дополнительных поля, зарезервированных для более детального описания тела сообщения.

Стандарт MIME разработан как расширяемая спецификация, в которой подразумевается, что число типов данных будет расти по мере развития форм представления данных. Каждый новый тип в обязательном порядке должен быть зарегистрирован в IANA (Internet Assigned Numbers Authority). Остановимся подробнее на форме и назначении полей, определяемых стандартом.

Поле версии MIME (MIME-Version) Поле версии указывается в заголовке почтового сообщения и позволяет определить программе рассылки почты, что сообщение подготовлено в стандарте MIME. Формат поля выглядит как: MIME-Version: 1.0

Поле типа содержания тела почтового сообщения (Content-Type). Стандарт MIME определяет семь типов данных, которые можно передавать в теле письма: текст (text); смешанный тип (multipart); почтовое сообщение (message); графический образ (image); аудио информация (audio); фильм или видео (video); приложение (application).

Content-Type:= type "/" subtype *[";" parameter]

Например Content-Type:= text/plain

По умолчанию Content-type: text/plain; charset=us-ascii

Для типа text возможны подтипы plain (неразмеченный) richtext или enriched (форматированный) и гипертекст (html).

Multipart Этот тип содержания тела почтового сообщения определяет смешанный документ. Смешанный документ может состоять из фрагментов данных разного типа. Данный тип имеет ряд подтипов. Content-type: multipart/mixed; boundary ="simple boundary"

подтип mixed – последовательность фрагментов, разделенных границей (boundary).

Подтип alternative предполагает варианты для различных программ просмотра.

Content-Type: multipart/alternative; boundary=boundary42

--boundary42

1 фрагмент

Content-Type: text/plain; charset=us-ascii

digest – для сложных сообщений, когда частям сообщения приписывается более сложное условие, чем просто тип.

parallel – для сообщения, части которого должны отображаться параллельно.

Тип "message" предназначен для работы с обычными почтовыми сообщениями, которые, однако, не могут быть переданы по почте по разного рода причинам. Эти причины объясняются подтипами данного типа. Например, подтип "partial" предназначен для передачи одного большого сообщения по частям для последующей автоматической сборки у получателя. Атрибуты подтипа определяют идентификатор сообщения (id), номер порции (number) и общее число порций (total).

Подтип "External-Body", позволяет ссылаться на внешние, относительно сообщения, информационные источники. Если программа просмотра способна работать с внешними протоколами, то можно ссылки разрешить автоматически, запуская соответствующий сервис.

Поле типа кодирования почтового сообщения (Content-Transfer-Encoding).

Content-Transfer-Encoding:="BASE64"/"QUOTED-PRINTABLE"/"8BIT"/"7BIT"/"BINARY"/x-token.

Как уже говорилось ранее, стандарт определяет еще два дополнительных поля: "Content-ID" и "Content-Description". Первое поле определяет уникальный идентификатор содержания, а второе служит для комментария содержания. Ни то, ни другое программами просмотра обычно не отображаются.

Протокол IMAP

Другим протоколом разбора почты является протокол IMAP (Interactive Mail Access Protocol), который по своим возможностям очень похож на POP3, но был разработан как более надежная альтернатива последнего и к тому же обладает более широкими возможностями по управлению процессом обмена с сервером.

Работа протокола осуществляется по 143 порту TCP. Главным отличием от POP является возможность поиска нужного сообщения и разбор заголовков сообщения.

Для поиска информации используются команды FIND с различными аргументами. Это позволяет работать с заголовками сообщений, не скачивая их с сервера целиком, и выбирать, какие загружать, а какие, возможно, нет (просто удалить).

Доступ к сообщениям в IMAP 4.1 осуществляется с помощью уникального идентификатора или порядкового номера сообщения.

Каждому сообщению ставится в соответствие 32-битовый код, который при использовании совместно с уникальным идентификатором образует 64-битовую последовательность, гарантирующую однозначную идентификацию сообщения в почтовом ящике. Сообщения, приходящие позднее имеют больший код UID, чем полученные ранее.

В отличие от порядкового номера сообщения, уникальные идентификаторы не образуют упорядоченной последовательности, но они работают и за пределами текущей сессии. Это позволяет осуществлять ссылки на сообщение в случае обрыва сессии [IMAP-DISC].

Сообщение 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 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--

Исходные тексты программ

uuencode.c

#include

#include

static char encode[]="`!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]_";

#define WRITEBITS(n) putc(encode[(n)&0x3f],outFile)

void EncodeLine(int length,char* line,FILE* outFile){char *p;long l;

WRITEBITS(length);

for(p=line;length>0;p+=3,length-=3){

l=(((long)p[0]&0xff)<<16)|(((long)p[1]&0xff)<<8)|((long)p[2]&0xff);

WRITEBITS(l>>18);WRITEBITS(l>>12);WRITEBITS(l>>6);WRITEBITS(l);}

putc('\n',outFile);}

void EncodeFile(char *name,FILE *inFile,FILE *outFile){char line[80];int i;

fprintf(outFile,"begin 644 %s\n",name);

while((i=fread(line,1,45,inFile))>0)EncodeLine(i,line,outFile);EncodeLine(0,0,outFile);

fprintf(outFile,"end\n");}

main(int argc,char **argv){char stro[256];switch(argc){

case 2:strcpy(stro,argv[1]);if(strchr(stro,'.')==NULL)strcat(stro,".UUE");

else strcpy(strchr(stro,'.'),".UUE");

EncodeFile(argv[1],(stdin->flags&_F_TERM)?fopen(argv[1],"rb"):stdin,(stdout->flags&_F_TERM)?fopen(stro,"at"):stdout);

break;

case 3:strcpy(stro,argv[2]);if(strchr(stro,'.')==NULL)strcat(stro,".UUE");

else strcpy(strchr(stro,'.'),".UUE");

EncodeFile(argv[1],fopen(argv[2],"rb"),(stdout->flags&_F_TERM)?fopen(stro,"at"):stdout);

break;

case 4:strcpy(stro,argv[3]);if(strchr(stro,'.')==NULL)strcat(stro,".UUE");

EncodeFile(argv[1],fopen(argv[2],"rb"),fopen(stro,"at"));break;

default:fprintf(stderr,"Usage:%s name {infile [outfile]|outfile}\n",argv[0]);return 1;

}

fcloseall();return 0;}

xxencode.c

#include

#include

static char encode[]="+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";

#define WRITEBITS(n) putc(encode[(n)&0x3f],outFile)

void EncodeLine(int length,char* line,FILE* outFile){char *p;long l;

WRITEBITS(length);

for(p=line;length>0;p+=3,length-=3){

l=(((long)p[0]&0xff)<<16)|(((long)p[1]&0xff)<<8)|((long)p[2]&0xff);

WRITEBITS(l>>18);WRITEBITS(l>>12);WRITEBITS(l>>6);WRITEBITS(l);}

putc('\n',outFile);}

void EncodeFile(char *name,FILE *inFile,FILE *outFile){char line[80];int i;

fprintf(outFile,"begin 644 %s\n",name);

while((i=fread(line,1,45,inFile))>0)EncodeLine(i,line,outFile);EncodeLine(0,0,outFile);

fprintf(outFile,"end\n");}

main(int argc,char **argv){char stro[256];switch(argc){

case 2:strcpy(stro,argv[1]);if(strchr(stro,'.')==NULL)strcat(stro,".XXE");

else strcpy(strchr(stro,'.'),".XXE");

EncodeFile(argv[1],(stdin->flags&_F_TERM)?fopen(argv[1],"rb"):stdin,(stdout->flags&_F_TERM)?fopen(stro,"at"):stdout);

break;

case 3:strcpy(stro,argv[2]);if(strchr(stro,'.')==NULL)strcat(stro,".XXE");

else strcpy(strchr(stro,'.'),".XXE");

EncodeFile(argv[1],fopen(argv[2],"rb"),(stdout->flags&_F_TERM)?fopen(stro,"at"):stdout);

break;

case 4:strcpy(stro,argv[3]);if(strchr(stro,'.')==NULL)strcat(stro,".XXE");

EncodeFile(argv[1],fopen(argv[2],"rb"),fopen(stro,"at"));break;

default:fprintf(stderr,"Usage:%s name {infile [outfile]|outfile}\n",argv[0]);return 1;

}

fcloseall();return 0;}

uxdecode.c

#include

#include

#include

int decode[256];static char xxe[]="+-0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";

#define VALID(c) (decode[(int)(c)&0xff]>=0)

#define DECODE(c) (decode[(int)(c)&0xff])

void uuinit(void){int i;for(i=0;i<256;i++)decode[i]=-1;

for(i=0;i<64;i++)decode[i+' ']=i;decode['`']=0;decode['~']=0;}

void xxinit(void){int i;for(i=0;i<256;i++)decode[i]=-1;for(i=0;i<64;i++)decode[(int)xxe[i]&0xff]=i;}

void DecodeLine(char *line,int length,FILE *outFile){long l;int i;

while(length>0){l=0;for(i=0;i<4;i++)if(VALID(*line))l=(l<<6)|DECODE(*line++);

else fprintf(stderr,"Illegal char '%c' (%2X)\n",*line,(unsigned int)(*line));

putc((l>>16)&0xff,outFile);if(length>1)putc((l>>8)&0xff,outFile);

if(length>2)putc(l&0xff,outFile);length-=3;}

}

void DecodeFile(FILE *inFile,FILE *outFile){char line[80];int length=0;

do{if(fgets(line,80,inFile)==NULL){fprintf(stderr,"Error reading input.\n");exit(1);}

if(!length)if(strlen(line)!=((DECODE(line[0])+2)/3*4+2))if(DECODE('~'))uuinit();else xxinit();

if((length=DECODE(line[0]))<0)fprintf(stderr,"Illegal line count character '%c' (%2X)\n",line[0],(unsigned int)line[0]);

else DecodeLine(line+1,length,outFile);}while(length>0);fgets(line,79,inFile);

if(strncmp(line,"end",3)!=0)fprintf(stderr,"Final 'end' missing.\n");

}

FILE *FindBegin(FILE *inFile){char line[80],fileName[80];int mode;

do{if(fgets(line,80,inFile)==NULL){fprintf(stderr,"No 'begin' found.\n");exit(1);}

}while(strncmp(line,"begin",5));

sscanf(line,"begin %o %79s",&mode,fileName);printf("Decoding file '%s' mode=%o\n",fileName,mode);

return fopen(fileName,"wb");}

main(int argc,char **argv){int i,ec=0;FILE *f1,*f;uuinit();

if((argc==1)&&(stdin->flags&_F_TERM))fprintf(stderr,"\n%s (C) Kirill I.Jacovlev, Kiev, 1999.\n Using: %s {[...]|< }\n",argv[ec++],argv[0]);

else for(i=1;i<((stdin->flags&_F_TERM)?argc:(argc+1));i++){

if(argc==i)f1=stdin;else f1=fopen(argv[i],"rt");f=FindBegin(f1);

if(f!=NULL){DecodeFile(f1,f);fclose(f);fclose(f1);}

else {fprintf(stderr,"Culdn't open file.\n");ec=1;}}

return ec;}