[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                              D. Coulter
Expires: February 9, 1999                               August 9, 1998
Filename: draft-coulter-pmap-00.txt

                      Proxy Mail Address Protocol

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 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."

   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).

Abstract

   This specification defines a service that manages a type of
   disposable Internet mail address known as a proxy address.  Proxy
   addresses conform to the standard addressing scheme [RFC 822] and
   exist in the same address space, but act as aliases for regular,
   fixed addresses.  Users may own many at a time and allocate and
   deallocate them at will.

   Proxy addresses offer a defense against junk mail by allowing
   individuals to control access to their mailboxes by creating
   addresses for specific contacts or purposes.  If unwanted mail
   arrives addressed to a proxy, the user may delete or suspend the
   proxy address to remove the intrusive sender's means of accessing
   the mailbox.

   The service also defines a distinct command-response interface for
   use between client and server implementations to conduct management
   chores.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
   2. Anatomy of a Proxy Address . . . . . . . . . . . . . . . . .  4
   3. User Accounts  . . . . . . . . . . . . . . . . . . . . . . .  5
   4. Mail Delivery  . . . . . . . . . . . . . . . . . . . . . . .  6


Expires 09-Feb-1999   draft-coulter-pmap-00.txt               [Page 1]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   5. Command-Response Interface . . . . . . . . . . . . . . . . .  7
   5.1 Commands  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6. Command Reference  . . . . . . . . . . . . . . . . . . . . .  9
   6.1 PMAP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   6.2 AUTH  . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.3 NEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.4 DEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   6.5 SUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.6 REM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   6.7 STAT  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   6.8 LIST  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   6.9 DONE  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   7. Example Sessions . . . . . . . . . . . . . . . . . . . . . . 15
   8. Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.1 Commands  . . . . . . . . . . . . . . . . . . . . . . . . . 17
   8.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 18
   9. Security Considerations  . . . . . . . . . . . . . . . . . . 20
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . 21
   11. Contact Information . . . . . . . . . . . . . . . . . . . . 21

1.   Introduction

   Perhaps the most intrusive form of Internet mail abuse, the
   unsolicited mail problem is a chronic aggravation that users are
   generally powerless to stop or prevent.  Many forums have played
   host to endless criticism of the problem, particularly leveled
   against those who engage in the activity and their tactics, but few
   solutions have come to the forefront that provide users an adequate
   defense.  While economic and social influences define the human
   side of the problem, the permissiveness of the Internet mail
   architecture with regard to the freedoms it grants senders, as well
   as the fixed relationship between mailbox and address, are the
   critical factors that provide opportunity to those who would abuse
   it.

   Consistent with the Internet's cultural identity of openness and
   emphasis on personal responsibility, Internet mail grants users the
   right to send to any addressable mailbox; if an address is known,
   anyone can address mail to it.  Although the act of sending a
   message is, in essence, an imposition on the recipient,
   responsibility for the content and quantity of mail sent is the
   sole dominion of the sender.  The benefits of mail service
   notwithstanding, a mailbox is a privilege not without obligation,
   as individuals have no say over the receipt of inbound mail.
   Filtering offers a partial solution, but it cannot compensate for
   these properties of the underlying architecture.

   Moreover, once junk mailers or any unwelcome source gets hold of an
   address, especially if they distribute it, there is no escape from
   the inevitable, short of abandoning the address.  In general,
   Internet mail service consists of two distinct entities, the


Expires 09-Feb-1999   draft-coulter-pmap-00.txt               [Page 2]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   mailbox and the address.  The mailbox is an open container into
   which delivered mail is placed, while the purpose of an address is
   to provide its associated mailbox visibility on the network and
   represent insert privilege to senders.  The powerlessness that
   users experience when faced with junk mail is rooted in the
   singular, fixed relationship between regular addresses and their
   corresponding mailboxes, where mailbox and address are often
   considered indistinct.  This suggests the need for a plurality of
   addresses associated with each mailbox.

   Proxy addresses empower individuals against unsolicited mail by
   emphasizing a many-to-one relationship between address and mailbox,
   as opposed to the traditional notion of one mailbox, one address.
   More succinctly, proxy addresses act as disposable front ends, or
   aliases, for regular, fixed addresses, and are allocated and
   deallocated directly by user command without administrator
   involvement.  Though address aliasing can be achieved in other
   ways, such as by forwarding from other addresses (e.g., using the
   .forward file on Unix systems) or through mail handler rules that
   map multiple addresses to a single mailbox, they lack the
   purposefulness and manageability of proxy addresses.

   The opportunity to have more than one address on a mailbox allows a
   user to create numerous addresses, one for each contact or purpose.
   In any situation in which an address is called for, such as on
   forms or in environments that have a public distribution, the user
   should offer a proxy address instead of a regular address.  For
   example, proxy addresses are ideal as return addresses on posts to
   USENET newsgroups, which are scanned for users' mail addresses en
   masse by those who distribute unsolicited mailings.  Should
   unwanted mail begin to arrive addressed to a proxy, or when it is
   no longer needed, the user may delete or suspend the address,
   terminating the intrusion by removing the aforementioned visibility
   and insert privilege.  The prerogative to create an address
   expressly for a given contact and remove it in the event of abuse
   lets recipients selectively apportion access rights to their
   mailboxes on an individual basis.

   Proxy addresses also frustrate those who distribute addresses.  The
   user controlled lifetime of proxy addresses deters their keeping in
   address databases, as bulk mailers are unlikely to want their
   mailing lists waterlogged by hordes of potentially useless
   addresses.  Further, mail from an unexpected source clearly
   indicates that a party to whom a proxy address was intentionally
   given has shared the address.  Proxy addresses yield another
   benefit in that, unlike regular addresses, which often consist of
   parts that concede a user's name, their opacity (see Section 2)
   provides a wall of anonymity that masks such information.  In
   certain on-line activities, such as chat sessions, uncertainty
   exists when other participants request a mail address, especially
   if from a child and the address indicates a name or whereabouts.



