Berkrley Internet Name Domain. Иногда для этой цели выделяют специальную машину задача
| Вид материала | Задача |
- Поурочне планування курсу "Основи Інтернет – технологій", 88.8kb.
- Работа nat введение, 150.17kb.
- 1. Сервіси Internet, 731.38kb.
- 1. Сервіси Internet, 347.99kb.
- Internet Information Services (iis). Понимание организации сетей, tcp/ip и Domain Name, 17.07kb.
- Что такое Internet? Ресурсы Internet*, 347.7kb.
- Лабораторна робота №19 ”Internet”, 103.46kb.
- Е. Е. Израилевич Практическая грамматика английского языка с упражнениями и ключами, 14711.83kb.
- Математическая логика сквозь школьные предметы, 133.29kb.
- Мифы и реальности Internet известные и скрытые возможности сети Что такое Internet, 306.75kb.
r from to user -options size
Это запрос клиента на получение файла от сервера. Параметр from - имя файла на сервере. Это не может быть spool-файл, имя не может иметь символов подмены (wildcard). Параметр to - имя файла, который должен появиться у клиента, user - имя пользователя, инициировавшего обмен, options - список опций, контролирующих обмен, size - определяет максимальный размер файла, который может принять клиент. Допускаются следующие опции.
| d | клиент должен создать каталог, если необходимо (по умолчанию); |
| f | клиент не должен создать каталог, если необходимо,вместо этого он должен прервать сессию; |
| m | клиент должен послать e-mail по адресу user в случае успешного завершения обмена. |
Сервер может прислать следующие отклики на r-команду.
| Отклик | Описание |
| ry mode [size] | Сервер готов послать файл и начинает эту процедуру. Аргумент mode - восьмеричный код модификатора файла на сервере. Для некоторых версий bsd uucp аргумент mode может иметь в конце символ М, означающий, что сервер хочет стать клиентом и выдать команду-запрос |
| rn2 | Сервер не может послать файл, так как это запрещено или потому, что такой файл отсутствует |
| rn6 | Используется версией taylor uucp. Файл слишком велик (например, не соответствует ограничениям клиента) |
| rn9 | Используется версией taylor uucp и fsuucp. Удаленная система не может открыть еще один канал. Можно попробовать позднее |
По завершении обмена клиент может послать следующие команды (сервер их может проигнорировать).
cy файл благополучно передан;
cn5 временный файл не может быть перемещен в окончательную позицию.
Клиент может использовать команду x для запуска uucp на сервере. Команда может иметь формат x from to user -options. Параметр from - имя файла (или файлов) на ЭВМ-сервере, пересылку которого затребовал клиент. Команда может служить для пересылки файлов из сервера посторонней третьей системе. Параметр to является именем файла или каталога, куда будут перенесен файл (или файлы). Например, если клиент хочет получить файлы сам, можно использовать запись master!path. Сервер может прислать следующие отклики на команду x.
xy запрос принят, соответствующие команды пересылки файлов поставлены в очередь для последующего исполнения.
xn Запрос отклонен (причина отклонения не сообщается, может быть сервер не поддерживает Х-запросы).
Клиент может послать команду Е, которая имеет следующий формат:
e from to user -options temp mode notify size command
Е-команда поддерживается системой taylor uucp и служит для реализации запросов исполнения без использования файлов x.*. Эта команда применяется в случае, когда исполняемая команда требует входного файла, который используется ей в качестве стандартного ввода. Основные параметры команды имеют то же значение, что и в случае команды s. Список опций, управляющих обменом, представлен в таблице.
| Опция | Описание |
| c | Файл копируется в каталог spool (клиент должен использовать temp, а не from) |
| c | Файл не копируется в каталог spool (по умолчанию) |
| n | e-mail сообщение не посылается даже в случае неудачи. Это эквивалентно n-команде в файле x.*. |
| z | Е-mail сообщение посылается, если при исполнении команды произошла ошибка (значение по умолчанию). Эквивалентно команде z в файле Х.* |
| r | Е-mail сообщение о результате выполнения посылается адресату, записанному в параметре notify. Эквивалентно команде r в файле Х.* |
| e | Исполнение должно проводиться с /bin/sh. Эквивалентно команде e файла Х.*. |
В поле command записывается команда, которая должна быть исполнена. Это эквивалентно команде c файла Х.*. Отклики сервера на Е-команду эквивалентны откликам на команду s, только начальное s заменяется на Е.
Для переведения соединения в пассивное состояние клиент может использовать h-команду (не имеет параметров или опций). Сервер реагирует на нее h-откликом.
| hy | сервер согласен заблокировать обмен. В некоторых пакетах uucp клиент также посылаете команду hy. После этого стартует процедура закрытия канала. |
| hn | Сервер не готов заблокировать обмен. После этого клиент и сервер меняются ролями, такой обмен ролями возможен несколько раз за время сессии. |
Если обмен завершен и клиент не намерен выдавать какие-либо запросы, связь прерывается. Клиент посылает сообщение \020ОООООО\000, на что сервер откликается посылкой строки \02ООООООО\000 (6 символов ‘О’ в первом и 7 - во втором случае). Какой-либо смысловой нагрузки этот обмен не несет, по этой причине некоторые пакеты его не производят.
В рамках UUCP предусмотрено несколько вспомогательных протоколов.
g-протокол предназначен для коррекции ошибок и поддерживается всеми версиями UUCP. Стандартная ширина окна в этом протоколе равна 3, а размер пакета 64 байтам, но в принципе предусмотрена возможность расширения окна при реализации потоков до 7 при размере пакетов 4096 байт. Протокол базируется на стандартных пакетных драйверах. Для реализации g-протокола используются пакеты с 6-байтовыми заголовками (управляющие пакеты содержат только заголовок). Формат этих пакетов представлен на рис. 4.4.14.1.1.
Рис. 4.4.14.1. Формат пакетов g-протокола
Пакет начинается с восьмеричного кода 020, далее следует поле k (1 k 9). Для управляющих пакетов k=9. Для информационных пакетов k определяет размер поля данных. k=1 соответствует 32 байтам данных, а k=9 - 4096 байтам. Далее следуют два байта контрольной суммы, контрольный байт, определяющий тип пакета, и xor-байт. Последний равен результату операции xor для полей k, младшего байта контрольной суммы, старшего байта контрольной суммы и контрольного байта. Этот байт служит для контроля целостности заголовка пакета.
Управляющий байт заголовка содержит в себе три субполя (ttxxxyyy). Поле tt может принимать следующие значения.
| 0 | Указатель управляющего пакета (k должно быть равно 9). При этом поле xxx определяет тип управляющего пакета; |
| 1 | Не используется UUCP; |
| 2 | Информационный пакет; |
| 3 | Короткий информационный пакет. |
Пусть длина поля данных, заданная k, равна 1, пусть также первый байт поля данных равен b1. Если b1 меньше 128, тогда истинное число байт в поле данных равно 1 - b1, начиная со второго байта. Если b1 128 и второй байт поля данных b2, то истинное число байт в поле данных равно 1 - ((b1 & 0x7f) + (b2 << 7)), начиная с третьего байта. Контрольная сумма вычисляется для всех байтов поля данных.
Один байт данных пересылается в любом случае. Для всех типов информационных пакетов поле ххх определяет порядковый номер пакета, а поле yyy определяет номер последнего пакета, принятого без ошибки, что и определяет максимальный размер окна, равный 7. Каждая из сторон, участвующих в обмене, использует окно, чтобы регистрировать число пакетов, которое может быть послано без получения подтверждения. Размер этого окна может лежать в пределах 1-7. Пакеты посылаются строго по очереди, получение всех пакетов должно быть подтверждено в том порядке, в каком они были посланы.
В пакетах управления поле ххх может принимать следующие значения:
| CLOSE | Соединение должно быть оборвано немедленно (например, обнаружено слишком много ошибок). |
| RJ или NAK | Последний пакет доставлен с ошибкой. В поле ууу записан номер последнего пакета, доставленного корректно. |
| SRJ | Выборочный отказ. Поле ууу содержит номер пакета, доставленного с ошибкой. Пакет должен быть послан повторно. В UUCP обычно не используется. |
| RR или ACK | Подтверждение получения пакета. Поле ууу содержит код номера последнего пакета, полученного корректно. |
| INITA | Первый пакет инициализации. Поле ууу содержит код максимального размера окна. |
| INITB | Второй пакет инициализации. Поле ууу содержит код размера пакетов, который планируется использовать. |
| INITC | Третий пакет инициализации. Поле ууу содержит размер окна, который будет использован. |
Контрольная сумма управляющего пакета равна 0хаааа - с, где с - контрольный байт заголовка. Контрольная сумма информационного пакета равна 0хаааа - (check c), где обозначает операцию исключающее ИЛИ, а check результат работы программы, приведенной ниже и обрабатывающей поле данных. Исходными параметрами для этой программы является указатель на начало блока данных z и число байтов в блоке c.
Int
igchecksum (z, c)
| | register const char *z; |
| | register int c; |
{
| | register unsigned int ichk1, ichk2; |
| | ichk1 = 0xffff; |
| | ichk2 = 0; |
| | do |
| | { |
| | register unsigned int b; |
/* rotate ichk1 left. */
| | if ((ichk1 & 0x8000) == 0) | |
| | | ichk1 <<= 1; |
| | else | |
| | | { |
| | ichk1 <<= 1; | |
| | ++ichk1; | |
| | } |
/* add the next character to ichk1. */
| | b = *z++ & 0xff; |
| | ichk1 += b; |
/* add ichk1 xor the character position in the buffer counting from the back to ichk2. */
ichk2 += ichk1 c; /* if the character was zero, or adding it to ichk1 caused an overflow, xor ichk2 to ichk1. */
| | if (b == 0 || (ichk1 & 0xffff) < b) |
| | ichk1 = ichk2; |
| | } |
| | while (--c > 0); |
| | return ichk1 & 0xffff; |
}
Когда g-протокол запускается в работу, посылается управляющий пакет INITA с кодом желательного значения максимального размера окна. Сервер откликается пакетом INITA со своим предложением размера окна. После этого аналогичный обмен производится пакетами INITB и INITC. В результате каждая из сторон может использовать свой размер окна и длину посылаемых пакетов.
Когда UUCP выдает команду, посылается один или более пакетов. В конце команды всегда посылается нулевой байт, который указывает на завершение командной строки. Когда пересылается файл, его завершение отмечается коротким информационным пакетом, содержащим нули. Прекращение работы протокола осуществляется посылкой управляющего пакета close.
f-протокол. Этот протокол предназначен для пересылки 7-битных текстовых файлов. Здесь используются только символы от \040 (пробел) до \176 (~) и возврат каретки. Протокол весьма не эффективен для транспортировки 8-битовых данных. Его система контрольного суммирования не слишком надежна для больших файлов. Первоначально этот протокол предназначался для работы в сетях Х.25. В f-протоколе не предусмотрена процедура инициализации. При пересылке команды передается строка, завершающаяся символом возврат каретки. В процессе передачи файлов каждый байт b преобразуется в соответствии с таблицей.
| 0 | <= b <= 037: | 0172, b + 0100 | (0100 дo 0137) |
| 040 | <= b <= 0171: | b | (040 до 0171) |
| 0172 | <= b <= 0177: | 0173, b - 0100 | ( 072 до 077) |
| 0200 | <= b <= 0237: | 0174, b - 0100 | (0100 до 0137) |
| 0240 | <= b <= 0371: | 0175, b - 0200 | ( 040 до 0171) |
| 0372 | <= b <= 0377: | 0176, b - 0300 | ( 072 до 077) |
Таким образом, байты между \040 и \171 включительно передаются без изменений, остальные перед отправкой преобразуются. Когда файл данных переслан, посылается 7-байтовая последовательность, включающая в себя два байта \176, за которыми следует 4 ASCII байта контрольной суммы (в шестнадцатеричном формате) и символ возврата каретки. Если контрольная сумма равна 0x1a2b, то будет послана последовательность \176\1761a2b\r.
При вычислении контрольной суммы туда сначала заносится код 0xffff. Для вычисления контрольной суммы (ichk) используется следующая программа, которая выполняется перед отправкой каждого байта.
/* rotate the checksum left. */
| | if ((ichk & 0x8000) == 0) |
| | ichk <<= 1; |
| | else |
| | { |
| | ichk <<= 1; |
| | ++ichk; |
| | } |
/* add the next byte into the checksum. */
| | ichk += b; |
Принимающая файл сторона также вычисляет контрольную сумму данных и сравнивает ее с полученной по каналу. По результату этого сравнения передающей стороне посылается одно-символьный отклик, за которым следует код возврата каретки.
| G | Файл принят без ошибок; |
| R | Ошибка в контрольной сумме, файл надо передать повторно; |
| Q | Контрольная сумма неверна, но уже совершено много попыток и сессию следует прервать |
t-протокол. Протокол предназначен для каналов, обеспечивающих надежную связь по схеме точка-точка (аналог TCP) для 8-битных данных. При посылке команды сначала определяется ее длина с. Затем посылается (с/512 +1)*512 байт, которые включают в себя строку команды и соответствующее число нулевых байтов. При пересылке файлов обмен идет блоками по 1024 байта. Каждый блок начинается с 4 байтов, характеризующих объем данных в блоке (формат аналогичен используемому UNIX-утилитой htonl). В конце файла передается блок нулевых байтов.
e-протокол. Протокол подобен t-протоколу. Но здесь нет управления потоком и контроля ошибок. При посылке команды передается командная строка, завершающаяся нулевым байтом. При пересылке файла сначала посылается код его размера в виде ASCII десятичных цифр. Эта строка дополняется до 20 символов нулевыми байтами. Так, если длина файла 40000 байт, сначала посылается последовательность 40000\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0, после чего посылается собственно файл.
G-протокол. Протокол используется SVR4 UUCP. Он идентичен G-протоколу за исключением того, что можно модифицировать окно и размер пакетов. В SVR4 реализации G-протокола размер окна всегда равен 7 а длина пакета 64 байтам.
i-протокол. Протокол написан Яном Лансом Тейлором и использован в taylor UUCP. Это протокол пересылки данных со скользящим окном, подобно G-протоколу. Но в отличие от этого протокола i-протокол поддерживает обмен данными в двух направлениях одновременно. Пакеты в этом протоколе имеют 6-байтовый заголовок. За полем данных следует 4-байтовая контрольная сумма. Определено 5 типов пакетов: DATA, SYNC, ACK, NAK, SPOS и CLOSE. Все они могут содержать поле данных. Пакеты типа DATA, SPOS и CLOSE имеют порядковые номера. Каждая из сторон нумерует пакеты независимо по модулю 32. Каждый из пакетов характеризуется локальным и удаленным номерами каналов. Каждому типу команд в локальной системе ставится в соответствие ненулевой локальный номер канала. Аналогичное правило справедливо и для удаленной системы. Это позволяет решить проблему одновременного двухстороннего информационного обмена. Для каждого файла протокол формирует указатель, в исходный момент равный нулю. После получения очередного пакета указатель соответствующим образом инкрементируется. Исключение представляют пакеты типа spos, которые служат для изменения указателя файла. Формат пакета i-протокола представлен на рис. 4.4.14.1.2.
Рис. 4.4.14.1.2. Формат пакета i -протокола
Заголовок начинается с флага g (восьмеричный код \007), далее следует 5-битовое поле пакет. Пакеты DATA, SPOS и CLOSE используют это поле для номера пакета. В пакетах NAK сюда заносится номер пакета, подлежащий повторной пересылке. В пакетах же ACK и SYNC это поле заполняется нулями. Поле ACK содержит 5 бит и служит для записи номера последнего пакета, принятого без ошибки. Это поле используется всеми типами пакетов. В трехбитовое поле тип определяет назначение пакета и может принимать следующие значения.
| 0 ‘DATA’ | Информационный пакет; |
| 1 ‘SYNC’ | Пакет sync используется при инициализации соединения, поле пакет в для этого типа обнуляется; |
| 2 ‘ACK’ | Пакет-отклик. Так как пакет типа data также может использоваться для отклика, ack предназначен для случая, когда одной из сторон нечего посылать. Пакеты ack не нумеруются. |
| 3 ‘NAK’ | Отрицательное подтверждение. Пакет посылается, когда при приеме произошла ошибка. В этом случае в поле пакет записывается номер пакета, подлежащего повторной пересылке. |
| 4 ‘SPOS’ | Пакет служит для изменения указателя файла. Пакет содержит 4 байта указателя файла (наиболее значащий байт первый). |
| 5 ‘CLOSE’ | Пакет служит для сообщения о прерывании связи. Противоположная сторона должна откликнуться пакетом CLOSE. |
Однобитовое поле d =1 для пакетов клиента и =0 для пакетов сервера. Поле длины поля данных состоит из двух секций (полный байт содержит младшую часть), имеет суммарную протяженность 12 бит, что позволяет варьировать поле данных в пределах от 0 до 4095 байт. Однобайтовое поле контрольная сумма содержит код, который представляет собой результат операции XOR, выполненной для байт заголовка, начиная со второго по пятый. После заголовка следует поле данных, за которым помещается 32-разрядная контрольная сумма информационного поля (CRC).
При инициализации i-протокола стороны обмениваются SYNC-пакетами, которые содержат по крайней мере 3 байта. Первые два байта несут в себе максимальный размер пакетов, посылаемых удаленной стороной (старший байт первый). Третий байт определяет размер окна, используемый удаленной стороной. При этом могут посылаться пакеты любого размера, но не больше указанного максимального. Если SYNC содержит четвертый байт, то он хранит в себе номер канала (1-7), который может использовать удаленная система. Размер окна определяет число пакетов, которое может быть послано, не дожидаясь подтверждения получения. Подтверждаться может не каждый пакет. Если получено подтверждение получения пакета n, все предшествующие считаются полученными корректно. Если потерян пакет, посланный одной из сторон, другая может передавать пакеты, как ни в чем не бывало. Команды посылаются в виде последовательности информационных пакетов с ненулевым полем номера локального канала. Последний из пакетов в этом случае должен содержать нулевой байт в конце (обычно команда укладывается в один пакет). Файла передаются в виде последовательности пакетов, завершающейся пакетом нулевой длины. При получении отклика sn пересылка файла абортируется. Применение номеров каналов позволяет посылать команды и пересылать файлы одновременно.
j-протокол. Этот протокол является разновидностью i-протокола написанного тем же автором. Протокол предназначен для коммуникационных каналов с возможностью перехвата некоторых символов, например xon или xoff. Протокол не выполняет детектирования или исправления ошибок. При инициализации j-протокола системы обмениваются последовательностями печатных ascii-символов, чтобы указать, какие из них стороны хотят исключить из употребления. Такая последовательность должна начинаться с символа (восьмеричный код 136) и завершаться символом ~ (восьмеричный код 176). После отправления такой строки система ждет аналогичной посылки с противоположной стороны. Строки состоят из esc-последовательностей типа \ooo, где o - восьмеричная цифра. Например, посылка последовательности \021\023~ означает, что следует избегать символов xon и xoff. Блокировка использования символов из диапазона \040 - \176 запрещена. После указанного обмена включается стандартный i-протокол, но пакеты i-протокола вкладываются в j-пакеты. Заголовок j-пакетов содержит 7 байт. Формат заголовка пакета j-протокола показан на рис. 4.4.14.1.3.
Рис. 4.4.14.1.3. Формат заголовка j-пакета
Заголовок начинается с кода символа . Далее следует два байта поля длина (первый из них старший), которые характеризуют полную длину пакета в байтах. Запись в этом поле осуществляется в виде ascii-символов. Истинная длина пакета вычисляется согласно формуле: (l1 - 040)*0100 + (l2 - 040), где 040 l1 < 0177 и 040 l2 < 0140. После поля длина следует байт 075 (символ =), за которым следует два байта длины поля данных (равна размеру вложенного i-пакета в октетах). Заголовок завершается символом @ (восьмеричный код 0100). Все символы, запрещенные к использованию при инициализации, в случае их наличия в i-пакете подменяются печатными ASCII-символами. При этом для каждой такой подмены вводится два индексных байта (art-h и index_l). Индексные байты непосредственно следуют за байтами данных. В индексных байтах закодировано положение “запретного” символа в i-пакете. Преобразование запретных символов производится следующим образом. Если код символа больше или равно 0200, из него вычитается 0200, если при этом результат меньше 020 или равен 0177, над ним производится операция xor 020. Индексные байты представляют собой ASCII-символы. Истинное положение запретного символа вычисляется по формуле: (art-h - 040) * 040 + (index_l - 040). Значение index_l должно лежать в пределах 040 index_l < 0100, а art-h - 040 art-h < 0176.
x-протокол. Протокол ориентирован на машины со встроенными картами Х.25 и предназначен для непосредственной пересылки 8-битовых данных без взаимодействия со слоями Х.28 или Х.29. Пересылка осуществляется 512 байтными пакетами.
y-протокол. Протокол разработан Йоргом Квиком и используется в FX uucico. Протокол осуществляет контроль и коррекцию ошибок, он предназначен для передачи 8-битовых данных в поточном режиме. Здесь не предусмотрено подтверждения получения пакетов, по этой причине протокол удобен для полудуплексных каналов. Каждый пакет имеет 6-байтовый заголовок. Формат заголовка для y-пакетов показан на рис. 4.4.14.1.4.
Рис. 4.4.14.1.4. Формат заголовка для y-пакетов
Первое поле номер содержит два байта номера пакета, причем первый из байтов является младшей частью номера (это справедливо и для других полей заголовка). Нумерация начинается с нуля. Так как первый пакет всегда SYNC, информационные пакеты имеют номера, начиная с 1. Каждая из систем, участвующих в обмене, нумеруют пакеты независимо. Если старший бит 16-битового поля длины равен нулю, то в этом поле записано число байт в поле данных, следующем за заголовком. Если же старший бит равен 1, то данных в пакете нет, а сам он является управляющим пакетом. В этом случае поле длина определяет тип пакета. Содержимое двухбайтового поля контрольная сумма вычисляется по программе, приведенной в описании протокола f. Для пакетов, не содержащих данных, контрольная сумма равна нулю. Инициализация протокола начинается с того, что стороны обмениваются SYNC-пакетами. SYNC-пакет должен содержать по меньшей мере 4 байта данных. Первый из них содержит код версии протокола. Далее следует байт длины пакета, которая измеряется в блоках по 256 байт (максимальный размер поля данных 32768 байт, что соответствует коду длины 128). Завершается блок данных пакета SYNC двумя байтами флагов. В настоящее время их функции не определены и их следует обнулять. Определены следующие типы управляющих пакетов.
| 0хFFFE ‘YPKT_ACK’ | подтверждение корректного приема файла; |
| 0xFFFD ‘YPKT_ERR’ | указывает на ошибку в контрольной сумме; |
| 0xFFFC ‘YPKT_BAD’ | указывает на ошибку в порядковом номере, в поле длины или какую-либо еще ошибку. |
Если получен управляющий пакет, отличный от ‘YPKT_ACK’, соединение обрывается (это же делается при обнаружении других ошибок). Команда в y-протоколе представляет собой последовательность пакетов, завершающаяся нулевым байтом. Конец передачи файла отмечается посылкой пакета с нулем в поле длина.
Существуют также d-, h- и v-протоколы UUCP, но они не имеют заметного применения.
4.4.14.2. Почтовый протокол POP3
Семёнов Ю.А. (ГНЦ ИТЭФ), ссылка скрыта
В некоторых небольших узлах Интернет бывает непрактично поддерживать систему передачи сообщений (MTS - Message Transport System). Рабочая станция может не иметь достаточных ресурсов для обеспечения непрерывной работы SMTP-сервера [RFC-821]. Для “домашних ЭВМ” слишком дорого поддерживать связь с Интернет круглые сутки.
Но доступ к электронной почте необходим как для таких малых узлов, так и индивидуальных ЭВМ. Для решения этой проблемы разработан протокол POP3 (Post Office Protocol - Version 3, STD: 53. M. Rose, RFC-1939). Этот протокол обеспечивает доступ узла к базовому почтовому серверу.
POP3 не ставит целью предоставление широкого списка манипуляций с почтой, он лишь получает и стирает почтовые сообщения. Более продвинутый и сложный протокол IMAP4 обсуждается в RFC-2060 (порт 143). Об аутентификации в POP3 можно прочесть в документе RFC-1734.
В дальнейшем ЭВМ-клиентом будет называться машина, пользующаяся услугами POP3, а ЭВМ-сервером - сторона, предлагающая услуги POP3.
Когда пользователь ЭВМ-клиента хочет послать сообщение, он устанавливает SMTP связь с почтовым сервером непосредственно и посылает все, что нужно через него. При этом ЭВМ POP3-сервер не обязательно является почтовым сервером.
В исходный момент ЭВМ POP3-сервер прослушивает TCP-порт 110. Если ЭВМ-клиент хочет воспользоваться услугами POP3-сервера, то устанавливает с ним TCP связь. По установлении связи POP3-сервер посылает клиенту уведомление (например, +OK POP3 server ready) и сессия переходит в фазу авторизации (см. также RFC-1734, -1957). После этого может производиться обмен командами и откликами.
Команды POP3 состоят из ключевых слов (3-4 символа), за которыми могут следовать аргументы. Каждая команда завершается парой символов CRLF. Как ключевые слова, так и аргументы могут содержать только печатаемые ASCII-символы. В качестве разделителя используются символы пробела. Каждый аргумент может содержать до 40 символов.
Сигнал отклика в POP3 содержит индикатор состояния и ключевое слово, за которым может следовать дополнительная информация. Отклик также завершается кодовой последовательностью CRLF. Длина отклика не превышает 512 символов, включая CRLF. Существует два индикатора состояния: положительный - "+OK" и отрицательный "-ERR" (все символы прописные).
Отклики на некоторые команды могут содержать несколько строк. В этом случае последняя строка содержит код завершения 046 ("."), за которым следует CRLF.
На практике многострочные отклики для исключения имитации завершаются последовательностью CRLF.CRLF.
В процессе авторизации клиент должен представить себя серверу, передав имя и пароль (возможен вариант посылки команды APOP). Если авторизация успешно завершена, сессия переходит в состояние транзакции (TRANSACTION). При получении от клиента команды QUIT сессия переходит в состояние UPDATE, при этом все ресурсы освобождаются и TCP связь разрывается.
На синтаксически неузнанные и неверные команды, сервер реагирует, посылая отрицательный индикатор состояния.
POP3 сервер может быть снабжен таймером пассивного состояния (10 мин.), который осуществляет автоматическое прерывание сессии. Приход любой команды со стороны клиента сбрасывает этот таймер в нуль.
Сервер нумерует все передаваемые сообщения из своего почтового ящика и определяет их длину. Положительный отклик начинается с +OK, за ним следует пробел, номер сообщения, еще один пробел и длина сообщения в октетах. Завершается отклик последовательностью CRLF. Переданные сообщения удаляются из почтового ящика сервера. Все сообщения, передаваемые во время сессии POP3 должны следовать рекомендациям формата Интернет сообщений [RFC822].
В состоянии транзакции клиент может посылать серверу последовательность POP3 команд, на каждую из которых сервер должен послать отклик. Далее следует краткое описание команд, используемых в состоянии транзакция.
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 связь. Пример:
К: QUIT
С: +OK dewey POP3 server signing off.
RETR msg (msg - номер сообщения)
Если POP3-сервер выдал положительный отклик, то за начальным +OK следует сообщение с номером, указанным в аргументе. Отрицательный отклик имеет вид -ERR no such message.
Пример использования команды:
К: RETR 1
С: +OK 120 octets
С:
С: .
DELE msg (msg - номер сообщения)
Сервер POP3 помечает сообщение как удаленное. Любая ссылка на это сообщение в будущем вызовет ошибку. При этом само сообщение не удаляется пока сессия не войдет в режим UPDATE.
Пример использования команды:
К: DELE 1
С: +OK message 1 deleted
...
К: DELE 2
С: -ERR message 2 already deleted
NOOP (не использует каких-либо аргументов). При реализации этой команды сервер не делает ничего, лишь посылает положительный отклик.
RSET (не использует каких-либо аргументов)
Если какие-либо сообщения помечены как удаленные, сервер POP3 удаляет эту пометку и возвращает положительный отклик. Например:
К: RSET
С: +OK maildrop has 2 messages (320 octets)
Если сессия завершается не по команде клиента, то перехода в состояние UPDATE не производится, а сообщения не удаляются из почтового ящика. Далее следует описание команд, используемых в состоянии 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
Примеры использования команды USER:
К: USER frated
С: -ERR sorry, no mailbox for frated here
...
К: USER mrose
С: +OK mrose is a real hoopy frood
PASS string (string - пароль для доступа к почтовому серверу)
Команда работает в режиме авторизации сразу после команды USER. Когда клиент выдает команду PASS, сервер использует аргументы команд USER и PASS для определения доступа клиента к почтовому ящику. На команду PASS возможны следующие отклики:
+OK maildrop locked and ready
-ERR invalid password
-ERR unable to lock maildrop
Пример диалога при использовании команды PASS:
К: USER mrose
С: +OK mrose is a real hoopy frood
К: PASS secret
С: -ERR maildrop already locked
...
К: USER mrose
С: +OK mrose is a real hoopy frood
К: PASS secret
С: +OK mrose's maildrop has 2 messages (320 octets)
APOP name digest, где name - идентификатор почтового ящика, а digest - дайджест сообщения - MD5 (RFC-1828). Команда используется только на стадии авторизации.
Обычно любая сессия начинается с обмена USER/PASS. Но так как в некоторых случаях подключения к серверу POP3 может осуществляться достаточно часто, возрастает риск перехвата пароля. Альтернативным методом авторизации является использование команды APOP. Сервер, который поддерживает применение команды APOP, добавляет временную метку в свое стартовое уведомление. Синтаксис временной метки соответствует формату идентификаторов сообщений, описанному в [RFC822] и должны быть уникальными для всех заголовков уведомлений. Так для UNIX-приложений синтаксис временной метки должен иметь вид:
где `process-ID' представляет собой десятичное значение PID процесса, clock - десятичное показание системных часов, а hostname - полное имя домена, где размещен сервер POP3.
Клиент POP3 фиксирует временную метку и выдает команду APOP. Параметр `name' семантически идентичен параметру `name' команды USER. Параметр `digest' вычисляется с использованием алгоритма MD5 [RFC1321] для строки, состоящей из временной метки (включая угловые скобки) за которой следует строка пароля, которая известна только клиенту и серверу. Параметр `digest' содержит 16 октетов, которые пересылаются в шестнадцатеричном формате с использованием строчных ASCII символов. Сервер, получив команду APOP, проверяет принятый дайджест и если он корректен, посылает положительный отклик клиенту. Сессия при этом переходит в состояние транзакции. В противном случае посылается отрицательный отклик и состояние сессии не изменяется. С целью обеспечения безопасности для каждого конкретного пользователя и сервера должен использоваться либо метод доступа USER/PASS, либо APOP, но не в коем случае оба метода попеременно.
Сервер перед закрытием канала по команде QUIT должен удалить из почтового ящика все сообщения, которые были перенесены с помощью команд RETR.
Предполагается, что все сообщения, передаваемые в ходе сессии POP3, имеют текстовый формат Интернет в соответствии с документом [RFC822].