AAA

RFC 1939 — Протокол POP3

Статус документа

Это документ содержит стандарт протокола Internet для Internet-сообщества и служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации и статус протокола можно узнать из текущей версии документа «Internet Official Protocol Standards» (STD 1). Допускается свободное распространение документа.

Оглавление

  1. Введение
  2. Краткое замечание
  3. Базовые операции
  4. Состояние AUTHORIZATION
  5. Состояние TRANSACTION
  6. Состояние UPDATE
  7. Необязательные команды
  8. Вопросы эксплуатации и масштабируемости
  9. Резюме по командам POP3
  10. Пример POP3 сессии
  11. Формат сообщения
  12. Литература
  13. Вопросы безопасности
  14. Благодарности
  15. Адреса авторов

1. Введение

Некоторым типам небольших узлов интернета порой бывает непрактично поддерживать транспортную систему сообщения (MTS). Например, рабочая станция, возможно, не располагает достаточными ресурсами для установки на ней резидентного SMTP-сервера [RFC821] и связанных с ним систем доставки почты. Кроме того, для персонального компьютера затруднительно сохранять постоянное подключение к IP-сетям в течение длительного времени.

Несмотря на это, часто полезно иметь возможность манипулировать почтой на таких маленьких узлах. Post Office Protocol (POP3) обеспечивает удобный интерфейс рабочей станции для динамического обращения к почтовому ящику на сервере.

POP3 не ставит целью предоставить обширные возможности по манипуляции почтой на сервере. Обычная операция — почта загружается клиентом, а затем удаляется. Более продвинутый и сложный протокол, IMAP4, обсуждается в [RFC1730]

2. Краткое замечание

Этот документ не определяет, каким образом клиент вводит почту в транспортную систему, хотя методика, согласованная с философией документа, представлена здесь:

Когда пользовательский агент (UA) желает отправить почту в транспортную систему, он устанавливает соединение с SMTP-сервером, и отправляет всю почту ему. SMTP-сервер может находиться как на локальной машине c POP3-сервером, так и удаленно.

3. Базовые операции

Первоначально, сервер прослушивает TCP соединение на порту 110. Когда клиент желает воспользоваться сервисом POP3, он должен установить соединение с сервером. После установки соединения сервер посылает клиенту приветствие. Клиент и POP3 сервер обмениваются командами и ответами (в указанном порядке) до тех пор, пока соединение не будет закрыто или прервано.

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

Ответы состоят из индикатора состояния и ключевого слова, иногда сопровождаемого дополнительной информацией. Все ответы заканчиваются парой CRLF. Ответ может быть длиной до 512 символов, включая завершающий CRLF. В настоящее время есть два индикатора состояния: положительный (+OK) и отрицательный (-ERR). Сервер должен посылать «+OK» и «-ERR» только в верхнем регистре.

Определенные ответы могут быть многострочными. В этом случае, после первой строки ответа заканчивающейся CRLF, каждая дополнительно посланная строка заканчивается парой CRLF. После того как все строки ответа посланы, последняя строка будет заканчиваться завершающим октетом — символом «.» (десятичный код 046) и парой CRLF. Таким образом, многострочный ответ заканчивается этими пятью октетами — «CRLF.CRLF». Исследуя многострочный ответ, клиент проверяет, начинается ли строка с октета завершения. Если это так, и если следуют октеты кроме CRLF, первый октет строки (октет завершения) снят. Если это так, и если CRLF следует сразу же за символом завершения, значит ответ POP сервера завершен, и строка, содержащая «.CLRF» не считается частью многострочного ответа.

POP3 сессия состоит из нескольких стадий. После установки TCP соединения, сервер посылает приветствие, и сессия переходит в состояние AUTHORIZATION. На этом этапе клиент должен идентифицировать себя на сервере. После успешной идентификации сессия переходит в состояние TRANSACTION. В этой стадии клиент запрашивает выполнение команд на сервере. Когда клиент посылает команду QUIT, сессия переходит в состояние UPDATE. На этом этапе POP3 сервер освобождает все ресурсы, занятые в стадии TRANSACTION и заканчивает работу. TCP соединение после этого закрывается.

Сервер должен ответить на нераспознанную, нереализованную, или синтаксически недопустимую команду, ответив с отрицательным (-ERR) индикатором состояния. Сервер должен ответить на команду, выполненную при некорректном состоянии сессии, ответив с отрицательным (-ERR) индикатором состояния. Нет никакого общего метода для клиента, чтобы различить сервер, который не реализует опциональную команду, или который не желает или неспособен обработать команду.

