INTERNET-DRAFT INTERNET-DRAFT A. Rundegren 7 May, 2000 Extended RETR - Extension to POP3 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Please send comments to the author. Abstract This memo introduces an extension to the RETR command in the POP3 protocol. The extension makes it possible for an interrupted RETR command to be continued. This is particularly useful when downloading large messages over unstable connections. A. Rundegren [page 1] INTERNET-DRAFT 7 May, 2000 Table of Contents 1. Introduction ........................................... 2 2. The Extended RETR Command .............................. 2 2.1 RFC 1939 Specification .............................. 2 2.2 The Offset Argument ................................. 3 2.3 Bytestuffing ........................................ 4 3. Extended Response Codes ................................ 5 4. The CAPA Tag ........................................... 5 5. Security Considerations ................................ 6 6. Acknowledgements ....................................... 6 7. References ............................................. 6 8. Author's Address ....................................... 6 1. Introduction When email was first developed it was intended to transfer readable text messages. Since the introduction of MIME (RFC 2045) it has become more common to transfer other message parts, more commonly known as attachments. These attachments are often much larger than the readable textparts. The current POP3 specification requires messages to be re-downloaded from scratch in the case of a premature disconnect during a message transfer. Such disconnects happens for various reasons, including poor phone line quality, modem setup, network packet loss and temporary network problems. By extending the RETR command, the download-and-delete model that characterizes the POP3 protocol becomes more complete in handling todays requirements of email. The benefits are: a) Less time used online for the client b) Less consumption of bandwidth c) Less resources used on the server-side 2. The Extended RETR Command This section will give a detailed view on how the second argument of the extended RETR command should be implemented. 2.1 RFC 1939 Specification The RETR command (as specified by RFC 1939), takes one argument which specifies the message to be retrieved by the client. The allowed responses are "+OK" and "-ERR", without the quotes, possibly followed by a space and a comment. A. Rundegren [page 2] INTERNET-DRAFT 7 May, 2000 2.2 The Offset Argument The second argument to the extended RETR command specifies the offset in the message of where the transfer should start. The offset is given in octets, and is calculated the way message sizes are, as defined in section 11 of RFC 1939. In order to ensure a valid multi-line response, with all lines terminated with a CRLF pair, the offset MUST NOT point into the middle of a CRLF pair. As specified by RFC 1939, responses can not be more htan 512 characters long, including the terminating CRLF. Implementors should note that there is no guarantee that the message numbering stays the same between sessions. In order to ensure the validity of a downloaded message, the use of a UIDL command is required. The syntax of the extended RETR command would be: RETR msg offset Arguments: A message-number (required) which may NOT refer to a message marked as deleted. An offset (optional) of where to start the transfer, specified in octets. If the offset argument is omitted, the message will be sent as specified by the RETR command in RFC 1939. Description: If the POP3 server issues a positive response, then the response given is multi-line. After the initial +OK, the POP3 server sends the message corresponding to the given message-number, starting from the offset provided, being careful to byte-stuff the termination character (as with all multi-line responses). Possible Responses: +OK message follows -ERR no such message Examples: C: RETR 1 345628 S: +OK 1253512 octets S: S: . A. Rundegren [page 3] INTERNET-DRAFT 7 May, 2000 If the specified offset is beyond the size of the message being retrieved, points into the middle of a CRLF pair, or is in any way erroneous in its syntax, the server should respond with a negative response code. This would however not distinguish the type of error. In the following section you can read about the use of extended response codes to clarify errormessages. 2.3 Bytestuffing This section explains how bytestuffing should be performed when resuming a previously interrupted transfer. When data is to be transferred from the server to the client, the server should be careful to byte-stuff all data. If the previous transfer was interrupted in the middle of a line, where the remaining part of the line starts with a '.' character, this means that data, that would normally not be bytestuffed (since it's not in the beginning of a line), must be byte-stuffed. Any octets added by any data-stuffing algorithm do not count as part of the offset used by the Extended RETR command. Examples: Message number is 1. Message size is 217,743 octets. Offset 113,435 starts with a '.'. Lets assume, that when transferring the above message, an interrupt occurs after exactly 113,435 octets. When resuming the transfer, the client executes "RETR 1 113435". The server then byte-stuffs the data before transferring it to the client, who then byte-destuffs the data before appending it to the previously transferred data. A. Rundegren [page 4] INTERNET-DRAFT 7 May, 2000 3. Extended Response Codes The extended RETR command does not require the implementation of extended response codes (RFC 2449) to be present in order to work. However, this memo specifies the extended response codes to be used if implemented. If the specified offset is beyond the size of the message being retrieved, the extended response code should be: -ERR [OFFSET-OVERRUN] message exists If an error occured because the message was not present on the server, the extended response code should be: -ERR [NON-EXISTENT] no such message For all other type of errors, a simple "-ERR" is sufficient. 4. The CAPA Tag The extended RETR command introduces a new CAPA tag (RFC 2449). This tag tells the client that the server is able to continue interrupted RETR commands. Its implementation is mandatory if the server supports this extension and the CAPA command. CAPA tag: EXT-RETR Arguments: none Added commands: n/a Standard commands affected: RETR Announced states / possible differences: both / no Commands valid in states: TRANSACTION Specification reference: [POP3, this document] Discussion: The extended RETR capability indicates that the server is capable of excepting a second argument to the RETR command in order to resume a previously interrupted RETR command. A. Rundegren [page 5] INTERNET-DRAFT 7 May, 2000 5. Security Considerations This extension is believed not to introduce additional security issues. Use of the extended RETR command sends messages in the clear over the network, unless an encryption layer has been previously negotiated. 6. Acknowledgements The extension introduced in this memo is based on the RETR command as specified in RFC 1939. I would like to thank R. Gellens, C. Newman and L. Lundblade for their comments and suggestions during the drafting of this document. 7. References 1) Post Office Protocol - Version 3 (RFC 1939). J. Myers, M. Rose. 2) Multipurpose Internet Mail Extensions, Part One (RFC 2045). N. Freed, N. Borenstein. 3) POP3 Extension Mechanism (RFC 2449). R. Gellens, C. Newman, L. Lundblade. 8. Author's Address Anders Rundegren Skimmelgatan 1 212 35 Malmo Sweden email: anders@rundegren.com A. Rundegren [page 6]