Differences

This shows you the differences between two versions of the page.

--- protocols:hf-pop [2018/08/14 16:05] – created root
+++ protocols:hf-pop [2018/08/20 12:43] (current) – [The UPDATE State] root
@@ Line 6: / Line 6: @@
 so read carefully.
-===== F.4.1 Introduction =====
+===== Introduction =====
 It will in general be impractical to maintain a message transport system (MTS) over HF radio
@@ Line 28: / Line 28: @@
 establishes an HMTP connection to its relay host and sends all mail to it.
-===== F.4.2 Basic Operation =====
+===== Basic Operation =====
 Initially, the server host starts the HF-POP3 service by listening for incoming connections
@@ Line 83: / Line 83: @@
 messages or sending any response to the client.
-===== F.4.3 The AUTHORIZATION State =====
+===== The AUTHORIZATION State =====
 Once the connection has been opened by a HF-POP3 client, the HF-POP3 server shall issue a
@@ Line 95: / Line 95: @@
 shall be used for this purpose.
+==== The APOP command ====
+__Usage:__
   APOP name digest
+__Arguments:__
+A string identifying a mailbox and a MD5 digest string (both required)
+__Restrictions:__
+May only be given in the AUTHORIZATION state after the POP3 greeting or after
+an unsuccessful USER or PASS command
+__Discussion:__
-  Arguments:
+In the context of this standard, the APOP command provides both origin
+authentication and replay protection. An HF-POP3 servers shall include a timestamp
-  a string identifying a mailbox and a MD5 digest string (both required)
+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
-  Restrictions:
+greeting. For example, on a UNIX implementation in which a separate UNIX
-  may only be given in the AUTHORIZATION state after the POP3 greeting or after
+process is used for each instance of a POP3 server, the syntax of the timestamp might
-  an unsuccessful USER or PASS command
+be:
-  Discussion:
-  In the context of this standard, the APOP command provides both origin
-  authentication and replay protection. An HF-POP3 servers shall 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:
   <process-ID.clock@hostname>
-  where `process-ID' is the decimal value of the process's PID, clock is the decimal
+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
+value of the system clock, and hostname is the fully-qualified domain-name
-  corresponding to the host where the POP3 server is running.
+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 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
+The `name' parameter has identical semantics to the `name' parameter of the USER
-  command. The `digest' parameter is calculated by applying the MD5 algorithm
+command. The `digest' parameter is calculated by applying the MD5 algorithm
-  [RFC1321] to a string consisting of the timestamp (including angle-brackets)
+[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
+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
+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
+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
+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.
+which is sent in hexadecimal format, using lower-case ASCII characters.
-  When the POP3 server receives the APOP command, it verifies the digest provided.
+When the POP3 server receives the APOP command, it verifies the digest provided.
-  If the digest is correct, the POP3 session enters the TRANSACTION state and the
+If the digest is correct, the POP3 session enters the TRANSACTION state and the
-  POP3 server issues a positive response including the LIST response for the maildrop,
+POP3 server issues a positive response including the LIST response for the maildrop,
-  as shown below. Otherwise, a negative response is issued and the POP3 session
+as shown below. Otherwise, a negative response is issued and the POP3 session
-  remains in the AUTHORIZATION state.
+remains in the AUTHORIZATION state.
 Note that as the length of the shared secret increases, so does the difficulty of deriving it. As
@@ Line 141: / Line 143: @@
 shown below).
-  Possible Responses:
+__Possible Responses:__
   S: +OK maildrop locked and ready; maildrop has 1 message (320 octets)
   S: 1 120
@@ Line 148: / Line 150: @@
   S: -ERR permission denied
-  Examples:
+__Examples:__
   S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
   C: APOP mrose c4c9334bac560ecc979e58001b3e22fb
@@ Line 154: / Line 156: @@
   S: 1 369