POP3 сервер МОЖЕТ иметь inactivity autologout таймер (таймер авто-завершения сессии при бездействии). Такой таймер ДОЛЖЕН быть установлен как минимум на 10 минут. Если клиент не передает серверу команды заданный интервал времени, то сервер разрывает TCP соединение без перехода в состояние UPDATE, т.е. без удаления сообщений и посылки каких либо ответов клиенту.

4. Состояние AUTHORIZATION

После открытия клиентом TCP соединения, сервер посылает однострочное приветствие. Строка должна заканчиваться положительным ответом.

Пример:

S:  +OK POP3 server ready

Теперь сессия находится в состоянии AUTHORIZATION. Клиент должен идентифицировать себя на сервере. В данном документе описано два способа, комбинация команд USER и PASS и команда APOP. Оба механизма описаны ниже в этом документе. Дополнительные механизмы аутентификации описаны в [RFC1734]. До тех пор, пока нет единого механизма, который требуется от всех POP3 серверов, сервер POP3 должен поддерживать, по крайней мере, один из механизмов аутентификации.

Для идентификации с помощью команд USER и PASS, клиент должен сначала послать команду USER. Если сервер ответил положительным индикатором состояния (+OK), то клиент должен послать команду PASS чтобы закончить авторизацию или послать команду QUIT для завершения сессии. Если сервер отправил отрицательный ответ (-ERR) на команду USER, то можно повторить авторизацию или закончить сессию командой QUIT.

Как только сервер определил, что клиенту нужно дать доступ к соответствующему почтовому ящику, POP3 сервер получает монопольный доступ к почтовому ящику, чтобы предотвратить изменение или удаление сообщений до состояния UPDATE. Если блокировка прошла успешно, сервер посылает положительный ответ и строку приветствия. Теперь сессия переходит в состояние TRANSACTION без сообщений, помеченных, как удаленные. Если, по каким либо причинам, почтовый ящик не может быть открыт (например, не может быть выполнена блокировка или клиенту отказано в доступе к соответствующему почтовому ящику), сервер отвечает отрицательным индикатором состояния. (Если блокировка прошла успешно, но сервер намерен ответить отрицательным индикатором состояния, то сервер POP3 должен снять блокировку до отклонения команды). После отрицательного ответа сервер может закрыть соединение. Если сервер не закрыл соединение, клиент может послать новую команду идентификации и начать все заново или послать команду QUIT.

После того как сервер открыл почтовый ящик, он присваивает номер каждому сообщению и отмечает размер сообщения в октетах. Первое сообщение будет иметь номер 1, следующее — номер 2 и так далее. В POP3 командах все числа представлены в десятичной системе.

Вот резюме команды QUIT, используемой в состоянии AUTHORIZATION:

QUIT

5. Состояние TRANSACTION

После того как клиент успешно идентифицировал себя на сервере и сервер заблокировал и открыл соответствующий почтовый ящик, сессия переходит в состояние TRANSACTION. Теперь клиент может запрашивать информацию. После каждой команды сервер отправляет ответ. В конце клиент отправляет команду QUIT, и сессия переходит в состояние UPDATE.

Вот команды POP3, валидные в состоянии TRANSACTION:

STAT

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

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

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

NOOP

RSET

6. Состояние UPDATE

Когда клиент посылает команду QUIT в состоянии TRANSACTION, сервер переходит на стадию UPDATE (Обратите внимание, что если клиент посылает команду в состоянии AUTHORIZATION, то сервер завершает сессию и не входит в стадию UPDATE).

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

QUIT

7. Необязательные команды

POP3 команды, описанные выше, должны поддерживаться всеми POP3 серверами.

Дополнительные команды дают клиенту большую свободу в обработке сообщений, сохраняя простоту реализации POP3-сервера.

Примечание: этот документ поощряет поддержку дополнительных команд, вместо внесений дополнительных сведений в «drop listing» и «scan listing». Короче говоря, философия этого документа — поместить весь интеллект в часть POP3-клиента, а не сервера.

TOP [сообщение] [количество строк]

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

USER [имя]

PASS [строка]

APOP [имя] [digest]

8. Вопросы эксплуатации и масштабируемости

