RFC: 1939
Оригинал: Post Office Protocol - Version 3
Предыдущие версии: RFC 1081, RFC 1225, RFC 1460, RFC 1725
Категория: Стандарт Интернета
Дата публикации:
Авторы: ,
Перевод: ?

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

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

Оглавление

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

  • Аргументы:
  • нет
  • Ограничения:
  • нет
  • Возможные ответы:
  • +OK
  • Примеры:
  • C: QUIT
S: +OK dewey POP3 server signing off

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

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

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

STAT

  • Аргументы:

  • нет

  • Ограничения:

  • Может быть передана только в состоянии TRANSACTION.

  • Подробности:

  • POP3 сервер отправляет положительный ответ со строкой содержащей информация о почтовом ящике. Эта строка называется «drop listing».

    Для легкого разбора, всем POP3-серверам необходимо использовать определенный формат для «drop listing». Положительный ответ включает в себя: индикатор состояния (+OK), дальше следуют число сообщений и размер сообщений в октетах, разделенные одиночным пробелом. Этот документ не определяет требований к тому, что следует за размером maildrop. Минимальная реализация должна заканчивать эту строку парой CRLF. Различные расширения могут включать дополнительную информацию.

    Примечание: Этот документ СТРОГО не рекомендует добавлять дополнительную информацию в «drop listing». Другие, опциональные средства, которые разрешают клиенту разбирать сообщения в maildrop, обсуждаются ниже.

    Отметим так же, что сообщения, помеченные как удаленные, не учитываются.

  • Возможные ответы:

  • +OK nn mm

  • Примеры:
  • C: STAT
S: +OK 2 320

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

  • Аргументы:

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

  • Ограничения:

  • Может быть передана только в состоянии TRANSACTION.

  • Подробности:

  • Если задан аргумент, сервер передает положительный ответ со строкой информации для заданного сообщения. Такая строка называется «scan listing».

    Если аргумент не задан и POP3 сервер отвечает положительным ответом, то данный ответ является многострочным. После индикатора состояния (+OK), для каждого сообщения в почтовом ящике, POP3 сервер посылает строку содержащую информацию для данного сообщения. Эта строка называется «scan listing». Если почтовый ящик пуст, POP3-сервер отвечает без «scan listing» — он выдает положительный ответ, сопровождаемый строкой, содержащей октет завершения и пару CRLF.

    Для легкого разбора, всем POP3-серверам необходимо использовать определенный формат для «scan listing». «scan listing» состоит из номера сообщения после которого, через одиночный пробел следует точный размер сообщения в октетах. Методы вычисления точного размера сообщения, описаны ниже, в разделе «Формат Сообщений». Данный документ не указывает, что должно следовать за размером сообщения, единственное требование — чтобы ответ заканчивался парой CRLF. Различные расширения могут включать дополнительную информацию.

    Примечание: Этот документ СТРОГО не рекомендует добавлять дополнительную информацию в «scan listing».

    Отметим так же, что сообщения, помеченные как удаленные, не учитываются.

  • Возможные ответы:

  • +OK scan listing follows
    -ERR no such message

  • Примеры:
  • C: LIST
S: +OK 2 messages (320 octets)
S: 1 120
S: 2 200
S: .
  ...
C: LIST 2
S: +OK 2 200
  ...
C: LIST 3
S: -ERR no such message, only 2 messages in maildrop

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

  • Аргументы:

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

  • Ограничения:

  • Может быть передана только в состоянии TRANSACTION.

  • Подробности:

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

  • Возможные ответы:

  • +OK message follows
    -ERR no such message

  • Примеры:
  • C: RETR 1
S: +OK 120 octets
S: <the POP3 server sends the entire message here>
S: .

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

  • Аргументы:

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

  • Ограничения:

  • Может быть передана только в состоянии TRANSACTION.

  • Подробности:

  • POP3 сервер помечает сообщение как удаленное. Все последующие обращения к этому сообщению будут вызывать ошибку. Фактически сервер не удаляет сообщение, пока не наступит состояние UPDATE.

  • Возможные ответы:

  • +OK message deleted
    -ERR no such message

  • Примеры:
  • C: DELE 1
S: +OK message 1 deleted
   ...
C: DELE 2
S: -ERR message 2 already deleted

NOOP

  • Аргументы:

  • Нет.

  • Ограничения:

  • Может быть передана только в состоянии TRANSACTION.

  • Подробности:

  • Сервер ничего не делает и отвечает только положительно.

  • Возможные ответы:

  • +OK

  • Примеры:
  • C: NOOP
S: +OK

RSET

  • Аргументы:

  • Нет.

  • Ограничения:

  • Может быть передана только в состоянии TRANSACTION.

  • Подробности:

  • Если сообщение было помечено как удаленное, то сервер снимает эту отметку. Ответ всегда положительный.

  • Возможные ответы:

  • +OK

  • Примеры:
  • C: RSET