-  In this example, the shared secret is the string `tanstaaf'. Hence, the MD5
+In this example, the shared secret is the string ''tanstaaf''. Hence, the MD5
-  algorithm is applied to the string
+algorithm is applied to the string
   <1896.697170952@dbc.mtview.ca.us>tanstaaf
-  which produces a digest value of
+which produces a digest value of ''c4c9334bac560ecc979e58001b3e22fb''
-  c4c9334bac560ecc979e58001b3e22fb
 Once the POP3 server has determined through the use of the APOP command that the client
@@ Line 184: / Line 184: @@
 message in a maildrop is assigned a message-number of "n". In HF-POP3 commands and
 responses, all message-numbers and message sizes are expressed in base-10 (i.e., decimal).
+==== The QUIT command ====
 Here is the summary for the QUIT command when used in the AUTHORIZATION state:
   QUIT
-  Arguments: none
+__Arguments:__ none
-  Restrictions: none
+__Restrictions:__ none
-  Possible Responses:
+__Possible Responses:__
   +OK
-  Examples:
+__Examples:__
   C: QUIT
   S: +OK dewey POP3 server signing off
-===== F.4.4 The TRANSACTION State =====
+===== The TRANSACTION State =====
 Once the client has successfully identified itself to the POP3 server and the POP3 server has
@@ Line 212: / Line 214: @@
 Here are the POP3 commands valid in the TRANSACTION state:
+==== The LIST Command ====
+__Usage:__
   LIST [msg]
-  Arguments:
+__Arguments:__
-  a message-number (optional), which, if present, may NOT
+a message-number (optional), which, if present, may NOT
-  refer to a message marked as deleted
+refer to a message marked as deleted
-  Restrictions:
+__Restrictions:__
-  may only be given in the TRANSACTION state
+may only be given in the TRANSACTION state
-  Discussion:
+__Discussion:__
-  If an argument was given and the POP3 server issues a positive response with a line
+If an argument was given and the POP3 server issues a positive response with a line
-  containing information for that message. This line is called a "scan listing" for that
+containing information for that message. This line is called a "scan listing" for that
-  message.
+message.
 If no argument was given and the POP3 server issues a positive response, then the response
@@ Line 240: / Line 245: @@
 Note that messages marked as deleted are not listed.
+__Possible Responses:__
+  +OK scan listing follows
+  -ERR no such message
+__Examples:__
+  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
+==== The RETR Command ====
+__Usage:__
+  RETR nn
+__Arguments:__
+a message-number (optional) which may NOT refer to a message marked as deleted
+__Restrictions:__
+may only be given in the TRANSACTION state
+__Discussion:__
+If the POP3 server issues a positive response, then the response given is multi-line. If
+an argument was given, after the initial +OK, the POP3 server sends the message
+corresponding to the given message-number, being careful to byte-stuff the
+termination character (as with all multi-line responses). If no argument was given,
+the server sends all messages in the drop which are not marked as deleted. Use UIDL
+to identify boundary between messages? If so, need to include the UIDL response as
+part of the response to APOP.
+__Possible Responses:__
+  +OK message nn follows
+  +OK m messages follow
+  -ERR no such message
+__Examples:__
+  C: RETR 1
+  S: +OK 120 octets
+  S: <the POP3 server sends the entire message here>
+  S: .
+==== The DELE Command ====
+__Usage:__
+  DELE msg
+__Arguments:__
+a message-number (required) which may NOT refer to a message marked as deleted
+Restrictions:
+may only be given in the TRANSACTION state
+__Discussion:__
+The POP3 server marks the message as deleted. Any future reference to the
+message-number associated with the message in a POP3 command generates an
+error. The POP3 server does not actually delete the message until the POP3 session
+enters the UPDATE state.
+__Possible Responses:__
+  +OK message deleted
+  -ERR no such message
+__Examples:__
+  C: DELE 1
+  S: +OK message 1 deleted
+  ...
+  C: DELE 2
+  S: -ERR message 2 already deleted
+==== The RSET Command ====
+__Usage:__
+  RSET
+__Arguments:__ none
+__Restrictions:__
+may only be given in the TRANSACTION state
+__Discussion:__
+If any messages have been marked as deleted by the POP3 server, they are unmarked.
+The POP3 server then replies with a positive response.
+__Possible Responses:__
+  +OK
+__Examples:__
+  C: RSET
+  S: +OK maildrop has 2 messages (320 octets)
+==== The STAT Command ====
+__Usage:__
+  STAT
+__Arguments:__ none
+__Restrictions:__
+  may only be given in the TRANSACTION state
+__Discussion:__
+The POP3 server issues a positive response with a line containing information for the
+maildrop. This line is called a "drop listing" for that maildrop.
+In order to simplify parsing, all POP3 servers are required to use a certain format for drop
+listings. The positive response consists of "+OK" followed by a single space, the number of
+messages in the maildrop, a single space, the size of the maildrop in octets, and the line shall
+be terminated with a CRLF pair.
+Note that messages marked as deleted are not counted in either total.
+__Possible Responses:__
+  +OK nn mm
+__Examples:__
+  C: STAT
+  S: +OK 2 320
+==== The UIDL Command (OPTIONAL) ====
+__Usage:__
+  UIDL [msg]
+__Arguments:__
+a message-number (optional), which, if present, may NOT refer to a message marked
+as deleted
+__Restrictions:__
+may only be given in the TRANSACTION state.
+__Discussion:__
+If an argument was given and the POP3 server issues a positive response with a line
+containing information for that message. This line is called a "unique-id listing" for
+that message.
+If no argument was given, then the response given is multi-line. After the initial
++OK, for each message in the maildrop, the HF-POP3 server responds with a line
+containing information for that message. This line is called a "unique-id listing" for
+that message.
+In order to simplify parsing, all POP3 servers are required to use a certain format for
+unique-id listings. A unique-id listing consists of the message-number of the
+message, followed by a single space and the unique-id of the message. No
+information follows the unique-id in the unique-id listing.
+The unique-id of a message is an arbitrary server-determined string, consisting of one
+to 70 characters in the range 0x21 to 0x7E, which uniquely identifies a message
+within a maildrop and which persists across sessions. This persistence is required
+even if a session ends without entering the UPDATE state. The server should never
+reuse an unique-id in a given maildrop, for as long as the entity using the unique-id
+exists.
+Note that messages marked as deleted are not listed.
+While it is generally preferable for server implementations to store arbitrarily
+assigned unique-ids in the maildrop, this specification is intended to permit uniqueids
+to be calculated as a hash of the message. Clients should be able to handle a
+situation where two identical copies of a message in a maildrop have the same
+unique-id.
+__Possible Responses:__
+  +OK unique-id listing follows
+  -ERR no such message
+__Examples:__
+  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
+===== The UPDATE State =====
+When the client issues the QUIT command from the TRANSACTION state, the POP3
+session enters the UPDATE state. (Note that if the client issues the QUIT command from the
+AUTHORIZATION state, the POP3 session terminates but does NOT enter the UPDATE
+state.)
+If a session terminates for some reason other than a client-issued QUIT command, the POP3
+session does NOT enter the UPDATE state and MUST not remove any messages from the
+maildrop.
+==== The QUIT Command ====
+__Usage:__
+  QUIT
+__Arguments:__ none
+__Restrictions:__ none
+__Discussion:__
+The POP3 server removes all messages marked as deleted from the maildrop and
+replies as to the status of this operation. If there is an error, such as a resource
+shortage, encountered while removing messages, the maildrop may result in having
+some or none of the messages marked as deleted be removed. In no case may the
+server remove any messages not marked as deleted.
+Whether the removal was successful or not, the server then releases any exclusiveaccess
+lock on the maildrop and closes the connection
+__Possible Responses:__
+  +OK
+  -ERR some deleted messages not removed
+__Examples:__
+  C: QUIT
+  S: +OK dewey POP3 server signing off (maildrop empty)
+  ...
+  C: QUIT
+  S: +OK dewey POP3 server signing off (2 messages left)
+  ...
+==== The TOP Command ====
+__Usage:__
+  TOP msg n
+__Arguments:__
+a message-number (required) which may NOT refer to to a message marked as
+deleted, and a non-negative number of lines (required)
+__Restrictions:__
+may only be given in the TRANSACTION state
+__Discussion:__
+If the POP3 server issues a positive response, then the response given is multi-line.
+After the initial +OK, the POP3 server sends the headers of the message, the blank
+line separating the headers from the body, and then the number of lines of the
+indicated message's body, being careful to byte-stuff the termination character (as
+with all multi-line responses).
+Note that if the number of lines requested by the POP3 client is greater than than the
+number of lines in the body, then the POP3 server sends the entire message.
+__Possible Responses:__
+  +OK top of message follows
+  -ERR no such message
+__Examples:__
+  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
+===== Scaling and Operational Considerations =====
+The HF-POP3 protocol implements a special case of a site policy in order to prevent users
+from accumulating large mail queues on the server system. These large queues can result in a
+full disk and system crashes; this problem is frequently observed in POP3 servers. Messages
+may only be downloaded once from the server, and shall be deleted after this has been
+accomplished. This could be implemented in HF-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.