Since some of the optional features described above were added to the POP3 protocol, experience has accumulated in using them in large-scale commercial post office operations where most of the users are unrelated to each other. In these situations and others, users and vendors of POP3 clients have discovered that the combination of using the UIDL command and not issuing the DELE command can provide a weak version of the «maildrop as semi-permanent repository» unctionality normally associated with IMAP. Of course the other capabilities of IMAP, such as polling an existing connection for newly arrived messages and supporting multiple folders on the server, are not present in POP3.

When these facilities are used in this way by casual users, there has been a tendency for already-read messages to accumulate on the server without bound. This is clearly an undesirable behavior pattern from the standpoint of the server operator. This situation is aggravated by the fact that the limited capabilities of the POP3 do not permit efficient handling of maildrops which have hundreds or thousands of messages.

Consequently, it is recommended that operators of large-scale multi-user servers, especially ones in which the user's only access to the maildrop is via POP3, consider such options as:

9. Резюме по командам POP3

Основные команды:

USER name               valid in the AUTHORIZATION state
PASS string
QUIT

STAT                    valid in the TRANSACTION state
LIST [msg]
RETR msg
DELE msg
NOOP
RSET
QUIT                    valid in the UPDATE state

Дополнительные команды:

APOP name digest        valid in the AUTHORIZATION state

TOP msg n               valid in the TRANSACTION state
UIDL [msg]

Ответы:

+OK
-ERR

Обратите внимание что на все команды за исключением STAT, LIST и UIDL, ответ, данный сервером важно только +OK и -ERR. Любой текст встречающийся после этого ответа может игнорироваться клиентом.

10. Пример POP3 сессии

S: <wait for connection on TCP port 110>
C: <open connection>
S:    +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
C:    APOP mrose c4c9334bac560ecc979e58001b3e22fb
S:    +OK mrose's maildrop has 2 messages (320 octets)
C:    STAT
S:    +OK 2 320
C:    LIST
S:    +OK 2 messages (320 octets)
S:    1 120
S:    2 200
S:    .
C:    RETR 1
S:    +OK 120 octets
S:    <the POP3 server sends message 1>
S:    .
C:    DELE 1
S:    +OK message 1 deleted
C:    RETR 2
S:    +OK 200 octets
S:    <the POP3 server sends message 2>
S:    .
C:    DELE 2
S:    +OK message 2 deleted
C:    QUIT
S:    +OK dewey POP3 server signing off (maildrop empty)
C:  <close connection>
S:  <wait for next connection>

11. Формат сообщения

All messages transmitted during a POP3 session are assumed to conform to the standard for the format of Internet text messages [RFC822].

It is important to note that the octet count for a message on the server host may differ from the octet count assigned to that message due to local conventions for designating end-of-line. Usually, during the AUTHORIZATION state of the POP3 session, the POP3 server can calculate the size of each message in octets when it opens the maildrop. For example, if the POP3 server host internally represents end-of-line as a single character, then the POP3 server simply counts each occurrence of this character in a message as two octets. Note that lines in the message which start with the termination octet need not (and must not) be counted twice, since the POP3 client will remove all byte-stuffed termination characters when it receives a multi-line response.

12. Литература

  1. [RFC821] Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 821, USC/Information Sciences Institute, August 1982.
  2. [RFC822] Crocker, D., «Standard for the Format of ARPA-Internet Text Messages», STD 11, RFC 822, University of Delaware, August 1982.
  3. [RFC1321] Rivest, R., «The MD5 Message-Digest Algorithm», RFC 1321, MIT Laboratory for Computer Science, April 1992.
  4. [RFC1730] Crispin, M., «Internet Message Access Protocol — Version 4», RFC 1730, University of Washington, December 1994.
  5. [RFC1734] Myers, J., «POP3 AUTHentication command», RFC 1734, Carnegie Mellon, December 1994.

13. Вопросы безопасности

It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both.

Further, note that as the length of the shared secret increases, so does the difficulty of deriving it.

Servers that answer -ERR to the USER command are giving potential attackers clues about which names are valid.

Use of the PASS command sends passwords in the clear over the network.

Use of the RETR and TOP commands sends mail in the clear over the network.

Otherwise, security issues are not discussed in this memo.

14. Благодарности

The POP family has a long and checkered history. Although primarily a minor revision to RFC 1460, POP3 is based on the ideas presented in RFCs 918, 937, and 1081.

In addition, Alfred Grimstad, Keith McCloghrie, and Neil Ostroff provided significant comments on the APOP command.

15. Адреса авторов

John G. Myers
Carnegie-Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
EMail: ude.umc@+mgj

Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
EMail: su.ac.weivtm.cbd@esorm

Перево на русский язык

Ex, ur.tsil@yildop