Expires 09-Feb-1999   draft-coulter-pmap-00.txt               [Page 3]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   It should be noted that the cancellation of a proxy address does
   not pose the inconvenience that canceling a regular address does,
   since the optimal use of proxy addresses is to have many in
   circulation, each held by a particular contact or existing for a
   specific purpose.  A regular address is frequently a user's only
   address, or one of a few, and issued to contacts far and wide.  By
   contrast, when a proxy address is deleted or suspended, it impacts
   only a specific distribution, the likely provocation for the
   action, obviating the need to inform numerous contacts of a change.
   In addition, it often proves difficult to cancel or change a
   regular address without disturbing the service account with which
   it is provided, since mail service is usually an adjunct to other
   services, such as Internet access provision or on-line portal
   sites.

2.   Anatomy of a Proxy Address

   A proxy address is a standard Internet mail address [RFC 822],
   consisting of a local part, a "@" symbol, and a domain part.  The
   principal of a proxy address is the local part, which is the
   concatenation of a single ampersand character followed by a string
   of precisely eight randomly generated alphanumeric characters.  The
   ampersand serves to help implementations discern proxy from non-
   proxy addresses.  The latter, called a proxy identifier, represents
   a unique value that keys a proxy address within an address space of
   other proxy addresses managed at an installation.  In conjunction
   with the other elements, the identifier forms a proxy address, as
   in &38K000PL@myu.edu, &2II9V9JH@research.myu.edu, or
   &DF989M41@myisp.net, for example.  Identifiers are not case
   sensitive; thus, 0000000A and 0000000a, for example, are identical.

   Though a proxy address is uniquely described by its identifier
   within the address space of a single database, implementations are
   free to allow for any number of address spaces, hence databases,
   from which proxy addresses are allocated.  This document, however,
   does not stipulate how multiple address spaces at an installation
   are differentiated in terms of the one from which a newly created
   proxy address is allocated.  The domain name of a user's regular
   address, however, is an obvious choice.

   Despite giving proxy addresses a cryptic appearance, identifiers
   are randomly generated, because far fewer address combinations
   would occur in practice if they were user selectable.  Machine
   chosen identifiers, on the other hand, give each value out of the
   entire set of 36^8 (i.e., eight alphanumeric characters), or some
   2.8 trillion, possibilities equal standing.  A large, balanced set
   of addresses significantly reduces the effectiveness of random or
   brute force attempts to send unwanted mail into a group of proxy
   addresses.

   The all-zero identifier is a special case.  A proxy address with
   this identifier (e.g., &00000000@myu.edu) is called a null proxy


Expires 09-Feb-1999   draft-coulter-pmap-00.txt               [Page 4]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   and owned by an installation's administrator.  The all-zero
   identifier is never assigned to a proxy address allocated by an
   ordinary user.

   In addition to its identifier, a proxy address carries three other
   attributes: the name of the user account of its owner, its
   suspension state, and a remark.  The user account name string
   serves to connect the proxy address to its owner's account, which,
   in turn, holds the regular address to which the proxy is mapped.
   The suspension attribute is a Boolean value, represented by either
   the character "0", for false, or active, or "1", for true, or
   suspended.  A proxy address in the suspended state responds to
   incoming mail as if it were non-existent.  The remark, a string of
   up to 64 characters, is freely set, used for such things as a
   short, user defined message about the purpose of the proxy address
   or arbitrary data assigned by the client implementation to help it
   in the management of multiple proxies.  The user has charge over
   suspension and the remark; the proxy identifier and user account
   reference are assigned at creation for the lifetime of the proxy
   address.

