Протоколы прикладного уровня Информационные службы Интернет
Информационные службы Интернет
Информационные системы Интернет p p p электронная почта система новостей Usenet система файловых архивов FTP гипертекстовая система Gopher система гипермедия WWW информационная система Wais
Cемейство протоколов прикладного уровня стека TCP/IP
Модель взаимодействия клиент-сервер
Электронная почта. Протоколы SMTP и POP 3
Протоколы электронной почты: p p p SMTP (Simple Mail Transport Protocol) POP 3 (Post Office Protocol) IMAP 4 (Internet Mail Access Protocol) Адресация электронной почты имя_пользователя@имя_почтового_домена
Электронная почта Архитектура системы SMTP DА UA
Формат сообщений p p p конверт (невидим для пользователя) заголовок тело сообщения
Заголовок сообщения Заголовок состоит из полей. Поля состоят из имени поля и содержания поля. Имя поля отделено от содержания символом ": ". Минимально необходимыми являются поля: Date, From, cc или To, например: Date: 26 Aug 76 1429 EDT From: Jones@Registry. orgcc: или Date: 26 Aug 76 1429 EDT From: Jones@Registry. org Тo: Smith@Registry. org
Модель работы протокола SMTP команды, ответы и данные Получатель Файловая система Отправитель SMTP Получатель SMTP Файловая система
Алгоритм работы SMTP 1. После установления канала SMTP соединения по любому из транспорт ных протоколов отправитель SMTP посылает команду MAIL, идентифицирующую атрибуты отправителя почты, например, его адрес. Если получатель SMTP может принять почтовое сообщение, он отправляет в ответ команду ОК. 2. После этого отправитель SMTP отправляет команду RCPT, идентифицирующую атрибуты получателя почты, например, адрес почтового ящика. Если получатель SMTP готов принять почту в данный почтовый ящик, он отвечает командой ОК, если нет, он отвечает отказом принять почту в указанный почтовый ящик. Если отправитель указал несколько почтовых ящиков, в которые следует поместить сообщение, то получатель SMTP может отказать части из них, при этом транзакция соединения не заканчивается. 3. Отправитель SMTP отправляет данные получателю SMTP. Если получатель успешно принял все данные, он отправляет команду ОК.
Взаимодействие SMTP с транспортным протоколом TCP Как правило, SMTP-канал использует TCP-соединение между отправителем SMTP — машиной пользователя, на которой порт SMTPсоединения может быть выбран произвольно, и SMTP-сервером, который, по умолчанию, использует порт 25. TCP-соединение поддерживает передачу 8 -битных символов. Если SMTP использует для передачи 7 -битные ASCII-символы, каждый из них передается по ТСР-каналу как 8 бит со старшим битом равным 0. 8 -битные SMTP-данные передаются без изменений. SMTP-команды и данные инкапсулируются в поле данных TCP в соответствии с обычными механизмами инкапсуляции стека протоколов TCP/IP. Более подробную информацию о протоколе SMTP и форматах почтовых сообщений MIME можно найти в: RFC-1341, RFC-1342, RFC-1426, RFC-1521, RFC-1806, RFC-1830, RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049, RFC-2076, RFC-788, RFC-821, RFC-822.
Протокол работы Для открытия простейшей SMTP транзакции отправки и получения почтового сообщения необходимо, чтобы между отправителем SMTP и получателем SMTP были установлены: 1. Транспортное соединение, например, TCP или UDP, или Х 25. 2. SMTP соединение устанавливается между отправителем и получателем SMTP по готовому транспортному каналу. Этот процесс включает в себя обмен сообщениями открытия SMTP канала. HELO <SP> <domain> <CRLF> Команда HELO отправляется инициирующим открытие соединения хостом, как правило, это хост отправителя, который идентифицирует себя через параметр <domain>. Ответом является код 250 с именем отвечающего домена. Для того чтобы завершить сеанс SMTP, достаточно отправить команду QUIT. Например: QUIT R: 221 AH-UNIX. ARPA Service closing transmission channel Для того чтобы прервать текущую SMTP-транзакцию и очистить все буферы отправителя и получателя данной транзакции (т. е. перезагрузить SMTP соединение), используется команда RSET. Она может применяться, например, при зацикливаниях квитирующих сообщений доставки.
Основные команды p Команда MAIL: MAIL <SP> FROM: <reverse-path> <CRLF> где <SP> — символ пробела, <CRLF> — перевод строки, <reverse path> — имя почтового ящика отправителя сообщения. В случае возникновения ошибки получатель SMTP отправляет по адресу <reverse path> уведомление о невозможности открытия транзакции. Если транзакция SMTP открыта успешно, "250 OK", где 250 — код возврата успешного выполнения команды. p Вторым шагом процесса передачи почты будет команда RCPT: RCPT <SP> T 0: <forward-path> <CRLF> где <forward path> — имя почтового ящика получателя почты. Если какой либо из получателей неизвестен в передающей системе, возвращается код 550 — "на указанный адрес почта не может быть отправлена — пользователь не существует". Если пользователь найден, отправителю возвращается код "250 OK". p На третьем шаге транзакции передается команда DATA: DATA <CRLF> На эту команду получатель SMTP возвращает код 354, означающий готовность принимать данные. После этого отправитель начинает передавать текст сообщения: заголовок и тело сообщения. Каждая строка сообщения заканчивается символом <CRLF>. При получении строки окончания передачи текста — последовательности <CRLF> получатель возвращает код "250 OK". Это означает, что все данные приняты.
Синтаксис команд p p Допустимо написание команд строчными или прописными символами, например: MAIL, Mail, mail, Ma. Il или m. AIl. Для того чтобы программа SMTP сервера была работоспособна, она должна понимать следующий минимум команд: n p p p HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT Предельная длина имени пользователя или домена равна 64 символам. Максимальная длина или составляет 256 символов, включая разделители (пробелы, точки, запятые и пр. ). Командная строка не должна быть длиннее 512 символов. Максимальный размер строки отклика не должен превышать, включая его код, 512 символов. Максимальная длина строки составляет 1000 символов. Предельно допустимое число адресатов равно 100, последнее полезно помнить, если вы храните этот список в файле.
Коды ответа p p p Структура кодов строго определена, обработка определенной команды может вернуть только строго определенные для нее коды возврата. Все коды возврата построены по определенной структуре и образуют сложную иерархическую систему. Каждая цифра или комбинация цифр кода возврата несет в себе информацию о породивших ее условиях. Подробное описание этой структуры можно найти в RFC, например, RFC 821.
Коды ответа на последовательность команд 211 System status, or system help reply 214 Help message [Information on how to use the receiver or the meaning of a particular non standard command; this reply is useful only to the human user] 500 Syntax error, command unrecognized [This may include errors such as command line too long] 501 Syntax error in parameters or arguments 502 Command not implemented 503 Bad sequence of commands 504 Command parameter not implemented
Коды состояния службы эл. почты 220 <domain> Service ready 221 <domain> Service closing transmission channel 421 <domain> Service not available, closing transmission channel [This may be a reply to any command if the service knows it must shut down]
Коды ответа на запрос 250 Requested mail action okay, completed 251 User not local; will forward to <forward path> 354 Start mail input; end with <CRLF> 450 Requested mail action not taken: mailbox unavailable [E. g. , mailbox busy] 451 Requested action aborted: error in processing 452 Requested action not taken: insufficient system storage 550 Requested action not taken: mailbox unavailable [E. g. , mailbox not found, no access] 551 User not local; please try <forward path> 552 Requested mail action aborted: exceeded storage allocation 553 Requested action not taken: mailbox name not allowed [E. g. , mailbox syntax incorrect] 554 Transaction failed
Пример передачи сообщения Пример показывает передачу почты от пользователя Smith, домена "Alpha. ARPA" пользователям домена "Beta. ARPA". S MAIL FROM: <Smith@Alpha. ARPA> R 250 OK S RCPT TO: <Jones@Beta. ARPA> R 250 OK S RCPT TO: <Green@Beta. ARPA> R 550 No such user here S RCPT TO: <Brown@Beta. ARPA> R 250 OK S DATA R 354 Start mail input; end with <CRLF> S hey hey. . . S. . . how do you do. Beta ? S <CRLF> R 250 OK S QUIT R 221 OK
Ретрансляция сообщений p p В огромной сети Internet очень редко удается отправить сообщение адресату напрямую. Как правило, используются SMTP серверы, которые выполняют роль промежуточных пунктов пересылки сообщений. SMTP серверы принимают всю поступившую на них почту (если администратором SMTP сервера не установлены ограничения) и затем, самостоятельно, переправляют ее адресату. Этот процесс и называется ретрансляцией сообщений. SMTP серверы выбирают путь сообщения по своему усмотрению в зависимости от параметров настройки, скорости доступа и т. д. Протокол SMTP позволяет отправителю сообщения самостоятельно указывать путь передачи сообщения, устанавливая в качестве параметров команды отправки промежуточные SMTP серверы. Параметр <forward path> команды RCPT может содержать не только имя почтового ящика получателя, но и путь к этому почтовому ящику через SMTP серверы, например: S: RCPT TO: <@ONE, @TWO: Jones@THREE> где "ONE", "TWO", "THREE" имена хостов ("ONE" и "TWO" имена промежуточных хостов, "Jones@THREE" — имя почтового ящика адресата на хосте "THREE")
Механизм ретрансляции сообщений состоит в следующем: 1. Сообщение передается SMTP серверу, стоящему первым на пути передачи (хост "ONE"). После принятия этим сервером сообщения, он перемещает свой идентификатор из пути передачи и ставит его в строку обратного пути <reverse path> (определенный в команде MAIL). 2. Затем сервер, получивший данное сообщение становится отправителем SMTP и передает сообщение по адресу хоста, стоящего первым в пути передачи (это будет теперь хост "TWO"). Теперь это сообщение с измененными параметрами <forward path> и '<reverse path> отправляется на следующий по маршруту хост. 3. Далее все повторяется, пока сообщение не дойдет до адресата (т. е. параметр <forward path> станет равным пустой строке).
![Пример SMTP-сессии (1) Сonnect from mail-relay 1. elsevier. co. uk [193. 131. 223. 5]](https://present5.com/presentation/36124583_153180171/image-25.jpg "Пример SMTP-сессии (1) Сonnect from mail-relay 1. elsevier. co. uk [193. 131. 223. 5]")
Пример SMTP-сессии (1) Сonnect from mail-relay 1. elsevier. co. uk [193. 131. 223. 5] 220 ns 1. hmti. ac. by ESMTP Sendmail 8. 12. 2/8. 12. 2; Fri, 14 May 2004 17: 38: 53 +0300 < EHLO mail relay 1. elsevier. co. uk 250 ns 1. hmti. ac. by Hello mail relay 1. elsevier. co. uk [193. 131. 223. 5], pleased to meet you. 250 ENHANCEDSTATUSCODES 250 PIPELINING 250 EXPN 250 VERB 250 8 BITMIME 250 SIZE 17000000 250 DSN 250 ETRN 250 DELIVERBY 250 HELP
Пример SMTP-сессии (2) < MAIL FROM: <C. Jones@elsevier. com> SIZE=304717 RET=FULL 250 2. 1. 0 <C. Jones@elsevier. com>. . . Sender ok < RCPT TO: <vll@ns 1. hmti. ac. by> NOTIFY=FAILURE, DELAY 250 2. 1. 5 <vll@ns 1. hmti. ac. by>. . . Recipient ok < DATA 354 Enter mail, end with ". " on a line by itself 250 2. 0. 0 i 4 EEcrr. J 013462 Message accepted for delivery < QUIT 221 2. 0. 0 ns 1. hmti. ac. by closing connection
Ограничения RFC 822 p p p RFC 822 определяет только формат заголовков, но оставляет содержимое сообщения полностью на усмотрение пользователей. Но в настоящее время требуется обеспечить возможность отправления сообщений со следующими характеристиками. 1. Сообщения на языках с надстрочными знаками (например, на французе немецком, испанском и т. д. ). 2. Сообщения на языках, использующих нелатинские алфавиты (наприме русском, арабском, иврите). 3. Сообщения на иероглифических языках (например, китайском, японс корейском). 4. Сообщения, вообще не являющиеся текстом (например, аудио и видео).
Спецификация MIME Решение было предложено в документе RFC 1341, а более новая редакция этого предложения была опубликована в RFC 1521. Это решение, получившее название MIME (Multipurpose Internet Mail Extensions — многоцелевые расширения электронной почты в Интернете), широко применяется в настоящий момент. MIME – расширение позволяет продолжить использование формата RFC 822, но с добавлением структуры к телу сообщения и с определением правил кодировки не АSCII сообшений. Не отклоняясь от стандарта RFC 822, MIME сообщения могут передаваться с помощью обычных почтовых программ и протоколов. Все, что нужно изменить, — это отправляющие и принимающие программы. Таким образом MIME – расширение: n n n расширяет способ формирования сообщений определяет новый формат передачи данных вводит ряд новых заголовков сообщения
Заголовки MIME p MIME Version: Указывает версию стандартов MIME. p Content Description: Описание содержимого. Строка обычного текста, информирующая о содержимом сообщения. Content Id: Уникальный идентификатор. p Content Transfer Encoding: p Content Type: Тип содержимого сообщения. p Указывает способ кодировки тела сообщения для его передачи.
Заголовок Content-Transfer-Encoding Синтаксис: "Content-Transfer-Encoding" ": " mechanism Mechanism : = "7 bit" / "8 bit" / "binary" / "quoted-printable" / "base 64" / ietftoken / x-token Описывает способ упаковки тела сообщения для его передачи по сети, которая может возражать против символов, отличных от букв, цифр и знаков препинания. Разработаны пять схем (плюс возможность добавления новых схем): Схемы передачи текстовых сообщений: p 7 битный ASCII-текст. Символы ASCII используют 7 разрядов и могут передаваться на прямую протоколом электронной почты, при условии, что строка не превышает 1000 символов. p 8 битный ASCII-текст. Сообщения, использующие 8 разрядную кодировку, также должны соблюдать правило о максимальной длине строки.
Схемы передачи двоичных данных. p p p Схемы передачи двоичных данных. К ним относятся произвольные двоичные файлы, которые не только используют все 8 разрядов в байте, но также и не соблюдают ограничение на 1000 символов в строке. quoted-printable. Для сообщений, почти полностью состоящих из символов ASCII, но с небольшими включениями нe ASCII символов, подобный метод несколько неэффективен. Вместо него лучше применять кодировку quoted printable (цитируемое печатное кодирование). Этот метод напоминает расширенный текстовый формат файлов RTF (Rich Text Format). При его использовании все ASCII символы остаются ASCII символами, а остальные символы (например, те, что больше 127) кодируются в виде знака равенства, за которым следует шестнадцатеричное представление самого символа. Base 64. При использовании данного метода группы по 24 бита разбиваются на четыре 6 разрядные единицы, каждая из которых посылается в виде обычного разрешенного ASCII символа. В этой кодировке 6 разрядный символ 0 кодируется ASCII символом «А» , 1 — ASCII символом «В» и т. д. Символы возврата каретки и переноса строки игнорируются, что позволяет разбивать закодированные в формате Base 64 файлы на строки произвольной длины, в том числе и короче 1000 символов. С помощью этого метода можно надежно посылать любые двоичные файлы.
Типы данных, определенные в RFC 1521 Стандарт MIME определяет семь типов данных, которые можно передавать в теле письма: текст (text); смешанный тип (multipart); почтовое сообщение (message); графический образ (image); аудиоинформация (audio); фильм или видео (video); приложение (application).
MIME типы и подтипы определенные в RFC 2045.
Протоколы доставки сообщений POP 3, IMAP 4
Протокол РОРЗ (RFC 1225) РОРЗ — это простейший протокол для работы пользователя с содержимым своего почтового ящика. Он позволяет только забрать почту из почтового ящика сервера на рабочую станцию клиента и удалить ее из почтового ящика на сервере. Всю дальнейшую обработку почтовое сообщение проходит на компьютере клиента. РОРЗ сервер не отвечает за отправку почты, он работает только как универсальный почтовый ящик для группы пользователей. Когда пользователю необходимо отправить сообщение, он должен установить соединение с каким либо SMTP сервером и отправить туда свое сообщение по SMTP. Этот SMTP сервер может быть как тем же хостом, где работает РОРЗ сервер, так и может располагаться совсем в другом месте (в другом домене или, вообще говоря, где угодно в Initernet).
Принципы работы POP 3 1. РОРЗ сервис, как правило, устанавливается на 110 й ТСР порт сервера, который будет находится в режиме ожидания входящего соединения. Когда клиент хочет воспользоваться РОРЗ сервисом, он просто устанавливает TCP соединение с портом 110 этого хоста. 2. После установления соединения сервис РОРЗ отправляет подсоединившемуся клиенту приветственное сообщение. После этого клиент и сервер начинают обмен командами и данными. 3. По окончании обмена РОРЗ канал закрывается.
РОРЗ-сессия 1. Как только открывается TCP соединение и РОРЗ сервер отправляет приветствие, сессия должна быть зарегистрирована — состояние аутентификации (AUTHORIZATION state). Клиент должен зарегистрироваться в РОРЗ сервере, т. е. ввести свой идентификатор и пароль. 2. После этого сервер предоставляет клиенту его почтовый ящик и открывает для данного клиента транзакцию — состояние начала транзакции обмена (TRANSACTION state). На этой стадии клиент может считать и удалить почту своего почтового ящика. 3. После того как клиент заканчивает работу (передает команду QUIT), сессия переходит в состояние UPDATE — завершение транзакции. В этом состоянии РОРЗ сервер закрывает транзакцию данного клиента и закрывает TCP соединение. 4. В случае получения неизвестной, неиспользуемой или неправильной команды, РОРЗ сервер должен ответить отрицательным состоянием индикатора и закрывает TCP соединение, не переходя в состояние UPDATE. РОРЗ сервер может использовать в своей работе таймер контроля времени соединения. Этот таймер отсчитывает время "бездействия" ("idle") клиента в сессии от последней переданной команды. Если время сессии истекло, сервер закрывает TCP соединение, не переходя в состояние UPDATE.
Протокол работы, основные команды Открытие сессии: При открытии TCP соединения РОРЗ клиентом, РОРЗ сервер отправляет сообщение приветствия: S: +OK РОРЗ server ready Теперь РОРЗ сессия находится в состоянии аутентификации (AUTHORIZATION), и клиент должен зарегистрировать себя на РОРЗ сервере. Это может быть выполнено либо с помощью команд USER и PASS — ввод открытых пользовательского идентификатора и пароля (именно этот способ используется чаще), либо командой АРОР — аутентификация цифровой подписью, на базе секретного ключа. Любой РОРЗ сервер должен поддерживать хотя бы один из механизмов аутентификации.
Команда USER Авторизация пользователя: Команда USER имеет следующий формат: USER name Аргументом — "name" является строка, идентифицирующая почтовый ящик системы. Этот идентификатор должен быть уникальным в данной почтовой системе РОРЗ сервера. Если ответом на эту команду является строка инди катора "+OK", клиент может отправлять команду PASS — ввод пароля или QUIT — завершить сессию. Если ответом является строка " ERR", клиент может либо повторить команду USER, либо закрыть сессию. Примеры использования команды: С: USER frated , S: ERR sorry, no mailbox for frated here ИЛИ С: USER mrose S: +OK mrose is a real hoopy frood
Команда PASS используется только после положительного ответа на команду USER: PASS string Аргументом команды является строка пароля данного почтового ящика. После получения команды PASS, РОРЗ сервер, на основании аргументов команд USER и PASS, определяет возможность доступа к заданному почтовому ящику. Если РОРЗ сервер ответил "+OK", это означает, что аутентификация клиента прошла успешно и он может работать со своим почтовым ящиком, т. е. сессия переходит в состояние TRANSACTION. Если РОРЗ сервер ответил " ERR", то либо был введен неверный пароль, либо не найден указанный почтовый ящик: С: USER mrose S: +OK mrose is a real hoopy frood С: PASS secret S: ERR maildrop already locked ИЛИ С: USER mrose S: +OK mrose is a real hoopy frood C: PASS secret S: +OK mrose's maildrop has 2 messages (320 octets)
Команда APOP Команда аутентификации пользователя АРОР не входит в список обязательно реализуемых команд РОРЗ сервера. Эта команда предоставляет значительно больший (по сравнению с командами USER или PASS) уровень защиты аутентификации пользователя при открытии сессии AUTHORIZATION и используется только тогда, когда к обеспечению конфиденциальности доступа к информации почтовых ящиков предъявляются повышенные требования. АРОР name digest Аргуменами команды являются: name — имя пользователя (то же, что и в команде USER), digest — шифрованная (по алгоритму MD 5) строка пароля. Применяемый здесь алгоритм необратимого шифрования для построения секретного ключа использует открытый ключ и временную метку. Временные метки передаются хосту клиента вместе с сообщением приветствия. Например, для UNIX машин временная метка может иметь вид: <process ID. clock@hostname>, где process ID — это идентификатор процесса, clock — состояние таймера на момент установления соединения, hostname — имя компьютера РОРЗ сервера. Этот механизм позволяет достичь очень высокой степени защищенности. S: +OK РОРЗ server ready <1896. 697170952@dbc. mtview. ca. us> С: АРОР mrose c 4 c 9334 bac 560 ecc 979 e 58001 b 3 e 22 fb S: +OK maildrop has 1 message (369 octets) Алгоритм на основании открытого ключа "tanstaaf и временной метки <1896. 697170952@dbc. mtview. ca. us> построил шифрованную строку "c 4 c 9334 bac 560 ecc 979 e 58001 b 3 e 22 fb".
Команда STAT (без аргументов) используется для просмотра состояния текущего почтового ящика. В ответ РОРЗ сервер возвращает строку, содержащую количество и общий размер в байтах сообщений, которые клиент может получить с РОРЗ сервера. Сообщения, помеченные на удаление, не учитываются. Формат ответа: "+ОК nn mm", где nn — количество сообщений, mm — их общий объем: С: STAT S: +ОК 2 320 РОРЗ сервер сообщает, что в данном почтовом ящике находятся два сообщения общим объемом 320 байт.
Команда LIST может передаваться как с аргументом msg — номером сообщения, так и без аргумента: LIST [msg] Если команда содержит аргумент, и сообщение с указанным номером существует, ответом на нее будет "информационная строка", которая содержит номер сообщения и размер сообщения в байтах. Если аргумент не указан — ответом будет список информационных строк обо всех сообщениях в данном почтовом ящике. Сообщения, помеченные на удаление не фигурируют в этом списке: С: LIST S: +ОК 2 messages (320 octets) S: 1 120 S: 2 200 S: . ИЛИ С: LIST 2 S: +ОК 2 200 ИЛИ С: LIST 3 S: ERR no such message, only 2 messages in maildrop
Команда RETR — используется для передачи клиенту запрашиваемого сообщения: RETR msg Аргумент команды — номер сообщения. Если запрашиваемого сообщения нет, возвращается отрицательный индикатор " ERR". С: RETR 1 S: +ОК 120 octets S: <text message> S: .
Команда DELE После получения, сообщение, как правило, помечается на удаление из почтового ящика, при этом используется команда DELE: DELE msg Аргумент команды— номер сообщения. Сообщения, помеченные на удаление, реально удаляются только после закрытия транзакции, на стадии UPDATE. С: DELE 1 S: +ОК message 1 deleted или С: DELE 2 S: ERR message 2 already deleted
Команды NOOP, RSET, QUIT NOOP – исп ся для проверки состояния соединения с РОРЗ сервером. C: noop S: +OK RSET исп ся для отката транзакции внутри сессии. Если пользователь случайно пометил на удаление какие либо сообщения, он может убрать эти пометки, отправив эту команду: С: RSET S: +OK maildrop has 2 messages (320 octets) QUIT – завершение сессии. После того как пользователь проделал в режиме TRANSACTION все необходимые действия, он должен перейти в режим UPDATE. Для этого клиент РОРЗ отправляет команду QUIT. По этой команде все сообщения, помеченные на удаление, реально уничтожаются в почтовом ящике. Если сессия TRANSACTION завершается каким либо другим способом (сбой сервера, сети или др. ) никаких изменений в состоянии почтового ящика не происходит. С: QUIT S: +ОК dewey POP 3 server signing off
Протокол IMAP 4. 1 p p Протокол IMAP 4. 1 (INTERNET MESSAGE ACCESS PROTOCOL VERSION 4 rev 1, V. Crispin, RFC 2060, December 1996) базируется на транспортном протоколе TCP и использует порт 143. Протокол IMAP представляет собой альтернативу POP 3. Также как и последний он работает только с сообщениями и не требует каких либо пакетов со специальными заголовками.
Отличия IMAP 4 от POP 3 p p p IMAP 4 был разработан с целью помочь пользовать пользующемуся несколькими компьютерами, например рабочей станцией в оффисе, персональным компьютером дома и лэптопом в пути. Основная идея, лежащая в основе протокола IMAP, состоит в том, что на почтовом сервере устраивается центральное хранилище, к которому можно получить доступ с любой машины. Таким образом, в отличие от протокола РОРЗ, протокол IMAP не копирует автоматически электронную почту на персональную машину пользователя, так как у пользователя может быть несколько машин. Протокол IMAP обладает разнообразными возможностями, как, например способность упорядочивать почту не по порядку ее поступления, а по атрибутам писем (например, сначала дайте мне письмо от Сергея). Таким образом, подобный почтовый ящик более похож на реляционную базу данных нежели на линейную последовательность сообщений.
Сравнение POP 3 и IMAP
Списки рассылки строятся на базе системы электронной почты. Список рассылки имеет 2 адреса: n n адрес подписки адрес отправки сообщений
Скачать презентацию Протоколы прикладного уровня Информационные службы Интернет Информационные
кс_2009_16_Эл.почта Интернет.ppt