Internet DRAFT - draft-hansen-pop3-xtndext
draft-hansen-pop3-xtndext
Internet Draft: draft-hansen-pop3-xtndext-00.txt T. Hansen
To-Be-Historic AT&T Labs
June 1998
POP3 XTND Extensions
<draft-hansen-pop3-xtndext-00.txt>
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,
<draft-myers-smtp-auth-*.txt>.
[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]