3.   User Accounts

   Each proxy address is associated with a single user account.
   Association grants the account holder the right to have mail
   addressed to a proxy directed to the regular address specified by
   the account's address attribute, as well as permission to view or
   change the proxy's attributes.  A server implementation maintains a
   database of user accounts, each of which have, principally, an
   identifying username, a password, and an address attribute.  The
   username and password are arbitrary strings of visible characters,
   though implementations may determine case sensitivity or impose
   string length limits or additional character constraints as they
   see fit.  As stated previously, a proxy address references its
   associated account by citing this username.  The address attribute
   stores a standard Internet mail address, the regular address
   coupled with the owner's mailbox.  The proxy address is translated
   into this address by implementations during mail processing.

   The password prevents the manipulation of proxy addresses belonging
   to other users.  All interactions between client and server take
   place in authenticated sessions, in which both username and
   password have been verified.  During authentication, a client may
   transmit either a clear text password or a digest based on the
   password protection scheme described in Section 6.2.

   A user account has two other attributes: the number of proxy
   addresses currently owned and the maximum number that may be owned.
   An error results if the user attempts to create proxy addresses
   beyond this limit.  It is suggested that a reasonable default
   maximum for most users be in the range of 10 to 20 proxy addresses.
   Implementations should allow the administrator to adjust this limit


Expires 09-Feb-1999   draft-coulter-pmap-00.txt               [Page 5]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   for each user.

4.   Mail Delivery

   On its way from source to destination, a message is routed through
   one or more SMTP [RFC 821] servers.  At each stop, a server either
   advances the message along its source route, if specified, or
   determines the action to take based on the message's recipient
   address, either delivering, rejecting, or forwarding the message.
   In the case of a proxy address, whose role is to front a regular
   address, which, in turn, corresponds to a mailbox, the server
   consults its proxy address and user account databases to translate
   the proxy address into the corresponding regular address, on which
   the installation's normal mail handling decisions are performed.
   No part of the message data is modified, although a server may
   prepend its usual Received header field [RFC 822], the "for" sub-
   field specifying the translated regular address rather than the
   proxy address.  The regular address becomes the message's operative
   recipient address for purposes of mail processing at the current
   and subsequent stops.  In some cases, servers may choose an action
   based upon the proxy address itself, rather than performing the
   translation, such as to forward all incoming proxy addressed mail
   to another server.

   Administrators and users should be aware that a delivery status
   notification returned to a sender may include a copy of the
   transmitted message containing Received header fields that cite the
   regular address translated from the original proxy address.  Given
   that a proxy address should conceal its corresponding regular
   address from senders, this presents a security risk for proxy
   address owners.  In particular, forwarding is an issue, because
   messages acquire such marks that include the translated regular
   address at each forwarding hop.  If an error occurs prior to final
   delivery, the delivery status notification returned to sender would
   disclose the address.  Success notifications returned by recipients
   on delivery should also be considered.

   On the client side, implementations provide users the means with
   which to allocate and deallocate proxy addresses, and view and
   change their attributes.  For received proxy addressed mail,
   implementers should be mindful that, despite the plurality of proxy
   addresses with respect to a regular address, mail is retrieved from
   a single mailbox and presented to users in the usual ways.  Users,
   though, may find user interface options that display or sort
   received mail by recipient address, hence proxy address, useful.
   For outgoing mail, implementations should offer the user a choice
   as to which proxy address to use as the source address on new
   messages.  For replies, clients may volunteer the recipient proxy
   address of the received message as the reply's source address,
   provided it is a proxy address that the user owns.  Ultimately, in
   support of the aims discussed in Section 1, the onus is on client
   applications to promote optimal use of proxy addresses through


Expires 09-Feb-1999   draft-coulter-pmap-00.txt               [Page 6]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   effective user interface design.

5.   Command-Response Interface

   To facilitate the management of proxy addresses, this specification
   defines a distinct command-response interface for use between
   connected client and server implementations.  As its principal
   mission is the allocation of mail addresses, support for the
   service is ideally embedded within SMTP [RFC 821] implementations.
   PMAP services, therefore, are made available through TCP listening
   port 25, that assigned SMTP.  Clients in this context are typically
   applications executed on personal workstations that render the
   protocol's functionality for end users.  A server implementation,
   on the other hand, executes on a machine that has sufficient
   connectivity and processing resources to provide back end services
   to multiple users.  A PMAP server maintains databases of local user
   accounts and proxy addresses for mail handlers to check when
   processing mail and clients to access in the management of proxy
   addresses.

   As stated, PMAP support is best provided closely alongside that for
   SMTP, its command-response interface available as an alternative to
   that of SMTP.  Once a network connection is established, a client
   chooses to initiate one of either protocol session, issuing the
   PMAP command instead of the HELO [RFC 821] (or EHLO [RFC 1869])
   command to initiate a PMAP session instead of a SMTP session.  As
   the PMAP command is the only extension to the SMTP command space in
   this document, it is unrecognized in a PMAP session.

   Sessions provide the context for interaction between client and
   server implementations.  The client initiates an interaction by
   sending a command to the server, which carries out the requested
   task and returns a response upon completion.  All tasks are
   stateless in that they complete within the scope of a single
   interaction.

   Command and response lines are limited to a maximum of 512
   characters, including terminator.  All PMAP syntactic elements are
   encoded as 7-bit, US-ASCII text [US-ASCII].  Implementations should
   observe case independence with respect to all syntactic elements
   containing alphabetic characters.

