idnits 2.17.1 draft-coulter-pmap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC822]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 9, 1998) is 9391 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 821 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1869 (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' Summary: 13 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT D. Coulter 3 Expires: February 9, 1999 August 9, 1998 4 Filename: draft-coulter-pmap-00.txt 6 Proxy Mail Address Protocol 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as "work in 19 progress." 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 26 West Coast). 28 Abstract 30 This specification defines a service that manages a type of 31 disposable Internet mail address known as a proxy address. Proxy 32 addresses conform to the standard addressing scheme [RFC 822] and 33 exist in the same address space, but act as aliases for regular, 34 fixed addresses. Users may own many at a time and allocate and 35 deallocate them at will. 37 Proxy addresses offer a defense against junk mail by allowing 38 individuals to control access to their mailboxes by creating 39 addresses for specific contacts or purposes. If unwanted mail 40 arrives addressed to a proxy, the user may delete or suspend the 41 proxy address to remove the intrusive sender's means of accessing 42 the mailbox. 44 The service also defines a distinct command-response interface for 45 use between client and server implementations to conduct management 46 chores. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Anatomy of a Proxy Address . . . . . . . . . . . . . . . . . 4 52 3. User Accounts . . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Mail Delivery . . . . . . . . . . . . . . . . . . . . . . . 6 54 5. Command-Response Interface . . . . . . . . . . . . . . . . . 7 55 5.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 6. Command Reference . . . . . . . . . . . . . . . . . . . . . 9 58 6.1 PMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 6.2 AUTH . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 6.3 NEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 6.4 DEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 6.5 SUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 63 6.6 REM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 6.7 STAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 6.8 LIST . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 6.9 DONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 7. Example Sessions . . . . . . . . . . . . . . . . . . . . . . 15 68 8. Syntax Rules . . . . . . . . . . . . . . . . . . . . . . . . 17 69 8.1 Commands . . . . . . . . . . . . . . . . . . . . . . . . . 17 70 8.2 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 9. Security Considerations . . . . . . . . . . . . . . . . . . 20 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . 21 73 11. Contact Information . . . . . . . . . . . . . . . . . . . . 21 75 1. Introduction 77 Perhaps the most intrusive form of Internet mail abuse, the 78 unsolicited mail problem is a chronic aggravation that users are 79 generally powerless to stop or prevent. Many forums have played 80 host to endless criticism of the problem, particularly leveled 81 against those who engage in the activity and their tactics, but few 82 solutions have come to the forefront that provide users an adequate 83 defense. While economic and social influences define the human 84 side of the problem, the permissiveness of the Internet mail 85 architecture with regard to the freedoms it grants senders, as well 86 as the fixed relationship between mailbox and address, are the 87 critical factors that provide opportunity to those who would abuse 88 it. 90 Consistent with the Internet's cultural identity of openness and 91 emphasis on personal responsibility, Internet mail grants users the 92 right to send to any addressable mailbox; if an address is known, 93 anyone can address mail to it. Although the act of sending a 94 message is, in essence, an imposition on the recipient, 95 responsibility for the content and quantity of mail sent is the 96 sole dominion of the sender. The benefits of mail service 97 notwithstanding, a mailbox is a privilege not without obligation, 98 as individuals have no say over the receipt of inbound mail. 99 Filtering offers a partial solution, but it cannot compensate for 100 these properties of the underlying architecture. 102 Moreover, once junk mailers or any unwelcome source gets hold of an 103 address, especially if they distribute it, there is no escape from 104 the inevitable, short of abandoning the address. In general, 105 Internet mail service consists of two distinct entities, the 106 mailbox and the address. The mailbox is an open container into 107 which delivered mail is placed, while the purpose of an address is 108 to provide its associated mailbox visibility on the network and 109 represent insert privilege to senders. The powerlessness that 110 users experience when faced with junk mail is rooted in the 111 singular, fixed relationship between regular addresses and their 112 corresponding mailboxes, where mailbox and address are often 113 considered indistinct. This suggests the need for a plurality of 114 addresses associated with each mailbox. 116 Proxy addresses empower individuals against unsolicited mail by 117 emphasizing a many-to-one relationship between address and mailbox, 118 as opposed to the traditional notion of one mailbox, one address. 119 More succinctly, proxy addresses act as disposable front ends, or 120 aliases, for regular, fixed addresses, and are allocated and 121 deallocated directly by user command without administrator 122 involvement. Though address aliasing can be achieved in other 123 ways, such as by forwarding from other addresses (e.g., using the 124 .forward file on Unix systems) or through mail handler rules that 125 map multiple addresses to a single mailbox, they lack the 126 purposefulness and manageability of proxy addresses. 128 The opportunity to have more than one address on a mailbox allows a 129 user to create numerous addresses, one for each contact or purpose. 130 In any situation in which an address is called for, such as on 131 forms or in environments that have a public distribution, the user 132 should offer a proxy address instead of a regular address. For 133 example, proxy addresses are ideal as return addresses on posts to 134 USENET newsgroups, which are scanned for users' mail addresses en 135 masse by those who distribute unsolicited mailings. Should 136 unwanted mail begin to arrive addressed to a proxy, or when it is 137 no longer needed, the user may delete or suspend the address, 138 terminating the intrusion by removing the aforementioned visibility 139 and insert privilege. The prerogative to create an address 140 expressly for a given contact and remove it in the event of abuse 141 lets recipients selectively apportion access rights to their 142 mailboxes on an individual basis. 144 Proxy addresses also frustrate those who distribute addresses. The 145 user controlled lifetime of proxy addresses deters their keeping in 146 address databases, as bulk mailers are unlikely to want their 147 mailing lists waterlogged by hordes of potentially useless 148 addresses. Further, mail from an unexpected source clearly 149 indicates that a party to whom a proxy address was intentionally 150 given has shared the address. Proxy addresses yield another 151 benefit in that, unlike regular addresses, which often consist of 152 parts that concede a user's name, their opacity (see Section 2) 153 provides a wall of anonymity that masks such information. In 154 certain on-line activities, such as chat sessions, uncertainty 155 exists when other participants request a mail address, especially 156 if from a child and the address indicates a name or whereabouts. 158 It should be noted that the cancellation of a proxy address does 159 not pose the inconvenience that canceling a regular address does, 160 since the optimal use of proxy addresses is to have many in 161 circulation, each held by a particular contact or existing for a 162 specific purpose. A regular address is frequently a user's only 163 address, or one of a few, and issued to contacts far and wide. By 164 contrast, when a proxy address is deleted or suspended, it impacts 165 only a specific distribution, the likely provocation for the 166 action, obviating the need to inform numerous contacts of a change. 167 In addition, it often proves difficult to cancel or change a 168 regular address without disturbing the service account with which 169 it is provided, since mail service is usually an adjunct to other 170 services, such as Internet access provision or on-line portal 171 sites. 173 2. Anatomy of a Proxy Address 175 A proxy address is a standard Internet mail address [RFC 822], 176 consisting of a local part, a "@" symbol, and a domain part. The 177 principal of a proxy address is the local part, which is the 178 concatenation of a single ampersand character followed by a string 179 of precisely eight randomly generated alphanumeric characters. The 180 ampersand serves to help implementations discern proxy from non- 181 proxy addresses. The latter, called a proxy identifier, represents 182 a unique value that keys a proxy address within an address space of 183 other proxy addresses managed at an installation. In conjunction 184 with the other elements, the identifier forms a proxy address, as 185 in &38K000PL@myu.edu, &2II9V9JH@research.myu.edu, or 186 &DF989M41@myisp.net, for example. Identifiers are not case 187 sensitive; thus, 0000000A and 0000000a, for example, are identical. 189 Though a proxy address is uniquely described by its identifier 190 within the address space of a single database, implementations are 191 free to allow for any number of address spaces, hence databases, 192 from which proxy addresses are allocated. This document, however, 193 does not stipulate how multiple address spaces at an installation 194 are differentiated in terms of the one from which a newly created 195 proxy address is allocated. The domain name of a user's regular 196 address, however, is an obvious choice. 198 Despite giving proxy addresses a cryptic appearance, identifiers 199 are randomly generated, because far fewer address combinations 200 would occur in practice if they were user selectable. Machine 201 chosen identifiers, on the other hand, give each value out of the 202 entire set of 36^8 (i.e., eight alphanumeric characters), or some 203 2.8 trillion, possibilities equal standing. A large, balanced set 204 of addresses significantly reduces the effectiveness of random or 205 brute force attempts to send unwanted mail into a group of proxy 206 addresses. 208 The all-zero identifier is a special case. A proxy address with 209 this identifier (e.g., &00000000@myu.edu) is called a null proxy 210 and owned by an installation's administrator. The all-zero 211 identifier is never assigned to a proxy address allocated by an 212 ordinary user. 214 In addition to its identifier, a proxy address carries three other 215 attributes: the name of the user account of its owner, its 216 suspension state, and a remark. The user account name string 217 serves to connect the proxy address to its owner's account, which, 218 in turn, holds the regular address to which the proxy is mapped. 219 The suspension attribute is a Boolean value, represented by either 220 the character "0", for false, or active, or "1", for true, or 221 suspended. A proxy address in the suspended state responds to 222 incoming mail as if it were non-existent. The remark, a string of 223 up to 64 characters, is freely set, used for such things as a 224 short, user defined message about the purpose of the proxy address 225 or arbitrary data assigned by the client implementation to help it 226 in the management of multiple proxies. The user has charge over 227 suspension and the remark; the proxy identifier and user account 228 reference are assigned at creation for the lifetime of the proxy 229 address. 231 3. User Accounts 233 Each proxy address is associated with a single user account. 234 Association grants the account holder the right to have mail 235 addressed to a proxy directed to the regular address specified by 236 the account's address attribute, as well as permission to view or 237 change the proxy's attributes. A server implementation maintains a 238 database of user accounts, each of which have, principally, an 239 identifying username, a password, and an address attribute. The 240 username and password are arbitrary strings of visible characters, 241 though implementations may determine case sensitivity or impose 242 string length limits or additional character constraints as they 243 see fit. As stated previously, a proxy address references its 244 associated account by citing this username. The address attribute 245 stores a standard Internet mail address, the regular address 246 coupled with the owner's mailbox. The proxy address is translated 247 into this address by implementations during mail processing. 249 The password prevents the manipulation of proxy addresses belonging 250 to other users. All interactions between client and server take 251 place in authenticated sessions, in which both username and 252 password have been verified. During authentication, a client may 253 transmit either a clear text password or a digest based on the 254 password protection scheme described in Section 6.2. 256 A user account has two other attributes: the number of proxy 257 addresses currently owned and the maximum number that may be owned. 258 An error results if the user attempts to create proxy addresses 259 beyond this limit. It is suggested that a reasonable default 260 maximum for most users be in the range of 10 to 20 proxy addresses. 261 Implementations should allow the administrator to adjust this limit 262 for each user. 264 4. Mail Delivery 266 On its way from source to destination, a message is routed through 267 one or more SMTP [RFC 821] servers. At each stop, a server either 268 advances the message along its source route, if specified, or 269 determines the action to take based on the message's recipient 270 address, either delivering, rejecting, or forwarding the message. 271 In the case of a proxy address, whose role is to front a regular 272 address, which, in turn, corresponds to a mailbox, the server 273 consults its proxy address and user account databases to translate 274 the proxy address into the corresponding regular address, on which 275 the installation's normal mail handling decisions are performed. 276 No part of the message data is modified, although a server may 277 prepend its usual Received header field [RFC 822], the "for" sub- 278 field specifying the translated regular address rather than the 279 proxy address. The regular address becomes the message's operative 280 recipient address for purposes of mail processing at the current 281 and subsequent stops. In some cases, servers may choose an action 282 based upon the proxy address itself, rather than performing the 283 translation, such as to forward all incoming proxy addressed mail 284 to another server. 286 Administrators and users should be aware that a delivery status 287 notification returned to a sender may include a copy of the 288 transmitted message containing Received header fields that cite the 289 regular address translated from the original proxy address. Given 290 that a proxy address should conceal its corresponding regular 291 address from senders, this presents a security risk for proxy 292 address owners. In particular, forwarding is an issue, because 293 messages acquire such marks that include the translated regular 294 address at each forwarding hop. If an error occurs prior to final 295 delivery, the delivery status notification returned to sender would 296 disclose the address. Success notifications returned by recipients 297 on delivery should also be considered. 299 On the client side, implementations provide users the means with 300 which to allocate and deallocate proxy addresses, and view and 301 change their attributes. For received proxy addressed mail, 302 implementers should be mindful that, despite the plurality of proxy 303 addresses with respect to a regular address, mail is retrieved from 304 a single mailbox and presented to users in the usual ways. Users, 305 though, may find user interface options that display or sort 306 received mail by recipient address, hence proxy address, useful. 307 For outgoing mail, implementations should offer the user a choice 308 as to which proxy address to use as the source address on new 309 messages. For replies, clients may volunteer the recipient proxy 310 address of the received message as the reply's source address, 311 provided it is a proxy address that the user owns. Ultimately, in 312 support of the aims discussed in Section 1, the onus is on client 313 applications to promote optimal use of proxy addresses through 314 effective user interface design. 316 5. Command-Response Interface 318 To facilitate the management of proxy addresses, this specification 319 defines a distinct command-response interface for use between 320 connected client and server implementations. As its principal 321 mission is the allocation of mail addresses, support for the 322 service is ideally embedded within SMTP [RFC 821] implementations. 323 PMAP services, therefore, are made available through TCP listening 324 port 25, that assigned SMTP. Clients in this context are typically 325 applications executed on personal workstations that render the 326 protocol's functionality for end users. A server implementation, 327 on the other hand, executes on a machine that has sufficient 328 connectivity and processing resources to provide back end services 329 to multiple users. A PMAP server maintains databases of local user 330 accounts and proxy addresses for mail handlers to check when 331 processing mail and clients to access in the management of proxy 332 addresses. 334 As stated, PMAP support is best provided closely alongside that for 335 SMTP, its command-response interface available as an alternative to 336 that of SMTP. Once a network connection is established, a client 337 chooses to initiate one of either protocol session, issuing the 338 PMAP command instead of the HELO [RFC 821] (or EHLO [RFC 1869]) 339 command to initiate a PMAP session instead of a SMTP session. As 340 the PMAP command is the only extension to the SMTP command space in 341 this document, it is unrecognized in a PMAP session. 343 Sessions provide the context for interaction between client and 344 server implementations. The client initiates an interaction by 345 sending a command to the server, which carries out the requested 346 task and returns a response upon completion. All tasks are 347 stateless in that they complete within the scope of a single 348 interaction. 350 Command and response lines are limited to a maximum of 512 351 characters, including terminator. All PMAP syntactic elements are 352 encoded as 7-bit, US-ASCII text [US-ASCII]. Implementations should 353 observe case independence with respect to all syntactic elements 354 containing alphabetic characters. 356 5.1 Commands 358 A command is transmitted as a line of text, consisting of a command 359 verb, any required arguments, where each is preceded by a space 360 character, and a terminating carriage return/linefeed pair: 362 command-line = verb * ( SP argument ) CRLF 364 PMAP defines eight commands for use in a PMAP session: AUTH, NEW, 365 DEL, SUS, REM, STAT, LIST, and DONE. 367 The AUTH command is used to declare the username and password of 368 the user account with which to bind the session. Except for the 369 DONE command, which ends a PMAP session, it must be issued in a 370 session before any other command can succeed and is illegal once 371 the user is authenticated. 373 NEW and DEL create and delete proxy addresses, respectively, while 374 SUS and REM modify their suspension states and remarks. STAT 375 retrieves the attributes of either a proxy address or the session's 376 authenticated user account, depending on the presence of an 377 argument. LIST returns the identifiers of the proxy addresses 378 owned by the authenticated user. Lastly, the DONE command is used 379 to close a PMAP session and revert to a SMTP session. As stated, 380 the PMAP command is valid only in a SMTP session. 382 5.2 Responses 384 A PMAP session response, like a command, is a line of text 385 terminated by a carriage return/linefeed pair, whose parameters and 386 optional comment are each preceded by a space character: 388 response-line = status-char ( SP error-keyword / 389 * ( SP success-parameter ) ) [ SP comment ] [ CRLF 390 multi-line-list-reply ] CRLF 392 The comment strings are defined by implementers, with some 393 suggestions in Section 7. 395 This response definition is specific only to PMAP session commands. 396 The PMAP command, which is used outside of a PMAP session, is 397 exceptional in that, while its success response conforms to the 398 above, its failure response is a three-digit SMTP result code. The 399 DONE command, also, generates responses in either protocol session, 400 though conversely. 402 The first element of a PMAP response line is the status character, 403 whose value is either a plus symbol ("+"), for success, or a minus 404 symbol ("-"), for failure. A success response may include 405 parameters determined by the foregoing command: 407 success-response-line = "+" * ( SP success-parameter ) 408 [ SP comment ] CRLF 410 The LIST command is unique in that it returns a multi-line 411 response. 413 On failure, a PMAP response line contains one of five error 414 keywords that describes the cause of the failure, following the 415 status character: 417 failure-response-line = "-" SP ( "SYN" / "GEN" / "ID" / "AUTH" / 418 "MAX" ) [ SP comment ] CRLF 420 The SYN error keyword is returned as a result of any syntax or 421 parsing error, such as an unrecognized command or invalid argument. 422 GEN indicates a general error condition, where the implementation 423 is unable to carry out the requested task; for example, an attempt 424 to create a new proxy cannot succeed because of a resource 425 limitation. 427 The ID error keyword is returnable only from commands that take a 428 proxy identifier as an argument. It indicates that the session's 429 authenticated user does not own the identified proxy, either 430 because it belongs to another user or does not exist. The AUTH 431 keyword is returned when the username or password arguments to the 432 AUTH command do not correspond to those of any account on the 433 server. It may also result if any command other than AUTH or DONE 434 is issued in a session before a successful authentication or if the 435 AUTH command is issued when a user has already been authenticated. 437 Unlike the other error keywords, MAX is returned as a potential 438 failure response only by the NEW command. It indicates that an 439 attempt to create a new proxy address exceeds the limit allowed for 440 the user account. 442 6. Command Reference 444 The error keywords of potential failure responses are given at the 445 end of each command subsection. Only the failures specific to each 446 command or its arguments are given explicitly. 448 6.1 PMAP 450 PMAP is the only command defined herein that exists in the SMTP 451 [RFC 821], as opposed to the PMAP, command space. Consequently, 452 the PMAP command is unrecognized in a PMAP session. Valid at any 453 point in a SMTP session where the QUIT [RFC 821] command may be 454 used, the PMAP command signals the server of the client's desire to 455 transition from a SMTP to a PMAP session. It is equivalent to the 456 QUIT command in that context, except that the network connection is 457 maintained from one protocol session to the next. The PMAP command 458 takes no arguments: 460 command = "PMAP" CRLF 462 As with the DONE command, its response is generated in one of 463 either protocol session, depending on success or failure. If the 464 PMAP command fails, SMTP remains the principal, and the server 465 returns a standard SMTP failure response with either the 421, 500, 466 or 502 error code: 468 failure-response = ( "421" / "500" / "502" ) [ SP comment ] CRLF 470 Each indicates that PMAP services are unavailable. Specifically, 471 the 500 error code indicates that the PMAP command is unrecognized. 472 Conversely, the command is recognized in the case of 421 and 502. 473 421 indicates that service is temporarily unavailable, while 502 474 means that service is unimplemented. 476 Should the PMAP command succeed, a PMAP session begins immediately 477 and returns a success response: 479 success-response = "+" SP digest-context [ SP comment ] CRLF 481 Its single parameter, a string of 64 randomly generated visible 482 characters, is the digest context for the session, optionally used 483 in authentication. It is unique each session. 485 6.2 AUTH 487 With the exception of DONE, no command may succeed in a PMAP 488 session until a user has been authenticated with AUTH command, 489 which takes as arguments the username and password of the account 490 with which to associate the session: 492 command = "AUTH" SP username SP ( password / digest ) CRLF 494 As described below, a digest of the password may be transmitted 495 instead of the password itself. The digest is a string of 16 496 hexadecimal characters. 498 If the username argument matches an existing account name on the 499 server and the password argument matches that held by the 500 identified account, the user is authenticated for the session, and 501 a success response without parameters is returned: 503 success-response = "+" [ SP comment ] CRLF 505 Alternatively, the server returns a failure response with the AUTH 506 error keyword: 508 failure-response = "-" SP "AUTH" [ SP comment ] CRLF 510 This failure response is also generated if the AUTH command is used 511 subsequent to a successful authentication in a session. 513 In general, a security risk exists whenever sensitive data, such as 514 a password, is transmitted in the clear across a network. For a 515 measure of protection, the AUTH command accepts a digest of the 516 password instead of the actual password. The digest is computed 517 using the MD5 algorithm [RFC 1321] from the concatenation of the 518 digest context string, returned as the success response parameter 519 to the PMAP command, followed by the account password: 521 digest := md5( digest-context + password ) 523 If the digest received from the client matches that computed in the 524 same manner by the server, the password is verified and the session 525 is authenticated. Otherwise, the AUTH failure response is 526 returned. 528 This method of password protection effectively conceals the 529 password, given the difficulty in mapping the digest generated by 530 the MD5 algorithm to the original data containing the password or 531 constructing a second data set that would generate the same digest. 532 Furthermore, the digest passed to the AUTH command is valid only in 533 the session in which it was computed, because the digest context 534 returned in the PMAP command success response used in its 535 computation is generated anew each session. Server implementations 536 may offer administrators the option to disallow clear text 537 passwords. 539 Potential error keywords: SYN, GEN, AUTH 541 6.3 NEW 543 The client issues the NEW command to create a new proxy address: 545 command = "NEW" CRLF 547 On success, the server assigns the name of the authenticated user 548 account to the new proxy's account reference attribute. It also 549 assigns the value false to the suspension attribute, which makes 550 the proxy address active, and a blank string to its remark. The 551 success response includes the identifier of the new proxy address 552 as its single parameter: 554 success-response = "+" SP proxy-id [ SP comment ] CRLF 556 The count of owned proxy addresses belonging to the authenticated 557 user account is incremented on success. User accounts track the 558 number of proxies they own in addition to the maximum number they 559 may own. If an attempt to create a new proxy would exceed this 560 maximum, a failure response with the MAX error keyword is returned: 562 failure-response = "-" SP "MAX" [ SP comment ] CRLF 564 Potential error keywords: SYN, GEN, AUTH, MAX 566 6.4 DEL 568 The option to remove an address to cut off unwanted mail is the 569 rationale behind proxy addresses. This is accomplished using the 570 DEL command, which the client issues with a single argument, the 571 identifier of the proxy address to delete: 573 command = "DEL" SP proxy-id CRLF 575 If the referenced proxy is not owned by the authenticated user, a 576 failure response with the ID error keyword is returned: 578 failure-response = "-" SP "ID" [ SP comment ] CRLF 580 A successful deletion returns a success response without 581 parameters: 583 success-response = "+" [ SP comment ] CRLF 585 The removal of a proxy address decrements the count of owned 586 proxies in the authenticated user account. Any mail sent to the 587 deleted proxy address is rejected by the mail handler with a 588 standard delivery status notification, describing the proxy as an 589 unknown address. (See Section 4.) 591 Potential error keywords: SYN, GEN, ID, AUTH 593 6.5 SUS 595 A suspended proxy address rejects all incoming mail as if the 596 address did not exist, mimicking the affects of deleting a proxy 597 without actually doing so. The client can toggle the suspension 598 state of a proxy address using the SUS command: 600 command = "SUS" SP proxy-id CRLF 602 On success, if the proxy was already suspended, it is made active; 603 if already active, it is suspended. A success response is returned 604 without parameters: 606 success-response = "+" [ SP comment ] CRLF 608 If the proxy address whose identifier was passed as an argument is 609 not owned by the authenticated user account, the suspension state 610 remains unchanged, and a failure response is returned with the ID 611 error keyword: 613 failure-response = "-" SP "ID" [ SP comment ] CRLF 615 A client can determine the current state of the suspension 616 attribute using the STAT command. 618 Potential error keywords: SYN, GEN, ID, AUTH 620 6.6 REM 622 Each proxy address carries a remark attribute, an arbitrary string 623 of characters assigned by the client implementation or user. 624 Clients, for example, may store custom data to help manage multiple 625 proxy addresses, while users may assign a description of the 626 purpose of a proxy. While the STAT command is used to retrieve the 627 remark, the REM command assigns its value: 629 command = "REM" SP proxy-id SP remark CRLF 631 The remark string consists of at most 64 non-control characters. 632 If the remark argument contains at least one space, it is enclosed 633 in double quotes. Double quote and backslash characters are, 634 therefore, escaped. To empty the remark attribute, a blank string 635 may be assigned, expressed using two consecutive double quotes. 637 A successful assignment returns a success response without 638 parameters: 640 success-response = "+" [ SP comment ] CRLF 642 The REM command fails with the ID error keyword if passed an 643 identifier of a proxy address not owned by the authenticated user 644 account: 646 failure-response = "-" SP "ID" [ SP comment ] CRLF 648 As with any other submission by the client, the REM command may 649 fail due to a syntax error, to which it is particularly susceptible 650 given the constraints on the remark argument. 652 The remark attribute remains unchanged on failure. 654 Potential error keywords: SYN, GEN, ID, AUTH 656 6.7 STAT 658 The STAT command returns the pertinent attributes of either the 659 authenticated user account or a given proxy address. It is issued 660 with or without a proxy identifier as an argument: 662 command = "STAT" [ SP proxy-id ] CRLF 664 Without the argument, a success response is returned with three 665 parameters corresponding to the authenticated user account: 667 account-success-response = "+" SP mailbox SP owned-proxies 668 SP max-proxies [ SP comment ] CRLF 670 The parameters contain the traditional mailbox address [RFC 822], 671 to which mail addressed to any proxy address associated with the 672 account is directed, the current number of proxy addresses owned by 673 the authenticated user account, and the maximum number that may be 674 owned under the account. 676 Alternatively, the STAT command returns two attributes belonging to 677 the proxy address specified by the identifier in the argument: 679 proxy-success-response = "+" SP suspended SP remark 680 [ SP comment ] CRLF 682 The suspended and remark parameters give the proxy address's 683 suspension and remark attributes, respectively. If the remark 684 contains at least one space or is empty, it is enclosed in double 685 quotes. 687 If STAT is issued with the argument, it may fail with the ID error 688 keyword: 690 failure-response = "-" SP "ID" [ SP comment ] CRLF 692 Potential error keywords: SYN, GEN, ID, AUTH 694 6.8 LIST 696 A client uses the LIST command to retrieve a listing of identifiers 697 of the proxy addresses associated with the authenticated user 698 account. It is issued without arguments: 700 command = "LIST" CRLF 702 The LIST command, like any other, is susceptible to failure by 703 syntax, general, or authentication error: 705 failure-response = "-" SP ( "SYN" / "GEN" / "AUTH" ) 706 [ SP comment ] CRLF 708 The success response to the LIST command, however, is unlike that 709 of the other commands. Following the usual success response line, 710 which consists of the plus symbol and optional comment string, a 711 sequence of lines containing one proxy identifier each is returned: 713 success-response = "+" [ SP comment ] * ( CRLF proxy-id ) CRLF 715 The client should query the server using the STAT command to obtain 716 the number of proxy addresses owned by the authenticated user 717 account, hence the number of lines to expect, prior to issuing 718 LIST. The server is not obliged to order the listing. 720 Potential error keywords: SYN, GEN, AUTH 722 6.9 DONE 724 The client closes a PMAP session using the DONE command, which 725 initiates a SMTP session as if a new connection had been 726 established. To close the connection, the client issues the QUIT 727 [RFC 821] command after the transition to a SMTP session. Unlike 728 the other PMAP session commands, DONE may be used even if the 729 session has not been authenticated with the AUTH command. 731 command = "DONE" CRLF 733 As with the PMAP command, the source of the response depends on 734 success or failure and the switch between protocols. On success, 735 control reverts to SMTP, which returns a standard success response 736 with the 220 greeting code: 738 success-response = "220" [ SP comment ] CRLF 740 Following this command, the client must begin a new PMAP session 741 and re-authenticate in order to use PMAP session commands. 743 The DONE command, properly phrased, must not fail. However, as 744 with any other submission, the client must cope with the 745 possibility of a syntax error: 747 failure-response = "-" SP "SYN" [ SP comment ] CRLF 749 Potential error keywords: SYN 751 7. Example Sessions 753 Failure opening a PMAP session: 755 757 S: 220 myu.edu SMTP service ready 759 C: PMAP 761 S: 500 Command unrecognized 762 -or- 763 S: 502 Service unimplemented 764 -or- 765 S: 421 Service temporarily unavailable 767 C: QUIT 768 S: 221 myu.edu SMTP service closing connection 770 772 Success opening a PMAP session, failed authentication: 774 776 S: 220 myu.edu SMTP service ready 778 C: PMAP 779 S: + 780 H/29X)^+CM03/XBNJ%912!\CL66"9MS03);AD872}NS@82L::J97\P50(1J9.W9W 781 myu.edu PMAP service ready 782 C: AUTH dvader luke 783 S: - AUTH Username, password, or digest unrecognized 785 C: DONE 786 S: 220 myu.edu SMTP service ready 788 C: QUIT 789 S: 221 myu.edu SMTP service closing connection 791 793 Success opening and authenticating a PMAP session, with 794 representative uses and misuses of commands: 796 798 S: 220 myu.edu SMTP service ready 800 C: PMAP 801 S: + 802 MV903,A>M677.0&~LF$A0#.39F??=JHG+HL?1K*{NM&!2KE[916!!J1MD0%[88EQ 803 myu.edu PMAP service ready 805 C: PMAP 806 S: - SYN Syntax error 808 C: DEL M09Z7812 809 S: - AUTH Command used out of context 811 C: AUTH hsolo leia 812 S: + User authenticated in session 814 C: AUTH hsolo leia 816 S: - AUTH Command used out of context 818 C: NEW 819 S: + J779A01P New proxy address created 821 C: NEW 822 S: - MAX Proxy address not created, ownership limit exceeded 824 C: DEL J779A01P 825 S: + Proxy address deleted 827 C: DEL J779A01P 828 S: - ID Proxy address identifier unrecognized 830 C: SUS KJD09M09 831 S: + Proxy address suspension state toggled 832 C: REM KJD09M09 "Imperial newsletter" 833 S: + Proxy address remark assigned 835 C: STAT KJD09M09 836 S: + 1 "Imperial newsletter" Proxy address attributes 838 C: STAT 2AA09552 839 S: + 0 "" Proxy address attributes 841 C: STAT 842 S: + han@cin.myu.edu 3 4 User account attributes 844 C: LIST 845 S: + Owned proxy addresses 846 S: KJD09M09 847 S: 2AA09552 848 S: M09Z7812 850 C: DONE 851 S: 220 myu.edu SMTP service ready 853 C: QUIT 854 S: 221 myu.edu SMTP service closing connection 856 858 8. Syntax Rules 860 The syntax rules, expressed using Augmented Backus-Naur Form 861 [RFC 2234], describe the elements of the PMAP command-response 862 interface. The elements are encoded as 7-bit, US-ASCII text 863 [US-ASCII]. PMAP specific rules are given in lower case, while 864 those from the set of core rules defined in Section 6.1 of 865 [RFC 2234] are in upper case. The following rules are common to 866 both the command and response sections. 868 alphanum = ALPHA / DIGIT 870 proxy-id = 8 alphanum 872 remark = 1*64 VCHAR / DQUOTE *64 vqchar DQUOTE 874 vqchar = "\" DQUOTE / "\\" / %d32-33 / %d35-91 / %d93-126 876 8.1 Commands 878 command = ( open-session / authenticate / new-proxy / 879 delete-proxy / toggle-suspension / set-remark / 880 get-account-status / get-proxy-status / list-proxies / 881 close-session ) CRLF 883 open-session = "PMAP" ; valid in SMTP session only 884 authenticate = "AUTH" SP username SP ( password / digest ) 886 new-proxy = "NEW" 888 delete-proxy = "DEL" SP proxy-id 890 toggle-suspension = "SUS" SP proxy-id 892 set-remark = "REM" SP proxy-id SP remark 894 get-account-status = "STAT" 896 get-proxy-status = "STAT" SP proxy-id 898 list-proxies = "LIST" 900 close-session = "DONE" 902 username = 1* VCHAR 904 password = 1* VCHAR 906 digest = 16 HEXDIG 908 8.2 Responses 910 response = ( success / failure ) CRLF 912 success = ( "+" ( open-session-success / authenticate-success / 913 new-proxy-success / delete-proxy-success / 914 toggle-suspension-success / set-remark-success / 915 get-account-status-success / get-proxy-status-success / 916 list-proxies-success ) ) / close-session-success 918 failure = ( open-session-failure / ( "-" 919 SP ( authenticate-failure / new-proxy-failure / 920 delete-proxy-failure / toggle-suspension-failure / 921 set-remark-failure / get-account-status-failure / 922 get-proxy-status-failure / list-proxies-failure / 923 close-session-failure ) ) ) [ SP comment ] 925 open-session-success = SP digest-context [ SP comment ] 927 open-session-failure = "421" / "500" / "502" 928 ; generated in SMTP session 930 authenticate-success = [ SP comment ] 932 authenticate-failure = syntax-error / general-error / 933 authentication-error 935 new-proxy-success = SP proxy-id [ SP comment ] 937 new-proxy-failure = syntax-error / general-error / 938 authentication-error / proxy-limit-error 940 delete-proxy-success = [ SP comment ] 942 delete-proxy-failure = syntax-error / general-error / 943 identifier-error / authentication-error 945 toggle-suspension-success = [ SP comment ] 947 toggle-suspension-failure = syntax-error / general-error / 948 identifier-error / authentication-error 950 set-remark-success = [ SP comment ] 952 set-remark-failure = syntax-error / general-error / 953 identifier-error / authentication-error 955 get-account-status-success = SP mailbox SP owned-proxies 956 SP max-proxies [ SP comment ] 958 get-account-status-failure = syntax-error / general-error / 959 authentication-error 961 get-proxy-status-success = SP suspended SP remark [ SP comment ] 963 get-proxy-status-failure = syntax-error / general-error / 964 identifier-error / authentication-error 966 list-proxies-success = [ SP comment ] * ( CRLF proxy-id ) 968 list-proxies-failure = syntax-error / general-error / 969 authentication-error 971 close-session-success = "220" [ SP comment ] 972 ; generated in SMTP session 974 close-session-failure = syntax-error 976 comment = * ncchar 978 digest-context = 64 VCHAR 980 proxy-id = 8 alphanum 982 mailbox = 984 proxies = number 986 max-proxies = number 987 suspended = BIT 989 number = 1* DIGIT 991 ncchar = SP / VCHAR 993 syntax-error = "SYN" 995 general-error = "GEN" 997 identifier-error = "ID" 999 authentication-error = "AUTH" 1001 proxy-limit-error = "MAX" 1003 9. Security Considerations 1005 Though the authentication process described in Section 6.2 involves 1006 the transfer of an account password each session, it is arguable 1007 that PMAP is less susceptible to eavesdropping compared with other 1008 protocols, such as the Post Office Protocol [RFC 1939], because 1009 PMAP is not as essential a service. Connections to POP servers, 1010 for example, are many and frequent, given their role, while PMAP 1011 sessions constitute only management chores. In any case, users and 1012 administrators must face the risks inherent to transmitting 1013 passwords as clear text across a network. 1015 The goal of the password protection scheme defined in Section 6.2 1016 involving the MD5 algorithm [RFC 1321] is to prevent eavesdroppers 1017 from capturing the password when the client sends it to the server 1018 for authentication. Data is vulnerable in this context 1019 specifically when in transit, so it makes sense to transmit it or a 1020 representation of it in a scrambled form, hence sending a digest in 1021 place of a true password. The procedure requires that both sender 1022 and receiver compute the digest in the same way. In addition, the 1023 properties of digests generated by the MD5 algorithm practically 1024 guarantee that the original data, the password, cannot easily be 1025 derived from the digest nor another data set be found that maps to 1026 the same digest. For these reasons, this succeeds in protecting 1027 the password, since only the two endpoints are expected to know it, 1028 thus be able to produce matching digests. Note that digestion is 1029 preferable to encryption for these reasons, as well as for its 1030 independence from keys and the need to convey them securely. 1032 How proxy addresses might be used in the field poses some security 1033 issues, if personal or economic rather than technological. Section 1034 1 outlines the benefits of proxy addresses, notably their 1035 plurality, transience, and opacity. As with any tool, its benefits 1036 may be used to both positive and negative ends. In the same way a 1037 user may remove a proxy address to stop intrusive mail, a wrongdoer 1038 may hide behind a proxy address in the commission of an offense, 1039 with the freedom to delete it at any time to eliminate that 1040 recourse. Similarly, as users may feel secure in the anonymity 1041 that the code like appearance of proxy addresses provides, 1042 offenders may take the same advantage. Fraud, for example, could 1043 be committed behind a proxy address. 1045 In all cases, caution should be exercised with the same 1046 sensibilities in virtual settings as in the real world. No 1047 competent vendor, for example, would accept only a postal box 1048 address or a telephone number in lieu of payment for an item, nor 1049 would someone make a close acquaintance without substantive 1050 information. Likewise, such prudence should be observed by anyone 1051 in a tangible personal or economic relationship with someone 1052 offering only a proxy address. Implementers are encouraged to 1053 provide server based auditing facilities to help track abuse when 1054 it occurs. 1056 10. References 1058 [RFC 821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 1059 821, August 1982. 1061 [RFC 822] Crocker, D., "Standard for the format of ARPA Internet 1062 text messages", STD 11, RFC 822, August 1982. 1064 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1065 1321, April 1992. 1067 [RFC 1869] Klensin, J., et al, "SMTP Service Extensions", STD 10, 1068 RFC 1869, November 1995. 1070 [RFC 1939] Myers, J., and Rose, M., "Post Office Protocol, Version 1071 3", STD 53, RFC 1939, May 1996. 1073 [RFC 2234] Crocker, M., "Augmented BNF for Syntax Specifications: 1074 ABNF", RFC 2234, November 1997. 1076 [US-ASCII] ANSI X3.4:1986, "Coded Character Sets: 7 Bit American 1077 National Standard Code for Information Interchange (7-bit 1078 ASCII)". 1080 11. Contact Information 1082 Derek Coulter 1083 E-mail: dcoulter@cgo.wave.ca