S: +OK maildrop has 2 messages (320 octets)

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

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

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

QUIT

  • Аргументы:

  • Нет

  • Ограничения:

  • Нет

  • Подробности:

  • Сервер удаляет все сообщения помеченные как удаленные и посылает ответ о состоянии операции.

  • Возможные ответы:

  • +OK

  • Примеры:
  • C: QUIT
S: +OK dewey POP3 server signing off (maildrop empty)
   ...
C: QUIT
S: +OK dewey POP3 server signing off (2 messages left)
   ...

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

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

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

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

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

  • Аргументы:

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

  • Ограничения:

  • Может быть передана только в состоянии TRANSACTION.

  • Подробности:

  • После положительного ответа, сервер посылает многострочный ответ. После начального +OK, сервер посылает заголовок сообщения, пустую строку и указанное количество строк из тела сообщения.

    Примечание: Если число строк, которые требует клиент, больше числа строк в сообщение, то сервер передает все сообщение полностью.

  • Возможные ответы:

  • +OK top of message follows
    -ERR no such message

  • Примеры:
  • C: TOP 1 10
S: +OK
S: <the POP3 server sends the headers of the
   message, a blank line, and the first 10 lines
   of the body of the message>
S: .
   ...
C: TOP 100 3
S: -ERR no such message

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

  • Аргументы:

  • Номер сообщения (необязательный). Нельзя обратиться к сообщению помеченному как удаленное.

  • Ограничения:

  • Может быть передана только в состоянии TRANSACTION.

  • Подробности:

  • Если аргумент задан, сервер посылает положительный ответ со строкой содержащей информацию о заданном сообщении. Эта строка называется «unique-id listing».

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

    Для упрощения синтаксического разбора все сервера должны использовать определенный формат «unique-id listing». «unique-id listing» состоит из номера сообщения и уникального идентификатора разделенные одиночным пробелом. За уникальным идентификатором не должно следовать ни какой дополнительной информации.

    Уникальный идентификатор это произвольная, определяемая сервером, строка, содержащая 1-70 символов в диапазоне от 0x21 до 0x7E, которая однозначно идентифицирует сообщение в пределах почтового ящика. Идентификатор сохраняется на все время сессии. Это постоянство требуется, даже если сеанс закончился не переходя в состояние UPDATE. Сервер не должен многократно использовать идентификатор для данного почтового ящика, пока существует объект использующий его. Сообщения помеченные как удаленные не учитываются.

  • Возможные ответы:

  • +OK unique-id listing follows
    -ERR no such message

  • Примеры:
  • C: UIDL
S: +OK
S: 1 whqtswO00WBw418f9t5JxYwZ
S: 2 QhdPYR:00WBw1Ph7x7
S: .
   ...
C: UIDL 2
S: +OK 2 QhdPYR:00WBw1Ph7x7
   ...
C: UIDL 3
S: -ERR no such message, only 2 messages in maildrop

USER [имя]

  • Аргументы:

  • Строка идентификации почтового ящика (обязательный).

  • Ограничения:

  • Может быть передана только в состоянии AUTHORIZATION после POP3 приветствия или неуспешной команды USER или PASS.

  • Подробности:

  • To authenticate using the USER and PASS command combination, the client must first issue the USER command. If the POP3 server responds with a positive status indicator («+OK»), then the client may issue either the PASS command to complete the authentication, or the QUIT command to terminate the POP3 session. If the POP3 server responds with a negative status indicator («-ERR») to the USER command, then the client may either issue a new authentication command or may issue the QUIT command.

    The server may return a positive response even though no such mailbox exists. The server may return a negative response if mailbox exists, but does not permit plaintext password authentication.

  • Возможные ответы:

  • +OK name is a valid mailbox
    -ERR never heard of mailbox name

  • Примеры:
  • C: USER mrose
S: +OK mrose is a real hoopy frood
   ...
C: USER frated
S: -ERR sorry, no mailbox for frated here

PASS [строка]

  • Аргументы:

  • пароль к почтовому ящику (обязательный).

  • Ограничения:

  • Может быть передана только в состоянии AUTHORIZATION после успешной команды USER.

  • Подробности:

  • When the client issues the PASS command, the POP3 server uses the argument pair from the USER and PASS commands to determine if the client should be given access to the appropriate maildrop.

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

  • Возможные ответы:

  • +OK maildrop locked and ready
    -ERR invalid password
    -ERR unable to lock maildrop

  • Примеры:
  • C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: +OK mrose's maildrop has 2 messages (320 octets)
  ...
C: USER mrose
S: +OK mrose is a real hoopy frood
C: PASS secret
S: -ERR maildrop already locked

