idnits 2.17.1 draft-ietf-acap-pers-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 Abstract section. ** The document seems to lack an Introduction section. ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (February 2003) is 7740 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) == Missing Reference: 'BASIC-URL' is mentioned on line 525, but not defined == Missing Reference: 'SASL' is mentioned on line 510, but not defined == Unused Reference: 'URL-SMTP' is defined on line 583, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. 'ACAP-ACCOUNT' -- Possible downref: Non-RFC (?) normative reference: ref. 'ACAP-OPTIONS' ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2554 (ref. 'SMTP-AUTH') (Obsoleted by RFC 4954) ** Obsolete normative reference: RFC 1738 (ref. 'URL-BASIC') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2192 (ref. 'URL-IMAP') (Obsoleted by RFC 5092) -- Possible downref: Non-RFC (?) normative reference: ref. 'URL-SMTP' ** Obsolete normative reference: RFC 2279 (ref. 'UTF8') (Obsoleted by RFC 3629) -- Obsolete informational reference (is this intentional?): RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) Summary: 13 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Gellens 3 Document: draft-ietf-acap-pers-06.txt QUALCOMM 4 Expires: August 2003 February 2003 6 ACAP Email Personality Dataset Class 8 Status of this Memo: 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet- Drafts as 21 reference material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 . 29 Copyright Notice 31 Copyright (C) The Internet Society 2003. All Rights Reserved. 32 Abstract 34 It has become common for Internet mail users to receive and compose 35 mail in the capacity of different roles or identities (for example, 36 personal and work), to receive and compose mail at different 37 machines, and to use multiple programs which require mail 38 composition configuration information. These different roles or 39 identities have become known as email personalities. 41 The Application Configuration Access Protocol [ACAP] provides an 42 ideal mechanism for storage of email personality data. 44 This specification defines a standard ACAP dataset class for email 45 personalities, and a common option for indicating a default. 47 An SMTP URL scheme is also defined. 49 Table of Contents 51 1. Conventions Used in this Document . . . . . . . . . . . . . . 3 52 2. Changes Since Previous Version . . . . . . . . . . . . . . . 3 53 3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 4. ACAP Standard Options . . . . . . . . . . . . . . . . . . . 4 55 5. ACAP Email Personality Dataset Class . . . . . . . . . . . . 4 56 5.1. ACAP Email Personality Dataset Class Prefix . . . . . . 4 57 5.2. ACAP Email Personality Dataset Hierarchy . . . . . . . . 4 58 6. ACAP Email Personality Dataset Attributes . . . . . . . . . 4 59 6.1. Basic Attributes . . . . . . . . . . . . . . . . . . . . 5 60 6.2. Specific Attributes . . . . . . . . . . . . . . . . . . 5 61 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8. The SMTP URL Scheme . . . . . . . . . . . . . . . . . . . . 10 63 8.1. SMTP User Name and Authentication Mechanism . . . . . . . 10 64 8.2. Relative SMTP URLs . . . . . . . . . . . . . . . . . . . 12 65 8.3. Multinational Considerations . . . . . . . . . . . . . . 12 66 8.4. Example . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.5. ABNF for SMTP URL scheme . . . . . . . . . . . . . . . . 12 68 8.6. Security Considerations . . . . . . . . . . . . . . . . 13 69 9. Normative References . . . . . . . . . . . . . . . . . . . . 13 70 10. Informative References . . . . . . . . . . . . . . . . . . 15 71 11. Security Considerations . . . . . . . . . . . . . . . . . . 15 72 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 15 73 13. Author's Address . . . . . . . . . . . . . . . . . . . . . 16 74 Intellectual Property Statement . . . . . . . . . . . . . . . 16 75 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16 77 1. Conventions Used in this Document 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 83 2. Changes Since Previous Version 85 - Cleaned up examples. 86 - Minor text clarifications. 87 - Added specification of SMTP URL. 89 3. Comments 90 Public comments can be sent to the IETF ACAP mailing list, 91 . To subscribe, send a message to 92 with the word SUBSCRIBE as the 93 body. Private comments should be sent to the author. 95 4. ACAP Standard Options 97 This specification defines the MUA Default Personality standard 98 option. This is a scaler option in the ACAP Standard Option 99 ("/option") dataset. The entry name is "mua.default.personality". 100 The "option.value" attribute contains the value, which is a URL. 101 Generally, this will be an ACAP URL pointing to an entry in an Email 102 Personality dataset. 104 The standard option dataset class is specified in [ACAP-OPTIONS]. 105 ACAP URLs are defined in [ACAP]. 107 5. ACAP Email Personality Dataset Class 109 The ACAP Email Personality dataset class defines a set of attributes 110 which specify an email personality; that is, configuration 111 information used for composing and sending email. 113 Configuration information related to accessing and retrieving 114 received email is stored in the ACAP Email Account Dataset Class 115 [ACAP-ACCOUNT]. 117 5.1. ACAP Email Personality Dataset Class Prefix 119 Datasets whose names begin with "/personality" are assumed to 120 contain email personality entries as defined in this specification. 122 5.2. ACAP Email Personality Dataset Hierarchy 124 Each user may have a set of named email personalities. The default 125 is pointed at by the "mua.default.personality" standard option. 126 (See section 4 for more information.) 128 Inheritance is likely to be useful both for inheriting site or group 129 defaults (for example, [SMTP] servers, and initial client 130 configuration in general) as well as for inheriting user-specific 131 configuration when using different machines. 133 6. ACAP Email Personality Dataset Attributes 135 An email personality entry MUST have an "entry" attribute. All 136 other attributes are OPTIONAL. 138 Attributes are specified using Augmented Backus-Naur Form [ABNF]. 139 All attributes are single-valued and textual unless otherwise 140 stated. 142 The ABNF defines the content of the attribute values prior to their 143 encoding as an ACAP string. Clients MUST conform to the syntax when 144 generating these attributes, but MUST NOT assume that the attribute 145 values will conform to this syntax on access. Servers MUST NOT 146 enforce the syntax. 148 6.1. Basic Attributes 150 These attributes are defined in ACAP [ACAP] and have meaning in all 151 dataset classes. This section describes how they are used in an 152 email personality dataset. 154 entry 155 The "entry" attribute is used to hold a unique name for the 156 personality. This name is used for inheritance, so when 157 customizing a personality which has an entry in an inherited 158 dataset, the entry name needs to remain the same. The name 159 should also be descriptive. 161 subdataset 162 The "subdataset" attribute indicates that there is a subdataset 163 of this entry. The value of this attribute specifies the actual 164 location of the subdataset, per [ACAP] section 3.1.1. 166 6.2. Specific Attributes 168 These attributes are specific to the Email Personality dataset 169 class. 171 personality.Auto.Encrypt 172 This flag indicates if the client should automatically encrypt 173 messages composed with this personality. 175 pers-auto-enc = "0" / "1" 177 personality.Auto.Sign 178 This flag indicates if the client should automatically apply a 179 digital signature to messages composed with this personality. 181 pers-auto-sign = "0" / "1" 183 personality.Cert-DN 184 This contains the certificate name to be used when encrypting 185 and/or signing messages using certificate-based mechanisms. 187 pers-cert-dn = 1*UTF8-CHAR 189 personality.Charset 190 This specifies the default coded character set to be used when 191 composing messages. The name must be in the IANA charset 192 registry (located at 193 ). 195 pers-charset = 1*CHAR 197 personality.File-Into.IMAP 198 This specifies an IMAP folder into which new messages should be 199 copied by default. Generally, this is specified as an IMAP URL, 200 as defined in [URL-IMAP]. 202 pers-file-imap = url ;defined in [URL-BASIC] 204 personality.File-Into.Local 205 This specifies the name of a local folder into which new 206 messages should be placed by default. 208 pers-file-local = 1*UTF8-CHAR 210 personality.Header.BCC 211 This specifies the default BCC header field contents. 213 pers-hdr-bcc = *address 214 ;address specified in [RFC-822] 216 personality.Header.CC 217 This specifies the default CC header field contents. 219 pers-hdr-cc = 1*address 220 ;address specified in [RFC-822] 222 personality.Header.Extra 223 This multivalued attribute contains additional header fields. 224 Each value contains the complete canonical form of a header name 225 and contents. Values must conform to [RFC-822] and [MIME]. 227 pers-hdr-extra = 1*CHAR 228 ;must conform to [RFC-822] and [MIME] 230 personality.Header.Reply-To 231 This specifies the default Reply-To header field contents. 232 Values must conform to [RFC-822] and [MIME]. 234 pers-hdr-reply = 1*CHAR 235 ;must conform to [RFC-822] and [MIME] 237 personality.Language 238 This contains the default language to be specified in language 239 tags. The name must be in the IANA language registry (located 240 at ). 242 pers-lang = 1*CHAR 244 personality.MIME.Composition-Type 245 This specifies the default MIME type to use when composing 246 messages which contain any text elements or parts. The value is 247 a MIME type and subtype, with optional parameters. The value 248 should be canonicalized by removing unnecessary quoting. The 249 type, subtype, and any parameters must conform to [MIME], 250 including IANA registration requirements. Free insertion of 251 linear-white-space is not permitted. 253 pers-mtype = type "/" subtype *(";" SP parameter) 254 ;defined in RFC 2045 [MIME] 256 personality.PGP.Key-ID.bin 257 This contains the Key ID when PGP is used to encrypt and/or sign 258 messages. 260 pers-pgp-key = *OCTET 262 personality.Real-Name 263 This contains the display name associated with the personality. 264 The phrase component of the From header field should be 265 constructed from this value. 267 pers-name = 1*UTF8-CHAR 269 personality.Return-Address 270 This contains the [RFC-822] addr-spec associated with the 271 personality. The addr-spec of the From header field should by 272 default contain this value. It is separated from the phrase 273 From field component (stored in "personality.Real-Name") to make 274 comparisons easier. 276 pers-addr = addr-spec 277 ;addr-spec defined in [RFC-822] 279 personality.Server.SMTP 280 This specifies the [SMTP] server to be used when sending 281 messages for this personality. Generally, the form is an [SMTP] 282 URL, as defined in Section 8. 284 pers-smtp = url ;defined in [URL-BASIC] 286 personality.Signature.Text 287 This contains the signature text to be appended by default to 288 new messages. It is stored in canonical form, with 289 CRLF-separated lines. When a signature separator line is used, 290 it SHOULD NOT be contained in this attribute, but instead added 291 automatically by the client. 293 pers-sig-text = 1*CHAR 295 personality.Signature.URL 296 When the signature to be appended by default to new messages is 297 stored in a file or other resource, this attribute is used 298 instead of "personality.Signature.Text". This attribute 299 contains a URL (for example, a file URL) to the signature text. 300 It is assumed that the signature text is in canonical form, with 301 CRLF-separated lines. When a signature separator line is used, 302 it SHOULD NOT be contained in this file, but instead added 303 automatically by the client. 305 pers-sig-url = url ;defined in [URL-BASIC] 307 personality.Stationery 308 This attribute contains a URL (for example, a file URL) to the 309 stationery, or template, to be used when creating new messages 310 with this personality. In general the stationery contains a 311 canonicalized message, with header fields and/or body. 313 pers-statn = url ;defined in [URL-BASIC] 315 personality.SMTP-Auth.permitted.clear 316 This attribute specifies if clear-text [SMTP-AUTH] mechanisms 317 are permitted. A value of "never" indicates such mechanisms can 318 never be used for this personality. A value of "encrypted" 319 gives permission to use such mechanisms if an encrypted channel 320 is in effect, such as [TLS] or [IPSEC]. A value of "always" 321 permits such mechanisms to be used under all conditions. 323 Note that use of clear-text mechanisms poses at least two 324 different risks: one is that the password may be captured 325 in-transit (which can be mitigated by using an encryption 326 layer); the second is that the password may be disclosed to an 327 inappropriate server. 329 pers-auth-clear = "never" / "encrypted" / "always" 331 personality.SMTP-Auth.permitted.nonclear 332 This attribute specifies if non-clear-text [SMTP-AUTH] 333 mechanisms (such as CRAM-MD5, Kerberos, or One Time Password) 334 are permitted. A value of "never" indicates such mechanisms can 335 never be used for this personality. A value of "always" permits 336 such mechanisms to be used under all conditions. 338 Note that some non-clear-text mechanisms are vulnerable to 339 various attacks which could result in an unauthorized server 340 obtaining the user's password. 342 pers-auth-nonclear = "never" / "always" 344 7. Examples 346 entry personal 347 personality.File-Into.Local sent mail 348 personality.Header.Extra X-Pet: Yak 349 personality.MIME.Composition-Type text/plain; format=flowed 350 personality.Real-Name L. Eva Message 351 personality.Return-Address lem@pop.example.net 352 personality.Server.SMTP smtp:smtp.example.net 353 personality.Signature.Text L. Eva Message 354 "sua cuique voluptas" 355 personality.SMTP-Auth.permitted.clear Never 357 entry work 358 personality.File-Into.IMAP IMAP://lem@example.org/sent 359 personality.Header.Extra Organization: A.T.&Love 360 personality.MIME.Composition-Type multipart/alternative 361 personality.Real-Name L. Eva Message 362 personality.Return-Address lem@mail.example.org 363 personality.Server.SMTP smtp:smtp.example.org 364 personality.Signature.URL file://signature.txt 365 personality.SMTP-Auth.permitted.clear Never 366 personality.SMTP-Auth.permitted.nonclear 367 Always 369 8. The SMTP URL Scheme 371 The SMTP URL scheme designates an [SMTP] server, and optionally a 372 port number, authentication mechanism, authentication ID, and/or 373 authorization ID. 375 The SMTP URL follows the common Internet scheme syntax as defined in 376 RFC 1738 [BASIC-URL] except that clear text passwords are not 377 permitted. If : is omitted, the port defaults to 25. 379 The SMTP URL is described using [ABNF] in section 8.5. 381 An SMTP URL is of the general form: 383 smtp:;auth=@: 385 Where , , and are as defined in RFC 1738, and 386 some or all of the elements, except "smtp:" and , may be 387 omitted. 389 8.1. SMTP User Name and Authentication Mechanism 391 An authorization (which [SMTP] account to access) and authentication 392 (whose password to check against) identity (referred to as "user 393 name" for simplicity) and/or authentication mechanism name may be 394 supplied. These are used in an AUTH [SMTP-AUTH], or extension 395 command after making the connection to the SMTP server. If the URL 396 doesn't supply an authentication identifier, the program 397 interpreting the SMTP URL MAY request one from the user. 399 An authentication mechanism can be expressed by adding ";AUTH=" to the end of the user name. If the authentication 401 mechanism name is not preceded by a "+", it is a SASL SMTP [SASL] 402 mechanism. If it is preceded by a "+", it is an extension 403 mechanism. 405 When an is specified, the client SHOULD request 406 appropriate credentials from that mechanism and use the "AUTH", (or 407 extension) command. If no user name is specified and an 408 is specified, a user name SHOULD be obtained from 409 the mechanism or requested from the user as appropriate. 411 The string ";AUTH=*" indicates that the client SHOULD select an 412 appropriate authentication mechanism. It MAY use any mechanism 413 supported by the [SMTP] server. 415 If an other than ";AUTH=*" is specified, the client 416 SHOULD NOT use a different mechanism without explicit user 417 permission. 419 If a user name is included with no authentication mechanism, then 420 ";AUTH=*" is assumed. 422 Since URLs can easily come from untrusted sources, care must be 423 taken when resolving a URL which requires or requests any sort of 424 authentication. If authentication credentials are supplied to the 425 wrong server, it may compromise the security of the user's account. 426 The program resolving the URL should make sure it meets at least one 427 of the following criteria in this case: 429 (1) The URL comes from a trusted source, such as a referral server 430 which the client has validated and trusts according to site policy. 431 Note that user entry of the URL may or may not count as a trusted 432 source, depending on the experience level of the user and site 433 policy. 435 (2) Explicit local site policy permits the client to connect to the 436 server in the URL. For example, if the client knows the site domain 437 name, site policy may dictate that any hostname ending in that 438 domain is trusted. 440 (3) The user confirms that connecting to that domain name with the 441 specified credentials and/or mechanism is permitted. 443 (4) A mechanism is used which validates the server before passing 444 potentially compromising client credentials. 446 (5) An authentication mechanism is used which will not reveal 447 information to the server which could be used to compromise future 448 connections. 450 A URL containing ";AUTH=*" should be treated with extra care since 451 it might fall back on a weaker security mechanism. Finally, clients 452 are discouraged from using a plain text password as a fallback with 453 ";AUTH=*" unless the connection has strong encryption (e.g., a key 454 length of greater than 56 bits). 456 Note that if unsafe or reserved characters such as " " or ";" are 457 present in the user name or authentication mechanism, they MUST be 458 encoded as described in RFC 1738 [BASIC-URL]. 460 8.2. Relative SMTP URLs 462 Relative SMTP URLs are not permitted. 464 8.3. Multinational Considerations 466 Since 8-bit characters are not permitted in URLs, [UTF8] characters 467 are encoded as required by the URL specification [BASIC-URL]. 469 8.4. Example 471 The following example demonstrate how an SMTP client program might 472 translate various SMTP URLs into a series of SMTP commands. 473 Commands sent from the client to the server are prefixed with "C:", 474 and responses sent from the server to the client are prefixed with 475 "S:". 477 The URL: 479 481 Results in the following client commands: 483 484 485 S: 220 smtp.example.com ESMTP server ready 486 C: EHLO jgm.example.com 487 S: 250-smtp.example.com 488 S: 250 AUTH CRAM-MD5 DIGEST-MD5 489 C: AUTH CRAM-MD5 490 S: 334 491 PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4= 492 C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ== 493 S: 235 Authentication successful. 495 8.5. ABNF for SMTP URL scheme 497 The SMTP URL scheme is described using [ABNF]: 499 achar = uchar / "&" / "=" / "~" 500 ; see [BASIC-URL] for "uchar" definition 502 auth = ";AUTH=" ( "*" / enc-auth-type ) 504 enc-auth-type = enc-sasl / enc-ext 506 enc-ext = "+" 1*achar 507 ;encoded extension mechanism name 509 enc-sasl = 1*achar 510 ;encoded version of [SASL] "auth_type" 512 enc-user = 1*achar 513 ;encoded version of SMTP mailbox 515 smtp-url = "smtp:" server 517 server = [user-auth "@"] hostport 518 ;See [BASIC-URL] for "hostport" definition 520 user-auth = enc-user [auth] 522 8.6. Security Considerations 524 Security considerations discussed in the [SMTP-AUTH] 525 specification and the [BASIC-URL] specification are relevant. 526 Security considerations related to authenticated URLs are discussed 527 in section 8.1 of this document. 529 Many email clients store the plain text password for later use 530 after logging into a server. Such clients MUST NOT use a stored 531 password in response to an SMTP URL without explicit permission from 532 the user to supply that password to the specified host name. 534 9. Normative References 536 [ABNF] Crocker, Overell, "Augmented BNF for Syntax 537 Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon 538 Internet Ltd., November 1997. 539 541 [ACAP] Newman, Myers, "ACAP -- Application Configuration Access 542 Protocol", RFC 2244, Innosoft, Netscape, November 1997. 543 545 [ACAP-ACCOUNT] Gellens, "ACAP Email Account Dataset Class", work 546 in Progress. 547 549 [ACAP-OPTIONS] Hole, "ACAP Application Options Dataset Class", 550 workin Progress. 551 553 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 554 Requirement Levels", RFC 2119, Harvard University, March 1997. 555 557 [RFC-822] Crocker, "Standard for the Format of ARPA Internet 558 Text Messages", RFC 822, STD 11, University of Delaware, August 559 1982. 561 [MIME] Freed, Borenstein, "Multipurpose Internet Mail Extensions 562 (MIME) Part One: Format of Internet Message Bodies", RFC 2045, 563 Innosoft, First Virtual, November 1996; Freed, Borenstein, 564 "Multipurpose Internet Mail Extensions (MIME) Part Two: Media 565 Types", RFC 2046, Innosoft, First Virtual, November 1996; Moore, 566 "MIME (Multipurpose Internet Mail Extensions) Part Three: Message 567 Header Extensions for Non-ASCII Text", RFC 2047, University of 568 Tennessee, November 1996. 569 570 572 [SMTP-AUTH] J. Myers, "SMTP Service Extension for 573 Authentication", RFC 2554, Netscape Communications, March 1999. 574 576 [URL-BASIC] Berners-Lee, Masinter, McCahill, "Uniform Resource 577 Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of 578 Minnesota, December 1994. 580 [URL-IMAP] Newman, "IMAP URL Scheme", RFC 2192, Innosoft, 581 September 1997. 583 [URL-SMTP] Earhart, "An SMTP URL Interface", work in progress. 584 586 [UTF8] Yergeau, F. "UTF-8, a transformation format of ISO 587 10646", RFC 2279, Alis Technologies, January 1998. 588 590 10. Informative References 592 [IPSEC] R. Atkinson, "Security Architecture for the Internet 593 Protocol", RFC 1825, August 1995, 594 596 [SMTP] J. Klensin, "Simple Mail Transfer Protocol", RFC 2821, 597 April 2001, 599 [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", RFC 2246, 600 Certicom, January 1999. 602 11. Security Considerations 604 As with ACAP datasets in general, it is important that access 605 controls are set correctly on Email Personality datasets. 606 Attributes may contain highly personal information which should not 607 be disclosed except by explicit owner request. In addition, by 608 changing certain attributes (such as 609 "personality.SMTP-Auth.permitted.clear", 610 "personality.SMTP-Auth.permitted.nonclear", and 611 "personality.server.SMTP"), an attacker could cause a user to 612 attempt an unsafe and unwise authentication, including potentially 613 sending the user's password in the clear to a rogue server. 615 The "personality.SMTP-Auth.permitted.clear" attribute mentions 616 twoof the risks associated with sending clear-text passwords to an 617 SMTP server. 619 The "personality.SMTP-Auth.permitted.nonclear" attribute 620 mentions one of the risks associated with using non-clear-text 621 authentication mechanisms. 623 Security considerations for SMTP URLs are discussed in section 624 8.6. 626 12. Acknowledgments 627 Many thanks to the participants of the IETF ACAP working group 628 fortheir help, comments, and suggestions. 630 13. Author's Address 632 Randall Gellens +1 858 651 5115 633 QUALCOMM Incorporated randy@qualcomm.com 634 5775 Morehouse Drive 635 San Diego, CA 92121-2779 636 U.S.A. 638 Intellectual Property Statement 640 The IETF takes no position regarding the validity or scope of 641 any intellectual property or other rights that might be claimed to 642 pertain to the implementation or use of the technology described in 643 this document or the extent to which any license under such rights 644 might or might not be available; neither does it represent that it 645 has made any effort to identify any such rights. Information on the 646 IETF's procedures with respect to rights in standards-track and 647 standards-related documentation can be found in BCP-11. Copies of 648 claims of rights made available for publication and any assurances 649 of licenses to be made available, or the result of an attempt made 650 to obtain a general license or permission for the use of such 651 proprietary rights by implementors or users of this specification 652 can be obtained from the IETF Secretariat. 654 The IETF invites any interested party to bring to its attention 655 any copyrights, patents or patent applications, or other proprietary 656 rights which may cover technology that may be required to practice 657 this standard. Please address the information to the IETF Executive 658 Director. 660 Full Copyright Statement 662 Copyright (C) The Internet Society 2003. All Rights Reserved. 664 This document and translations of it may be copied and furnished 665 to others, and derivative works that comment on or otherwise explain 666 it or assist in its implementation may be prepared, copied, 667 published and distributed, in whole or in part, without restriction 668 of any kind, provided that the above copyright notice and this 669 paragraph are included on all such copies and derivative works. 670 However, this document itself may not be modified in any way, such 671 as by removing the copyright notice or references to the Internet 672 Society or other Internet organizations, except as needed for the 673 purpose of developing Internet standards in which case the 674 procedures for copyrights defined in the Internet Standards process 675 must be followed, or as required to translate it into languages 676 other than English. 678 The limited permissions granted above are perpetual and will not 679 be revoked by the Internet Society or its successors or assigns. 681 This document and the information contained herein is provided 682 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 683 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, 684 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 685 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 686 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.