5.1  Commands

   A command is transmitted as a line of text, consisting of a command
   verb, any required arguments, where each is preceded by a space
   character, and a terminating carriage return/linefeed pair:

      command-line = verb * ( SP argument ) CRLF

   PMAP defines eight commands for use in a PMAP session: AUTH, NEW,
   DEL, SUS, REM, STAT, LIST, and DONE.


Expires 09-Feb-1999   draft-coulter-pmap-00.txt               [Page 7]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   The AUTH command is used to declare the username and password of
   the user account with which to bind the session.  Except for the
   DONE command, which ends a PMAP session, it must be issued in a
   session before any other command can succeed and is illegal once
   the user is authenticated.

   NEW and DEL create and delete proxy addresses, respectively, while
   SUS and REM modify their suspension states and remarks.  STAT
   retrieves the attributes of either a proxy address or the session's
   authenticated user account, depending on the presence of an
   argument.  LIST returns the identifiers of the proxy addresses
   owned by the authenticated user.  Lastly, the DONE command is used
   to close a PMAP session and revert to a SMTP session.  As stated,
   the PMAP command is valid only in a SMTP session.

5.2  Responses

   A PMAP session response, like a command, is a line of text
   terminated by a carriage return/linefeed pair, whose parameters and
   optional comment are each preceded by a space character:

      response-line = status-char ( SP error-keyword /
         * ( SP success-parameter ) ) [ SP comment ] [ CRLF
         multi-line-list-reply ] CRLF

   The comment strings are defined by implementers, with some
   suggestions in Section 7.

   This response definition is specific only to PMAP session commands.
   The PMAP command, which is used outside of a PMAP session, is
   exceptional in that, while its success response conforms to the
   above, its failure response is a three-digit SMTP result code.  The
   DONE command, also, generates responses in either protocol session,
   though conversely.

   The first element of a PMAP response line is the status character,
   whose value is either a plus symbol ("+"), for success, or a minus
   symbol ("-"), for failure.  A success response may include
   parameters determined by the foregoing command:

      success-response-line = "+" * ( SP success-parameter )
         [ SP comment ] CRLF

   The LIST command is unique in that it returns a multi-line
   response.

   On failure, a PMAP response line contains one of five error
   keywords that describes the cause of the failure, following the
   status character:

      failure-response-line = "-" SP ( "SYN" / "GEN" / "ID" / "AUTH" /



Expires 09-Feb-1999   draft-coulter-pmap-00.txt               [Page 8]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


         "MAX" ) [ SP comment ] CRLF

   The SYN error keyword is returned as a result of any syntax or
   parsing error, such as an unrecognized command or invalid argument.
   GEN indicates a general error condition, where the implementation
   is unable to carry out the requested task; for example, an attempt
   to create a new proxy cannot succeed because of a resource
   limitation.

   The ID error keyword is returnable only from commands that take a
   proxy identifier as an argument.  It indicates that the session's
   authenticated user does not own the identified proxy, either
   because it belongs to another user or does not exist.  The AUTH
   keyword is returned when the username or password arguments to the
   AUTH command do not correspond to those of any account on the
   server.  It may also result if any command other than AUTH or DONE
   is issued in a session before a successful authentication or if the
   AUTH command is issued when a user has already been authenticated.

   Unlike the other error keywords, MAX is returned as a potential
   failure response only by the NEW command.  It indicates that an
   attempt to create a new proxy address exceeds the limit allowed for
   the user account.

6.   Command Reference

   The error keywords of potential failure responses are given at the
   end of each command subsection.  Only the failures specific to each
   command or its arguments are given explicitly.

6.1  PMAP

   PMAP is the only command defined herein that exists in the SMTP
   [RFC 821], as opposed to the PMAP, command space.  Consequently,
   the PMAP command is unrecognized in a PMAP session.  Valid at any
   point in a SMTP session where the QUIT [RFC 821] command may be
   used, the PMAP command signals the server of the client's desire to
   transition from a SMTP to a PMAP session.  It is equivalent to the
   QUIT command in that context, except that the network connection is
   maintained from one protocol session to the next.  The PMAP command
   takes no arguments:

      command = "PMAP" CRLF

   As with the DONE command, its response is generated in one of
   either protocol session, depending on success or failure.  If the
   PMAP command fails, SMTP remains the principal, and the server
   returns a standard SMTP failure response with either the 421, 500,
   or 502 error code:

      failure-response = ( "421" / "500" / "502" ) [ SP comment ] CRLF