APOP [имя] [digest]

  • Аргументы:

  • Строка идентифицирующая почтовый ящик и MD5 digest (шифрованная по алгоритму MD5 строка пароля), оба параметра обязательные.

  • Ограничения:

  • may only be given in the AUTHORIZATION state after the POP3 greeting or after an unsuccessful USER or PASS command

  • Подробности:

  • Normally, each POP3 session starts with a USER/PASS exchange. This results in a server/user-id specific password being sent in the clear on the network. For intermittent use of POP3, this may not introduce a sizable risk. However, many POP3 client implementations connect to the POP3 server on a regular basis — to check for new mail. Further the interval of session initiation may be on the order of five minutes. Hence, the risk of password capture is greatly enhanced.

    An alternate method of authentication is required which provides for both origin authentication and replay protection, but which does not involve sending a password in the clear over the network. The APOP command provides this functionality.

    A POP3 server which implements the APOP command will include a timestamp in its banner greeting. The syntax of the timestamp corresponds to the «msg-id» in [RFC822], and MUST be different each time the POP3 server issues a banner greeting. For example, on a UNIX implementation in which a separate UNIX process is used for each instance of a POP3 server, the syntax of the timestamp might be:

    <[email protected]
>

    where «process-ID» is the decimal value of the process's PID, clock is the decimal value of the system clock, and hostname is the fully-qualified domain-name corresponding to the host where the POP3 server is running.

    The POP3 client makes note of this timestamp, and then issues the APOP command. The «name» parameter has identical semantics to the «name» parameter of the USER command. The «digest» parameter is calculated by applying the MD5 algorithm [RFC1321] to a string consisting of the timestamp (including angle-brackets) followed by a shared secret. This shared secret is a string known only to the POP3 client and server. Great care should be taken to prevent unauthorized disclosure of the secret, as knowledge of the secret will allow any entity to successfully masquerade as the named user. The «digest» parameter itself is a 16-octet value which is sent in hexadecimal format, using lower-case ASCII characters.

    When the POP3 server receives the APOP command, it verifies the digest provided. If the digest is correct, the POP3 server issues a positive response, and the POP3 session enters the TRANSACTION state. Otherwise, a negative response is issued and the POP3 session remains in the AUTHORIZATION state.

    Note that as the length of the shared secret increases, so does the difficulty of deriving it. As such, shared secrets should be long strings (considerably longer than the 8-character example shown below).

  • Возможные ответы:

  • +OK maildrop locked and ready
    -ERR permission denied

  • Примеры:
  • S: +OK POP3 server ready <[email protected]
>
C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
S: +OK maildrop has 1 message (369 octets)
In this example, the shared  secret  is  the  string  «tan-
staaf». Hence, the MD5 algorithm is applied to the string
   <[email protected]
>tanstaaf
which produces a digest value of
   c4c9334bac560ecc979e58001b3e22fb

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:

  • Imposing a per-user maildrop storage quota or the like.

    A disadvantage to this option is that accumulation of messages may result in the user's inability to receive new ones into the maildrop. Sites which choose this option should be sure to inform users of impending or current exhaustion of quota, perhaps by inserting an appropriate message into the user's maildrop.

  • Enforce a site policy regarding mail retention on the server.

    Sites are free to establish local policy regarding the storage and retention of messages on the server, both read and unread. For example, a site might delete unread messages from the server after 60 days and delete read messages after 7 days. Such message deletions are outside the scope of the POP3 protocol and are not considered a protocol violation.

    Server operators enforcing message deletion policies should take care to make all users aware of the policies in force.

    Clients must not assume that a site policy will automate message deletions, and should continue to explicitly delete messages using the DELE command when appropriate.

    It should be noted that enforcing site message deletion policies may be confusing to the user community, since their POP3 client may contain configuration options to leave mail on the server which will not in fact be supported by the server.

    One special case of a site policy is that messages may only be downloaded once from the server, and are deleted after this has been accomplished. This could be implemented in POP3 server software by the following mechanism: «following a POP3 login by a client which was ended by a QUIT, delete all messages downloaded during the session with the RETR command». It is important not to delete messages in the event of abnormal connection termination (ie, if no QUIT was received from the client) because the client may not have successfully received or stored the messages. Servers implementing a download-and-delete policy may also wish to disable or limit the optional TOP command, since it could be used as an alternate mechanism to download entire messages.

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 <[email protected]
>
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. Литература

[RFC821] Postel, J., «Simple Mail Transfer Protocol», STD 10, RFC 821, USC/Information Sciences Institute, Август 1982.
[RFC822] Crocker, D., «Standard for the Format of ARPA-Internet Text Messages», STD 11, RFC 822, University of Delaware, Август 1982.
[RFC1321] R. Rivest, «Алгоритм цифровых подписей MD5», RFC 1321, Апрель 1992.
[RFC1730] Crispin, M., «Internet Message Access Protocol — Version 4», RFC 1730, University of Washington, Декабрь 1994.
[RFC1734] Myers, J., «POP3 AUTHentication command», RFC 1734, Carnegie Mellon, Декабрь 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

2007 - 2022 © Русские переводы RFC, IETF, ISOC.