Internet Draft R. Gellens Document: draft-ietf-acap-pers-03.txt QUALCOMM Expires: 25 August 2000 25 February 2000 ACAP Email Personality Dataset Class Status of this Memo: This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at <http://www.ietf.org/ietf/1id-abstracts.txt> The list of Internet-Draft Shadow Directories can be accessed at <http://www.ietf.org/shadow.html>. A version of this draft document is intended for submission to the RFC editor as a Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested. Copyright Notice Copyright (C) The Internet Society 2000. All Rights Reserved. Gellens Expires August 2000 [Page 1]Internet Draft ACAP Email Personality Dataset Class February 2000 Table of Contents 1. Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in this Document . . . . . . . . . . . . . 2 3. Changes Since Previous Version . . . . . . . . . . . . . . . 2 4. Comments . . . . . . . . . . . . . . . . . . . . . . . . . 3 5. ACAP Standard Options . . . . . . . . . . . . . . . . . . . 3 6. ACAP Email Personality Dataset Class . . . . . . . . . . . 3 6.1. ACAP Email Personality Dataset Class Prefix . . . . . . 3 6.2. ACAP Email Personality Dataset Hierarchy . . . . . . . 3 7. ACAP Email Personality Dataset Attributes . . . . . . . . . 3 7.1. Basic Attributes . . . . . . . . . . . . . . . . . . . 4 7.2. Specific Attributes . . . . . . . . . . . . . . . . . . 4 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations . . . . . . . . . . . . . . . . . . 9 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 10 12. Author's Address . . . . . . . . . . . . . . . . . . . . . 10 13. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 1. Abstract It has become common for Internet mail users to receive and compose mail in the capacity of different roles or identities (for example, personal and work), to receive and compose mail at different machines, and to use multiple programs which require mail composition configuration information. These different roles or identities have become known as email personalities. The Application Configuration Access Protocol [ACAP] provides an ideal mechanism for storage of email personality data. This specification defines a standard ACAP dataset class for email personalities, and a common option for indicating a default. 2. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. 3. Changes Since Previous Version - Added attributes: personality.SMTP-Auth.permitted.clear, personality.SMTP-Auth.permitted.nonclear. - Clarified personalities vs. email datasets. - Enhanced "Security Considerations". Gellens Expires August 2000 [Page 2]Internet Draft ACAP Email Personality Dataset Class February 2000 4. Comments Public comments can be sent to the IETF ACAP mailing list, <ietf-acap+@andrew.cmu.edu>. To subscribe, send a message to <ietf-acap-request+@andrew.cmu.edu> with the word SUBSCRIBE as the body. Private comments should be sent to the author. 5. ACAP Standard Options This specification defines the MUA Default Personality standard option. This is a scaler option in the ACAP Standard Option ("/option") dataset. The entry name is "mua.default.personality". The "option.value" attribute contains the value, which is a URL. Generally, this will be an ACAP URL pointing to an entry in an Email Personality dataset. The standard option dataset class is specified in [ACAP-OPTIONS]. ACAP URLs are defined in [ACAP]. 6. ACAP Email Personality Dataset Class The ACAP Email Personality dataset class defines a set of attributes which specify an email personality; that is, configuration information used for composing and sending email. Configuration information related to accessing and retrieving received email is stored in the ACAP Email Account Dataset Class [ACAP-ACCOUNT]. 6.1. ACAP Email Personality Dataset Class Prefix Datasets whose names begin with "/personality" are assumed to contain email personality entries as defined in this specification. 6.2. ACAP Email Personality Dataset Hierarchy Each user may have a set of named email personalities. The default is pointed at by the "mua.default.personality" standard option. (See section 5 for more information.) Inheritance is likely to be useful both for inheriting site or group defaults (for example, SMTP servers, and initial client configuration in general) as well as for inheriting user-specific configuration when using different machines. Gellens Expires August 2000 [Page 3]Internet Draft ACAP Email Personality Dataset Class February 2000 7. ACAP Email Personality Dataset Attributes An email personality entry MUST have an "entry" attribute. All other attributes are OPTIONAL. Attributes are specified using Augmented Backus-Naur Form [ABNF]. All attributes are single-valued and textual unless otherwise stated. The ABNF defines the content of the attribute values prior to their encoding as an ACAP string. Clients MUST conform to the syntax when generating these attributes, but MUST NOT assume that the attribute values will conform to this syntax on access. Servers MUST NOT enforce the syntax. 7.1. Basic Attributes These attributes are defined in ACAP [ACAP] and have meaning in all dataset classes. The section describes how they are used in an email personality dataset. entry The "entry" attribute is used to hold a unique name for the personality. This name is used for inheritance, so when customizing a personality which has an entry in an inherited dataset, the entry name needs to remain the same. The name should also be descriptive. subdataset The "subdataset" attribute indicates that there is a subdataset of this entry. The value of this attribute specifies the actual location of the subdataset, per [ACAP] section 3.1.1. 7.2. Specific Attributes These attributes are specific to the Email Personality dataset class. personality.Auto.Encrypt This flag indicates if the client should automatically encrypt messages composed with this personality. pers-auto-enc = "0" / "1" personality.Auto.Sign This flag indicates if the client should automatically apply a digital signature to messages composed with this personality. pers-auto-sign = "0" / "1" Gellens Expires August 2000 [Page 4]Internet Draft ACAP Email Personality Dataset Class February 2000 personality.Cert-DN This contains the certificate name to be used when encrypting and/or signing messages using certificate-based mechanisms. pers-cert-dn = 1*UTF8-CHAR personality.Charset This specifies the default coded character set to be used when composing messages. The name must be in the IANA charset registry (located at <ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>). pers-charset = 1*CHAR personality.File-Into.IMAP This specifies an IMAP folder into which new messages should be copied by default. Generally, this is specified as an IMAP URL, as defined in [URL-IMAP]. pers-file-imap = url ;defined in [URL-BASIC] personality.File-Into.Local This specifies the name of a local folder into which new messages should be placed by default. pers-file-local = 1*UTF8-CHAR personality.Header.BCC This specifies the default BCC header field contents. pers-hdr-bcc = *address ;address specified in [RFC-822] personality.Header.CC This specifies the default CC header field contents. pers-hdr-cc = 1*address ;address specified in [RFC-822] personality.Header.Extra This multivalued attribute contains additional header fields. Each value contains the complete canonical form of a header name and contents. Values must conform to [RFC-822] and [MIME]. pers-hdr-extra = 1*CHAR ;must conform to [RFC-822] and [MIME] personality.Header.Reply-To This specifies the default Reply-To header field contents. Values must conform to [RFC-822] and [MIME]. pers-hdr-reply = 1*CHAR Gellens Expires August 2000 [Page 5]Internet Draft ACAP Email Personality Dataset Class February 2000 ;must conform to [RFC-822] and [MIME] personality.Language This contains the default language to be specified in language tags. The name must be in the IANA language registry (located at <ftp://ftp.isi.edu/in-notes/iana/assignments/languages>). pers-lang = 1*CHAR personality.MIME.Composition-Type This specifies the default MIME type to use when composing messages which contain any text elements or parts. The value is a MIME type and subtype, with optional parameters. The value should be canonicalized by removing unnecessary quoting. The type, subtype, and any parameters must conform to [MIME], including IANA registration requirements. Free insertion of linear-white-space is not permitted. pers-mtype = type "/" subtype *(";" SP parameter) ;defined in RFC 2045 [MIME] personality.PGP.Key-ID.bin This contains the Key ID when PGP is used to encrypt and/or sign messages. pers-pgp-key = *OCTET personality.Real-Name This contains the display name associated with the personality. The phrase component of the From header field should be constructed from this value. pers-name = 1*UTF8-CHAR personality.Return-Address This contains the [RFC-822] addr-spec associated with the personality. The addr-spec of the From header field should by default contain this value. It is separated from the phrase From field component (stored in "personality.Real-Name") to make comparisons easier. pers-addr = addr-spec ;addr-spec defined in [RFC-822] personality.Server.SMTP This specifies the SMTP server to be used when sending messages for this personality. Generally, the form is an SMTP URL, as defined in [URL-SMTP]. pers-smtp = url ;defined in [URL-BASIC] Gellens Expires August 2000 [Page 6]Internet Draft ACAP Email Personality Dataset Class February 2000 personality.Signature.Text This contains the signature text to be appended by default to new messages. It is stored in canonical form, with CRLF-separated lines. When a signature separator line is used, it SHOULD NOT be contained in this attribute, but instead added automatically by the client. pers-sig-text = 1*CHAR personality.Signature.URL When the signature to be appended by default to new messages is stored in a file or other resource, this attribute is used instead of "personality.Signature.Text". This attribute contains a URL (for example, a file URL) to the signature text. It is assumed that the signature text is in canonical form, with CRLF-separated lines. When a signature separator line is used, it SHOULD NOT be contained in this file, but instead added automatically by the client. pers-sig-url = url ;defined in [URL-BASIC] personality.Stationery This attribute contains a URL (for example, a file URL) to the stationery, or template, to be used when creating new messages with this personality. In general the stationery contains a canonicalized message, with header fields and/or body. pers-statn = url ;defined in [URL-BASIC] personality.SMTP-Auth.permitted.clear This attribute specifies if clear-text [SMTP-AUTH] mechanisms are permitted. A value of "never" indicates such mechanisms can never be used for this personality. A value of "encrypted" gives permission to use such mechanisms if an encrypted channel is in effect, such as [TLS] or [IPSEC]. A value of "always" permits such mechanisms to be used under all conditions. Note that use of clear-text mechanisms poses at least two different risks: one is that the password may be captured in-transit (which can be mitigated by using an encryption layer); the second is that the password may be disclosed to an inappropriate server. pers-auth-clear = "never" / "encrypted" / "always" personality.SMTP-Auth.permitted.nonclear This attribute specifies if non-clear-text [SMTP-AUTH] mechanisms (such as CRAM-MD5, Kerberos, or One Time Password) are permitted. A value of "never" indicates such mechanisms can never be used for this personality. A value of "always" permits such mechanisms to be used under all conditions. Gellens Expires August 2000 [Page 7]Internet Draft ACAP Email Personality Dataset Class February 2000 Note that some non-clear-text mechanisms are vulnerable to various attacks which could result in an unauthorized server obtaining the user's password. pers-auth-nonclear = "never" / "always" 8. Examples entry personal personality.File-Into.Local sent mail personality.Header.Extra X-Pet: Yak personality.MIME.Composition-Type text/plain; format=flowed personality.Real-Name L. Eva Message personality.Return-Address lem@pop.example.net personality.Server.SMTP smtp://smtp.example.net personality.Signature.Text L. Eva Message "sua cuique voluptas" personality.SMTP-Auth.permitted.clear Never entry work personality.File-Into.IMAP IMAP://lem@example.org/sent personality.Header.Extra Organization: A.T.&Love personality.MIME.Composition-Type multipart/alternative personality.Real-Name L. Eva Message personality.Return-Address lem@mail.example.org personality.Server.SMTP smtp://smtp.example.org personality.Signature.URL file://signature.txt personality.SMTP-Auth.permitted.clear Never personality.SMTP-Auth.permitted.nonclear Always 9. References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd., November 1997. <ftp://ftp.isi.edu/in-notes/rfc2234.txt> [ACAP] Newman, Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, Innosoft, Netscape, November 1997. <ftp://ftp.isi.edu/in-notes/rfc2244.txt> [ACAP-ACCOUNT] Gellens, "ACAP Email Account Dataset Class", work in Progress. <ftp://ftp.ietf.org/internet-drafts/draft-ietf-acap-email-xx.txt> [ACAP-OPTIONS] Hole, "ACAP Application Options Dataset Class", work in Progress. <ftp://ftp.ietf.org/internet-drafts/draft-ietf-acap-options-xx.txt> Gellens Expires August 2000 [Page 8]Internet Draft ACAP Email Personality Dataset Class February 2000 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. <ftp://ftp.isi.edu/in-notes/rfc2119.txt> [IPSEC] R. Atkinson, "Security Architecture for the Internet Protocol", RFC 1825, August 1995, <ftp://ftp.isi.edu/in-notes/rfc1825.txt> [RFC-822] Crocker, "Standard for the Format of ARPA Internet Text Messages", RFC 822, STD 11, University of Delaware, August 1982. <ftp://ftp.isi.edu/in-notes/rfc822.txt> [MIME] Freed, Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996; Freed, Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual, November 1996; Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, University of Tennessee, November 1996. <ftp://ftp.isi.edu/in-notes/rfc2045.txt> <ftp://ftp.isi.edu/in-notes/rfc2046.txt> <ftp://ftp.isi.edu/in-notes/rfc2047.txt> [SMTP] J. Postel, "Simple Mail Transfer Protocol", RFC 821, STD 10, August 1982. <ftp.isi.edu/in-notes/rfc821.txt> [SMTP-AUTH] J. Myers, "SMTP Service Extension for Authentication", RFC 2554, Netscape Communications, March 1999. <ftp://ftp.isi.edu/in-notes/rfc2554.txt> [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", RFC 2246, Certicom, January 1999. <ftp://ftp.isi.edu/in-notes/rfc2246.txt> [URL-BASIC] Berners-Lee, Masinter, McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of Minnesota, December 1994. <ftp://ftp.isi.edu/in-notes/rfc1738.txt> [URL-IMAP] Newman, "IMAP URL Scheme", RFC 2192, Innosoft, September 1997. <ftp://ftp.isi.edu/in-notes/rfc2192.txt> [URL-SMTP] Earhart, "An SMTP URL Interface", work in progress. <ftp://ftp.ietf.org/internet-drafts/draft-earhart-url-smtp-xx.txt> [UTF8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", RFC 2279, Alis Technologies, January 1998. <ftp://ftp.isi.edu/in-notes/rfc2279.txt> 10. Security Considerations Gellens Expires August 2000 [Page 9]Internet Draft ACAP Email Personality Dataset Class February 2000 As with ACAP datasets in general, it is important that access controls are set correctly on Email Personality datasets. Attributes may contain highly personal information which should not be disclosed except by explicit owner request. In addition, by changing certain attributes (such as "personality.SMTP-Auth.permitted.clear", "personality.SMTP-Auth.permitted.nonclear", and "personality.server.SMTP"), an attacker could cause a user to attempt an unsafe and unwise authentication, including potentially sending the user's password in the clear to a rogue server. The "personality.SMTP-Auth.permitted.clear" attribute mentions two of the risks associated with sending clear-text passwords to an SMTP server. The "personality.SMTP-Auth.permitted.nonclear" attribute mentions one of the risks associated with using non-clear-text authentication mechanisms. 11. Acknowledgments Many thanks to the participants of the IETF ACAP working group for their help, comments, and suggestions. 12. Author's Address Randall Gellens +1 858 651 5115 QUALCOMM Incorporated randy@qualcomm.com 5775 Morehouse Drive San Diego, CA 92121-2779 U.S.A. 13. Full Copyright Statement Copyright (C) The Internet Society 2000. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. Gellens Expires August 2000 [Page 10]Internet Draft ACAP Email Personality Dataset Class February 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Gellens Expires August 2000 [Page 11]
Datatracker
Report a datatracker bug
draft-ietf-acap-pers-03
Internet-Draft
| Document | Document type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | anonymous%20IMAP%3A%20cyrus.andrew.cmu.edu%3Aarchive.ietf-acap |