Expires 09-Feb-1999   draft-coulter-pmap-00.txt               [Page 9]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   Each indicates that PMAP services are unavailable.  Specifically,
   the 500 error code indicates that the PMAP command is unrecognized.
   Conversely, the command is recognized in the case of 421 and 502.
   421 indicates that service is temporarily unavailable, while 502
   means that service is unimplemented.

   Should the PMAP command succeed, a PMAP session begins immediately
   and returns a success response:

      success-response = "+" SP digest-context [ SP comment ] CRLF

   Its single parameter, a string of 64 randomly generated visible
   characters, is the digest context for the session, optionally used
   in authentication.  It is unique each session.

6.2  AUTH

   With the exception of DONE, no command may succeed in a PMAP
   session until a user has been authenticated with AUTH command,
   which takes as arguments the username and password of the account
   with which to associate the session:

      command = "AUTH" SP username SP ( password / digest ) CRLF

   As described below, a digest of the password may be transmitted
   instead of the password itself.  The digest is a string of 16
   hexadecimal characters.

   If the username argument matches an existing account name on the
   server and the password argument matches that held by the
   identified account, the user is authenticated for the session, and
   a success response without parameters is returned:

      success-response = "+" [ SP comment ] CRLF

   Alternatively, the server returns a failure response with the AUTH
   error keyword:

      failure-response = "-" SP "AUTH" [ SP comment ] CRLF

   This failure response is also generated if the AUTH command is used
   subsequent to a successful authentication in a session.

   In general, a security risk exists whenever sensitive data, such as
   a password, is transmitted in the clear across a network.  For a
   measure of protection, the AUTH command accepts a digest of the
   password instead of the actual password.  The digest is computed
   using the MD5 algorithm [RFC 1321] from the concatenation of the
   digest context string, returned as the success response parameter
   to the PMAP command, followed by the account password:

      digest := md5( digest-context + password )


Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 10]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   If the digest received from the client matches that computed in the
   same manner by the server, the password is verified and the session
   is authenticated.  Otherwise, the AUTH failure response is
   returned.

   This method of password protection effectively conceals the
   password, given the difficulty in mapping the digest generated by
   the MD5 algorithm to the original data containing the password or
   constructing a second data set that would generate the same digest.
   Furthermore, the digest passed to the AUTH command is valid only in
   the session in which it was computed, because the digest context
   returned in the PMAP command success response used in its
   computation is generated anew each session.  Server implementations
   may offer administrators the option to disallow clear text
   passwords.

   Potential error keywords: SYN, GEN, AUTH

6.3  NEW

   The client issues the NEW command to create a new proxy address:

      command = "NEW" CRLF

   On success, the server assigns the name of the authenticated user
   account to the new proxy's account reference attribute.  It also
   assigns the value false to the suspension attribute, which makes
   the proxy address active, and a blank string to its remark.  The
   success response includes the identifier of the new proxy address
   as its single parameter:

      success-response = "+" SP proxy-id [ SP comment ] CRLF

   The count of owned proxy addresses belonging to the authenticated
   user account is incremented on success.  User accounts track the
   number of proxies they own in addition to the maximum number they
   may own.  If an attempt to create a new proxy would exceed this
   maximum, a failure response with the MAX error keyword is returned:

      failure-response = "-" SP "MAX" [ SP comment ] CRLF

   Potential error keywords: SYN, GEN, AUTH, MAX

6.4  DEL

   The option to remove an address to cut off unwanted mail is the
   rationale behind proxy addresses.  This is accomplished using the
   DEL command, which the client issues with a single argument, the
   identifier of the proxy address to delete:

      command = "DEL" SP proxy-id CRLF



Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 11]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   If the referenced proxy is not owned by the authenticated user, a
   failure response with the ID error keyword is returned:

      failure-response = "-" SP "ID" [ SP comment ] CRLF

   A successful deletion returns a success response without
   parameters:

      success-response = "+" [ SP comment ] CRLF

   The removal of a proxy address decrements the count of owned
   proxies in the authenticated user account.  Any mail sent to the
   deleted proxy address is rejected by the mail handler with a
   standard delivery status notification, describing the proxy as an
   unknown address.  (See Section 4.)

   Potential error keywords: SYN, GEN, ID, AUTH

6.5  SUS

   A suspended proxy address rejects all incoming mail as if the
   address did not exist, mimicking the affects of deleting a proxy
   without actually doing so.  The client can toggle the suspension
   state of a proxy address using the SUS command:

      command = "SUS" SP proxy-id CRLF

   On success, if the proxy was already suspended, it is made active;
   if already active, it is suspended.  A success response is returned
   without parameters:

      success-response = "+" [ SP comment ] CRLF

   If the proxy address whose identifier was passed as an argument is
   not owned by the authenticated user account, the suspension state
   remains unchanged, and a failure response is returned with the ID
   error keyword:

      failure-response = "-" SP "ID" [ SP comment ] CRLF

   A client can determine the current state of the suspension
   attribute using the STAT command.

   Potential error keywords: SYN, GEN, ID, AUTH

