taylor@hplabsc.UUCP (Dave Taylor) (04/11/86)
Comments on the Post Office Protocol, Version 2 (aka RFC-937) First off, I think this is a very reasonable protocol and has the advantage of being SIMPLE and easy to implement (a big plus). There are, however, a few problems in the document, namely; 1. It's not clear whether the request for a specific message to be transmitted (ie READ nnn) will be interpreted as relative to the Beginning of the folder/mailbox or relative to the current message 2. At one point the document indicates that the client transmits a "RETR" command with the server immediately responding with the message data. Later on, however, it is stated that the RETR "must be followed by an acknowledgement command". Perhaps the problem is that the quoted sentence should be changed to read something more like "the RETR command, with the server immediately transmitting the message. Completion of this transaction must be acknowledged by the client." 3. For lack of confusion, I suggest that arguments like "user" (login account name) and so on are either delimited by a different type face (ideally italicized) or surrounded by metacharacters as in "/usr/<user>"... 4. The default mailboxes for Unix are strange. Specifically, I've never heard of any Unix system that queues mail in /usr/<user>/Mail/inbox/* On the other hand, "/usr/mail/<user>" is quite common on Bell systems... 5. The FOLD command should have "- error report" added as a possible response by the server. Otherwise, how does the client learn that the requested access has been denied? 6. If the client requests a deletion of a message (ACKD) and permission is denied, how is this indicated? 7. Why does a RETR of 0 characters terminate the connection?? 8. In the sequence RETR 2 ; <send> ; ACKD ; RETR 1 ; <send> ; ACKS the return should be different from the sequence HELO a b ; #1 ; RETR ; < send > ; ACKS. That is, the return should distinguish between no-more-messages and next-message-marked-as-deleted. (In fact, in the latter case, perhaps the ACK* should increment the current-message to the next UNDELETED message or EOF, which- ever comes first) 9. In a more general sense, it would be interesting to have a similar protocol for queueing OUTBOUND messages too...(to be distinguished from the UUCP wait-till-it-calls-us method) I await responses from either the original POP2 team or anyone else who knows the protocol. -- Dave Taylor taylor@HPLABS -or- hplabs!taylor
dpk@mcvax.uucp (Doug Kingston) (04/13/86)
A number of good points were made, however a couple of the comments deserve further comment: In article <22000002@hplabsc.UUCP> taylor@hplabsc.UUCP writes: > 4. The default mailboxes for Unix are strange. Specifically, I've > never heard of any Unix system that queues mail in > /usr/<user>/Mail/inbox/* > On the other hand, "/usr/mail/<user>" is quite common on Bell > systems... Yes indeed. The suggestion of putting user directories under /usr is a mistake. It greatly complicates system administration. Reference to specific os dependent strings should be avoided in an Internet spec. > 8. In the sequence RETR 2 ; <send> ; ACKD ; RETR 1 ; <send> ; ACKS > the return should be different from the sequence HELO a b ; #1 ; > RETR ; < send > ; ACKS. That is, the return should distinguish > between no-more-messages and next-message-marked-as-deleted. > (In fact, in the latter case, perhaps the ACK* should increment > the current-message to the next UNDELETED message or EOF, which- > ever comes first) I disagree with the latter comment in parens. The behavior of ACK* should be very predictable so the client and server do not get out of sync. Don't increment by more than one each time. If the next message is "deleted", say so. > 9. In a more general sense, it would be interesting to have a > similar protocol for queueing OUTBOUND messages too...(to be > distinguished from the UUCP wait-till-it-calls-us method) > It's called SMTP, RFC-821. (if I understood your desire properly...) Cheers, -Doug-
chase@isi-hobgoblin.UUCP (04/23/86)
Dave- I will try to address each of your points. 1. When a READ nnnn request is sent, the argument is relative to the beginning of the folder (ie, it's absolute). 2. The sentence that states that the RETR command "must be followed by an acknowledgement command" could use a little reworking and/or relocation. The intent is that this ack command (one of ACKS, ACKD or NACK) is sent after the server has completed sending the requested message, and indicates the success or failure of receiving the message. 3. The suggestion of delimiting arguments like the login name with metacharacters in the document is a good one in general, although in some cases such conventions can be more confusing than helpful. Italics would be ideal for a strictly hardcopy version. Pains were taken in the specific instances of these arguments to be clear in the rfc. 4. The reference to /usr/spool/mail/user and /usr/user/Mail/inbox/* (where "user" is the value supplied in the HELO command [here's another instance of 3. above ;]), is indeed a localism. A note should be made to this effect at the least. The intent is mostly to point out the need to consider both the directory where the system queues incoming mail and the directory where some other mail program(s) have "inc'd" mail. The fact that none of the authors (least of all myself) are unix gurus sticks out here. 5. Responses to the FOLD command can indicate that access has been denied, or any other condition, in the option text string that follows the # response (ie, #0 Read access denied). 6. If the client requests deletion of a message with the ACKD command, and the client does not have write access to the folder, the folder is not changed. As above, this may be indicated in the optional text of the response (ie, =cccc Previous message not deleted [where cccc is the number of characters in the following message]). 7. A RETR of a 0 character message is viewed as anomalous. Recovery would likely be non-trivial. One of the guiding principles of the protocol is stated in paragraph 3 of page 2, "if anything goes wrong close the connection". We really do want to keep it simple. 8. As to whether the response to an ACKS (or ACKD) should distinguish between no-more-messages and next-message-is-deleted, there shouldn't be a difference as far as the protocol is concerned. The "=0" response indicates that a RETR command (without an argument) will not be appropriate. If there are more messages, the client already knows that based on the number of messages reported when the folder was first opened. Again, an optional text field should suffice (ie, =0 no more messages [an example taken directly from the example scenario in the rfc]). 9. As dpk points out, SMTP is the appropriate protocol for queueing outbound messages. It is, in fact, in use in conjunction with POP on local PCs at ISI. <>Dale Chase