[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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,

     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-

          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


       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


      C: XTND XMIT
      S: +OK Start sending message
      C: To: myfriend@somewhere.com
      C: From: me@somewhere.else.com
      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

Hansen           Expires December 11, 1998          [Page 3]

Internet Draft      POP3 XTND Extensions           June 1998

          Restrictions: may only be given in the TRANSACTION


       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


     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.


          [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

          [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]

Html markup produced by rfcmarkup 1.95, available from http://tools.ietf.org/tools/rfcmarkup/