6.6  REM

   Each proxy address carries a remark attribute, an arbitrary string
   of characters assigned by the client implementation or user.
   Clients, for example, may store custom data to help manage multiple
   proxy addresses, while users may assign a description of the



Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 12]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   purpose of a proxy.  While the STAT command is used to retrieve the
   remark, the REM command assigns its value:

      command = "REM" SP proxy-id SP remark CRLF

   The remark string consists of at most 64 non-control characters.
   If the remark argument contains at least one space, it is enclosed
   in double quotes.  Double quote and backslash characters are,
   therefore, escaped.  To empty the remark attribute, a blank string
   may be assigned, expressed using two consecutive double quotes.

   A successful assignment returns a success response without
   parameters:

      success-response = "+" [ SP comment ] CRLF

   The REM command fails with the ID error keyword if passed an
   identifier of a proxy address not owned by the authenticated user
   account:

      failure-response = "-" SP "ID" [ SP comment ] CRLF

   As with any other submission by the client, the REM command may
   fail due to a syntax error, to which it is particularly susceptible
   given the constraints on the remark argument.

   The remark attribute remains unchanged on failure.

   Potential error keywords: SYN, GEN, ID, AUTH

6.7  STAT

   The STAT command returns the pertinent attributes of either the
   authenticated user account or a given proxy address.  It is issued
   with or without a proxy identifier as an argument:

      command = "STAT" [ SP proxy-id ] CRLF

   Without the argument, a success response is returned with three
   parameters corresponding to the authenticated user account:

      account-success-response = "+" SP mailbox SP owned-proxies
         SP max-proxies [ SP comment ] CRLF

   The parameters contain the traditional mailbox address [RFC 822],
   to which mail addressed to any proxy address associated with the
   account is directed, the current number of proxy addresses owned by
   the authenticated user account, and the maximum number that may be
   owned under the account.

   Alternatively, the STAT command returns two attributes belonging to
   the proxy address specified by the identifier in the argument:


Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 13]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


      proxy-success-response = "+" SP suspended SP remark
         [ SP comment ] CRLF

   The suspended and remark parameters give the proxy address's
   suspension and remark attributes, respectively.  If the remark
   contains at least one space or is empty, it is enclosed in double
   quotes.

   If STAT is issued with the argument, it may fail with the ID error
   keyword:

      failure-response = "-" SP "ID" [ SP comment ] CRLF

   Potential error keywords: SYN, GEN, ID, AUTH

6.8  LIST

   A client uses the LIST command to retrieve a listing of identifiers
   of the proxy addresses associated with the authenticated user
   account.  It is issued without arguments:

      command = "LIST" CRLF

   The LIST command, like any other, is susceptible to failure by
   syntax, general, or authentication error:

      failure-response = "-" SP ( "SYN" / "GEN" / "AUTH" )
         [ SP comment ] CRLF

   The success response to the LIST command, however, is unlike that
   of the other commands.  Following the usual success response line,
   which consists of the plus symbol and optional comment string, a
   sequence of lines containing one proxy identifier each is returned:

      success-response = "+" [ SP comment ] * ( CRLF proxy-id ) CRLF

   The client should query the server using the STAT command to obtain
   the number of proxy addresses owned by the authenticated user
   account, hence the number of lines to expect, prior to issuing
   LIST.  The server is not obliged to order the listing.

   Potential error keywords: SYN, GEN, AUTH

6.9  DONE

   The client closes a PMAP session using the DONE command, which
   initiates a SMTP session as if a new connection had been
   established.  To close the connection, the client issues the QUIT
   [RFC 821] command after the transition to a SMTP session.  Unlike
   the other PMAP session commands, DONE may be used even if the
   session has not been authenticated with the AUTH command.



Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 14]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


      command = "DONE" CRLF

   As with the PMAP command, the source of the response depends on
   success or failure and the switch between protocols.  On success,
   control reverts to SMTP, which returns a standard success response
   with the 220 greeting code:

      success-response = "220" [ SP comment ] CRLF

   Following this command, the client must begin a new PMAP session
   and re-authenticate in order to use PMAP session commands.

   The DONE command, properly phrased, must not fail.  However, as
   with any other submission, the client must cope with the
   possibility of a syntax error:

      failure-response = "-" SP "SYN" [ SP comment ] CRLF

   Potential error keywords: SYN

