Internet Draft: draft-hansen-pop3-xtndext-00.txt T. Hansen To-Be-Historic AT&T Labs June 1998 POP3 XTND Extensions Status of this Memo This document is an Internet-Draft. Internet- Drafts are working documents of the Internet Engineer- ing 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 inap- propriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the entire list of current Internet- Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This memo will define a Historic Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and sugges- tions for improvement are requested. Distribution of this memo is unlimited. Please send comments to the author, mailto:tony@att.com. 1. Abstract This Internet Draft describes some extensions to the Post Office Protocol [POP3] and are described here for historical purposes. The status of this Internet Draft will be Historic. Hansen Expires December 11, 1998 [Page 1] Internet Draft POP3 XTND Extensions June 1998 [XTND] describes a mechanism to extend the POP3 protocol, called XTND. Two extensions which have been implemented on some server implementations are XTND XMIT and XTND XLST; this memo describes these exten- sions. New implementations of POP3 clients and servers are not expected to implement these extensions; other mechanisms should be used instead. For example, [SMTP] should be used instead of XTND XMIT for sending email. If authentication is needed for sending email, then the proposed [ESMTP] [AUTH] extension should be used. The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" are explained in [KEYWORDS]. 2. XTND XMIT Syntax: XTND XMIT Arguments: none Restrictions: may only be given in the TRANSACTION state. Discussion: XTND XMIT is used to send mail messages. The mail messages are usually passed on to another Mail Transfer Agent (MTA) for actual transmission. Lines are read until a line consisting of a sin- gle dot (.) is received. All lines are CR-LF ter- minated. If a line of the message begins with a dot, an extra dot must be prepended to the line by the client. The server must remove these extra dots before transmission of the message. The lines are limited to 998 7-bit ASCII characters before the ter- minating CR-LF. The input MUST consist of an [RFC822] formatted mail message, containing a header with at least one To:, Cc: or Bcc: header field. [MIME] formatted mes- sages MAY be sent, but the content transfer encodings of 8bit and binary MUST NOT be used. The server MUST extract email addresses from the To:, Cc: and Bcc: headers; these addresses are then Hansen Expires December 11, 1998 [Page 2] Internet Draft POP3 XTND Extensions June 1998 used for the recipient's addresses. In SMTP terms, these values become the RCPT TO: envelope values. Bcc: headers SHOULD be removed from the transmitted email message going to the To: and Cc: recipients. The Bcc: header MAY be removed from the transmitted email message going to a Bcc: recipient; recipients MUST NOT see a Bcc: header listing anyone except possibly that recipient. The server SHOULD check that the address given in the From: header is associated with the authenti- cated user. In SMTP terms, the server should use a MAIL FROM value which is known to be valid and which is associ- ated with the authenticated user. (This may be the user name under which the user is logged in.) Possible Responses After Command: +OK message can be sent -ERR message was invalid or cannot be sent Possible Responses After Final dot-CRLF: +OK message was successfully transmitted -ERR message was unable to be delivered successfully Example: C: XTND XMIT S: +OK Start sending message C: To: myfriend@somewhere.com C: From: me@somewhere.else.com C: C: Welcome back! C: . S: +OK message sent successfully 3. XTND XLST Syntax: XTND XLST header [num] Arguments: a header name and an optional message number. Hansen Expires December 11, 1998 [Page 3] Internet Draft POP3 XTND Extensions June 1998 Restrictions: may only be given in the TRANSACTION state. Discussion: XTDN XLST extracts a given header from a given mes- sage. If no message number is given, the header's value is extracted for all messages which are not currently marked for deletion. Each header is preceded with the message number. If the header field's value has continuation lines, those continuation lines are presented as separate lines, along with the leading whitespace. After the last header's value is presented, a line consisting of a single dot (.) is transmitted. All lines must be CRLF terminated. Case is ignored when searching for a header. Possible Responses After Command: +OK - header was extracted successfully -ERR - header was not extracted successfully Examples: C: XTND XLST Subject: S: +OK Header list follows: S: 1 Subject: Hi there! S: 3 Subject: this message has a very S: long header. S: 5 Subject: Coming to the party? S: . C: XTND XLST Subject: 1 S: +OK Header list follows: S: 1 Subject: Hi there! S: . 4. Security Issues XTND XMIT is equivalent to using the SMTP protocol for sending email, with the additional access control provided by logging into the POP session. The security of the mechanism used for logging into the POP session will affect the reliability of the user name used for transmitting the mail. Hansen Expires December 11, 1998 [Page 4] Internet Draft POP3 XTND Extensions June 1998 XTND XLST adds no security issues. References [AUTH] "SMTP Service Extension for Authentica- tion", J. Myers, Work in Progress, February 1998, . [ESMTP] "SMTP Service Extensions", J. Klensin, N. Freed, M. Rose, E. Stefferud & D. Crocker. November 1995, RFC 1869. [KEYWORDS] "Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997, RFC 2119, BCP 14. [MIME] "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", N. Freed & N. Borenstein, November 1996, RFC 2045. [POP3] J. Myers & M. Rose, "Post Office Protocol - Version 3", May 1996, RFC 1939, STD 53. [RFC822] "Standard for the Format of ARPA Internet Text Messages", D. Crocker, August 1982, RFC 822, STD 11. [SMTP] "Simple Mail Transfer Protocol", J. Postel, August 1982, RFC 821, STD 10. [XTND] M. Rose, "Post Office Protocol - Version 3, Extended Service Offerings", November 1988, RFC 1082. Author Address Tony Hansen AT&T Laboratories Room LZ 1B-214 307 Middletown-Lincroft Rd. Lincroft, NJ 07738, USA Phone: +1 732 576 3207 Fax: +1 732 576 3207 Email: tony@att.com Hansen Expires December 11, 1998 [Page 5]