[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: working group last call on ISP draft
- To: grip-wg@UU.NET
- Subject: Re: working group last call on ISP draft
- From: hansen@pegasus4.bl-els.att.com
- Date: Thu, 5 Mar 1998 17:40 EST
- >from: hansen@pegasus.att.com
- Comment: grip-wg mailing list add/drop requests to Majordomo@TransSys.COM
- Organization: AT&T Laboratories
< Seriously, an informational draft describing it would be very welcome.
< When you finish writing it you should submit it to
< Internet-Drafts@ietf.org, and you should also solicit comments on the
< DRUMS working group. Though it's not within their charter to discuss
< this, it's the most appropriate place. In addition, I know that Chris
< Newman and John Myers who are involved in DRUMS have strong opinions about
< XTND XMIT and they would be able to give you some good feedback.
Before I pass it on to DRUMS or internet-drafts@ietf.org, let me give it a
pass here first. Comments are welcome, particularly in the "Security
Considerations" section.
(I gave it a filename using the auspices of the grip working group. I hope
that's okay.)
Tony Hansen
tony@att.com, tony@attmail.com
GRIP Working Group T. Hansen
Internet Draft: draft-ietf-grip-hansen-xtnd-00.txt AT&T Labs
Experimental March 1998
POP3 XTND Extensions
<draft-ietf-grip-hansen-xtnd-00.txt>
Status of this Memo
This document is an Internet Draft. 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. Internet Drafts 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 a
``working draft'' or ``work in progress.''
To learn the current status of any Internet Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
This memo defines an Experimental Protocol for the Internet
community. This memo does not specify an Internet standard of any
kind. Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Please send comments to the IETF GRIP mailing list, grip-wg@uu.net.
To subscribe, send a message to grip-wg-request@uu.net with a body
which says ``subscribe''.
Abstract
This Request for Comments describes some experimental extensions to
the Post Office Protocol [POP3]. These extensions are described
here for historical purposes. The status of this RFC is
Experimental. New implementations of POP3 clients and servers are
Hansen Expires October 1, 1998 [Page 1]
Internet Draft POP3 XTND Extensions March 1998
not expected to implement these extensions.
1. Introduction
[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 extensions.
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 message is
usually passed on to another Mail Transfer Agent (MTA) for actual
transmission.
Lines are read until a line consisting of a single dot (.) is
received. All lines are CR-LF terminated. If a line 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.
The input MUST consist of an [RFC822] formatted mail message,
containing a header with at least one To:, Cc: or Bcc: header
field.
The server MUST extract email addresses from the To:, Cc: and
Bcc: headers. These addresses are used for the recipients. In
SMTP [SMTP] terms, these values become the RCPT TO: envelope
values.
Bcc: headers MUST 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:
Hansen Expires October 1, 1998 [Page 2]
Internet Draft POP3 XTND Extensions March 1998
recipient; recipients MUST NOT see a Bcc: header listing anyone
except possibly that recipient.
In SMTP terms, the user name under which the user is logged in
becomes the MAIL FROM: envelope value.
Possible Responses After Command:
+OK message can be sent
-ERR message 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 a message number (optionally).
Restrictions: may only be given in the TRANSACTION state.
Discussion:
XTDN XLST extracts a given header from a given message. 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
Hansen Expires October 1, 1998 [Page 3]
Internet Draft POP3 XTND Extensions March 1998
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 validation 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.
XTND XLST adds no security issues.
References
[SMTP] Postel, J., ``Simple Mail Transfer Protocol'', August 1982,
RFC 821, STD 10.
[RFC822] David H. Crocker, ``Standard for the Format of ARPA
Internet Text Messages'', August 1982, RFC 822, STD 11.
[XTND] M. Rose, ``Post Office Protocol - Version 3, Extended
Service Offerings'', November 1988, RFC 1082.
[POP3] Myers, J., & Rose, M., ``Post Office Protocol - Version 3'',
May 1996, RFC 1939, STD 53.
Hansen Expires October 1, 1998 [Page 4]
Internet Draft POP3 XTND Extensions March 1998
[KEYWORDS] Bradner, ``Key words for use in RFCs to Indicate
Requirement Levels'', March 1997, RFC 2119, BCP 14.
Author Address
Tony Hansen
AT&T Laboratories
307 Middletown-Lincroft Rd.
Lincroft, NJ 07738, USA
Phone: +1 732 576 3207
Fax: +1 732 576 3207
Email: tony@att.com
Hansen Expires October 1, 1998 [Page 5]