7.   Example Sessions

   Failure opening a PMAP session:

      <connection opened>

      S: 220 myu.edu SMTP service ready

      C: PMAP

      S: 500 Command unrecognized
        -or-
      S: 502 Service unimplemented
        -or-
      S: 421 Service temporarily unavailable

      C: QUIT
      S: 221 myu.edu SMTP service closing connection

      <connection closed>

   Success opening a PMAP session, failed authentication:

      <connection opened>

      S: 220 myu.edu SMTP service ready

      C: PMAP
      S: +
      H/29X)^+CM03/XBNJ%912!\CL66"9MS03);AD872}NS@82L::J97\P50(1J9.W9W
      myu.edu PMAP service ready



Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 15]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


      C: AUTH dvader luke
      S: - AUTH Username, password, or digest unrecognized

      C: DONE
      S: 220 myu.edu SMTP service ready

      C: QUIT
      S: 221 myu.edu SMTP service closing connection

      <connection closed>

   Success opening and authenticating a PMAP session, with
   representative uses and misuses of commands:

      <connection opened>

      S: 220 myu.edu SMTP service ready

      C: PMAP
      S: +
      MV903,A>M677.0&~LF$A0#.39F??=JHG+HL?1K*{NM&!2KE[916!!J1MD0%[88EQ
      myu.edu PMAP service ready

      C: PMAP
      S: - SYN Syntax error

      C: DEL M09Z7812
      S: - AUTH Command used out of context

      C: AUTH hsolo leia
      S: + User authenticated in session

      C: AUTH hsolo leia

      S: - AUTH Command used out of context

      C: NEW
      S: + J779A01P New proxy address created

      C: NEW
      S: - MAX Proxy address not created, ownership limit exceeded

      C: DEL J779A01P
      S: + Proxy address deleted

      C: DEL J779A01P
      S: - ID Proxy address identifier unrecognized

      C: SUS KJD09M09
      S: + Proxy address suspension state toggled




Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 16]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


      C: REM KJD09M09 "Imperial newsletter"
      S: + Proxy address remark assigned

      C: STAT KJD09M09
      S: + 1 "Imperial newsletter" Proxy address attributes

      C: STAT 2AA09552
      S: + 0 "" Proxy address attributes

      C: STAT
      S: + han@cin.myu.edu 3 4 User account attributes

      C: LIST
      S: + Owned proxy addresses
      S: KJD09M09
      S: 2AA09552
      S: M09Z7812

      C: DONE
      S: 220 myu.edu SMTP service ready

      C: QUIT
      S: 221 myu.edu SMTP service closing connection

      <connection closed>

8.   Syntax Rules

   The syntax rules, expressed using Augmented Backus-Naur Form
   [RFC 2234], describe the elements of the PMAP command-response
   interface.  The elements are encoded as 7-bit, US-ASCII text
   [US-ASCII].  PMAP specific rules are given in lower case, while
   those from the set of core rules defined in Section 6.1 of
   [RFC 2234] are in upper case.  The following rules are common to
   both the command and response sections.

   alphanum = ALPHA / DIGIT

   proxy-id = 8 alphanum

   remark = 1*64 VCHAR / DQUOTE *64 vqchar DQUOTE

   vqchar = "\" DQUOTE / "\\" / %d32-33 / %d35-91 / %d93-126

8.1  Commands

   command = ( open-session / authenticate / new-proxy /
      delete-proxy / toggle-suspension / set-remark /
      get-account-status / get-proxy-status / list-proxies /
      close-session ) CRLF

   open-session = "PMAP"  ; valid in SMTP session only


Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 17]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   authenticate = "AUTH" SP username SP ( password / digest )

   new-proxy = "NEW"

   delete-proxy = "DEL" SP proxy-id

   toggle-suspension = "SUS" SP proxy-id

   set-remark = "REM" SP proxy-id SP remark

   get-account-status = "STAT"

   get-proxy-status = "STAT" SP proxy-id

   list-proxies = "LIST"

   close-session = "DONE"

   username = 1* VCHAR

   password = 1* VCHAR

   digest = 16 HEXDIG

8.2  Responses

   response = ( success / failure ) CRLF

   success = ( "+" ( open-session-success / authenticate-success /
      new-proxy-success / delete-proxy-success /
      toggle-suspension-success / set-remark-success /
      get-account-status-success / get-proxy-status-success /
      list-proxies-success ) ) / close-session-success

   failure = ( open-session-failure / ( "-"
      SP ( authenticate-failure / new-proxy-failure /
      delete-proxy-failure / toggle-suspension-failure /
      set-remark-failure / get-account-status-failure /
      get-proxy-status-failure / list-proxies-failure /
      close-session-failure ) ) ) [ SP comment ]

   open-session-success = SP digest-context [ SP comment ]

   open-session-failure = "421" / "500" / "502"
      ; generated in SMTP session

   authenticate-success = [ SP comment ]

   authenticate-failure = syntax-error / general-error /
      authentication-error




Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 18]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   new-proxy-success = SP proxy-id [ SP comment ]

   new-proxy-failure = syntax-error / general-error /
      authentication-error / proxy-limit-error

   delete-proxy-success = [ SP comment ]

   delete-proxy-failure = syntax-error / general-error /
      identifier-error / authentication-error

   toggle-suspension-success = [ SP comment ]

   toggle-suspension-failure = syntax-error / general-error /
      identifier-error / authentication-error

   set-remark-success = [ SP comment ]

   set-remark-failure = syntax-error / general-error /
      identifier-error / authentication-error

   get-account-status-success = SP mailbox SP owned-proxies
      SP max-proxies [ SP comment ]

   get-account-status-failure = syntax-error / general-error /
      authentication-error

   get-proxy-status-success = SP suspended SP remark [ SP comment ]

   get-proxy-status-failure = syntax-error / general-error /
      identifier-error / authentication-error

   list-proxies-success = [ SP comment ] * ( CRLF proxy-id )

   list-proxies-failure = syntax-error / general-error /
      authentication-error

   close-session-success = "220" [ SP comment ]
      ; generated in SMTP session

   close-session-failure = syntax-error

   comment = * ncchar

   digest-context = 64 VCHAR

   proxy-id = 8 alphanum

   mailbox = <standard Internet mail address>

   proxies = number

   max-proxies = number


Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 19]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   suspended = BIT

   number = 1* DIGIT

   ncchar = SP / VCHAR

   syntax-error = "SYN"

   general-error = "GEN"

   identifier-error = "ID"

   authentication-error = "AUTH"

   proxy-limit-error = "MAX"

9.   Security Considerations

   Though the authentication process described in Section 6.2 involves
   the transfer of an account password each session, it is arguable
   that PMAP is less susceptible to eavesdropping compared with other
   protocols, such as the Post Office Protocol [RFC 1939], because
   PMAP is not as essential a service.  Connections to POP servers,
   for example, are many and frequent, given their role, while PMAP
   sessions constitute only management chores.  In any case, users and
   administrators must face the risks inherent to transmitting
   passwords as clear text across a network.

   The goal of the password protection scheme defined in Section 6.2
   involving the MD5 algorithm [RFC 1321] is to prevent eavesdroppers
   from capturing the password when the client sends it to the server
   for authentication.  Data is vulnerable in this context
   specifically when in transit, so it makes sense to transmit it or a
   representation of it in a scrambled form, hence sending a digest in
   place of a true password.  The procedure requires that both sender
   and receiver compute the digest in the same way.  In addition, the
   properties of digests generated by the MD5 algorithm practically
   guarantee that the original data, the password, cannot easily be
   derived from the digest nor another data set be found that maps to
   the same digest.  For these reasons, this succeeds in protecting
   the password, since only the two endpoints are expected to know it,
   thus be able to produce matching digests.  Note that digestion is
   preferable to encryption for these reasons, as well as for its
   independence from keys and the need to convey them securely.

   How proxy addresses might be used in the field poses some security
   issues, if personal or economic rather than technological.  Section
   1 outlines the benefits of proxy addresses, notably their
   plurality, transience, and opacity.  As with any tool, its benefits
   may be used to both positive and negative ends.  In the same way a
   user may remove a proxy address to stop intrusive mail, a wrongdoer



Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 20]


INTERNET-DRAFT      Proxy Mail Address Protocol            D. Coulter


   may hide behind a proxy address in the commission of an offense,
   with the freedom to delete it at any time to eliminate that
   recourse.  Similarly, as users may feel secure in the anonymity
   that the code like appearance of proxy addresses provides,
   offenders may take the same advantage.  Fraud, for example, could
   be committed behind a proxy address.

   In all cases, caution should be exercised with the same
   sensibilities in virtual settings as in the real world.  No
   competent vendor, for example, would accept only a postal box
   address or a telephone number in lieu of payment for an item, nor
   would someone make a close acquaintance without substantive
   information.  Likewise, such prudence should be observed by anyone
   in a tangible personal or economic relationship with someone
   offering only a proxy address.  Implementers are encouraged to
   provide server based auditing facilities to help track abuse when
   it occurs.

10.  References

   [RFC 821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
      821, August 1982.

   [RFC 822] Crocker, D., "Standard for the format of ARPA Internet
      text messages", STD 11, RFC 822, August 1982.

   [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
      1321, April 1992.

   [RFC 1869] Klensin, J., et al, "SMTP Service Extensions", STD 10,
      RFC 1869, November 1995.

   [RFC 1939] Myers, J., and Rose, M., "Post Office Protocol, Version
      3", STD 53, RFC 1939, May 1996.

   [RFC 2234] Crocker, M., "Augmented BNF for Syntax Specifications:
      ABNF", RFC 2234, November 1997.

   [US-ASCII] ANSI X3.4:1986, "Coded Character Sets: 7 Bit American
      National Standard Code for Information Interchange (7-bit
      ASCII)".

11.  Contact Information

   Derek Coulter
   E-mail: dcoulter@cgo.wave.ca








Expires 09-Feb-1999   draft-coulter-pmap-00.txt              [Page 21]