[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03 05 06

Internet Draft                                               R. Gellens
Document: draft-ietf-acap-pers-06.txt                          QUALCOMM
Expires: August 2003                                      February 2003


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


Copyright Notice

    Copyright (C) The Internet Society 2003.  All Rights Reserved.
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.








Gellens                   Expires August 2003                   [Page 1]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    This specification defines a standard ACAP dataset class for email
    personalities, and a common option for indicating a default.

    An SMTP URL scheme is also defined.















































Gellens                   Expires August 2003                   [Page 2]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


Table of Contents

    1.  Conventions Used in this Document . . . . . . . . . . . . . .  3
    2.  Changes Since Previous Version . . . . . . . . . . . . . . .   3
    3.  Comments  . . . . . . . . . . . . . . . . . . . . . . . . . .  3
    4.  ACAP Standard Options  . . . . . . . . . . . . . . . . . . .   4
    5.  ACAP Email Personality Dataset Class  . . . . . . . . . . . .  4
      5.1.  ACAP Email Personality Dataset Class Prefix  . . . . . .   4
      5.2.  ACAP Email Personality Dataset Hierarchy  . . . . . . . .  4
    6.  ACAP Email Personality Dataset Attributes  . . . . . . . . .   4
      6.1.  Basic Attributes  . . . . . . . . . . . . . . . . . . . .  5
      6.2.  Specific Attributes  . . . . . . . . . . . . . . . . . .   5
    7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
    8.  The SMTP URL Scheme  . . . . . . . . . . . . . . . . . . . .  10
      8.1.  SMTP User Name and Authentication Mechanism . . . . . . . 10
      8.2.  Relative SMTP URLs . . . . . . . . . . . . . . . . . . .  12
      8.3.  Multinational Considerations  . . . . . . . . . . . . . . 12
      8.4.  Example  . . . . . . . . . . . . . . . . . . . . . . . .  12
      8.5.  ABNF for SMTP URL scheme  . . . . . . . . . . . . . . . . 12
      8.6.  Security Considerations  . . . . . . . . . . . . . . . .  13
    9.  Normative References  . . . . . . . . . . . . . . . . . . . . 13
     10.  Informative References . . . . . . . . . . . . . . . . . .  15
     11.  Security Considerations . . . . . . . . . . . . . . . . . . 15
     12.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  15
     13.  Author's Address  . . . . . . . . . . . . . . . . . . . . . 16
      Intellectual Property Statement  . . . . . . . . . . . . . . .  16
      Full Copyright Statement  . . . . . . . . . . . . . . . . . . . 16


1.  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].


2.  Changes Since Previous Version

    - Cleaned up examples.
    - Minor text clarifications.
    - Added specification of SMTP URL.


3.  Comments







Gellens                   Expires August 2003                   [Page 3]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    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.


4.  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].


5.  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].


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


5.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 4 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 2003                   [Page 4]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


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


6.1.  Basic Attributes

    These attributes are defined in ACAP [ACAP] and have meaning in all
    dataset classes.  This 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.


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






Gellens                   Expires August 2003                   [Page 5]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    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"

    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]







Gellens                   Expires August 2003                   [Page 6]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    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
                              ;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





Gellens                   Expires August 2003                   [Page 7]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    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 Section 8.

        pers-smtp           = url ;defined in [URL-BASIC]

    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]






Gellens                   Expires August 2003                   [Page 8]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    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.

        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"


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


Gellens                   Expires August 2003                   [Page 9]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    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


8.  The SMTP URL Scheme

    The SMTP URL scheme designates an [SMTP] server, and optionally a
    port number, authentication mechanism, authentication ID, and/or
    authorization ID.

    The SMTP URL follows the common Internet scheme syntax as defined in
    RFC 1738 [BASIC-URL] except that clear text passwords are not
    permitted.  If :<port> is omitted, the port defaults to 25.

    The SMTP URL is described using [ABNF] in section 8.5.

    An SMTP URL is of the general form:

    smtp:<user>;auth=<auth>@<host>:<port>

    Where <user>, <host>, and <port> are as defined in RFC 1738, and
    some or all of the elements, except "smtp:" and <host>, may be
    omitted.


8.1.  SMTP User Name and Authentication Mechanism

    An authorization (which [SMTP] account to access) and authentication
    (whose password to check against) identity (referred to as "user
    name" for simplicity) and/or authentication mechanism name may be
    supplied.  These are used in an AUTH [SMTP-AUTH], or extension
    command after making the connection to the SMTP server.  If the URL
    doesn't supply an authentication identifier, the program
    interpreting the SMTP URL MAY request one from the user.

    An authentication mechanism can be expressed by adding ";AUTH=<enc-
    auth-type>" to the end of the user name.  If the authentication
    mechanism name is not preceded by a "+", it is a SASL SMTP [SASL]
    mechanism.  If it is preceded by a "+", it is an extension
    mechanism.







Gellens                  Expires August 2003                  [Page 10]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    When an <enc-auth-type> is specified, the client SHOULD request
    appropriate credentials from that mechanism and use the "AUTH", (or
    extension) command.  If no user name is specified and an
    <enc-auth-type> is specified, a user name SHOULD be obtained from
    the mechanism or requested from the user as appropriate.

    The string ";AUTH=*" indicates that the client SHOULD select an
    appropriate authentication mechanism.  It MAY use any mechanism
    supported by the [SMTP] server.

    If an <enc-auth-type> other than ";AUTH=*" is specified, the client
    SHOULD NOT use a different mechanism without explicit user
    permission.

    If a user name is included with no authentication mechanism, then
    ";AUTH=*" is assumed.

    Since URLs can easily come from untrusted sources, care must be
    taken when resolving a URL which requires or requests any sort of
    authentication.  If authentication credentials are supplied to the
    wrong server, it may compromise the security of the user's account.
    The program resolving the URL should make sure it meets at least one
    of the following criteria in this case:

    (1) The URL comes from a trusted source, such as a referral server
    which the client has validated and trusts according to site policy.
    Note that user entry of the URL may or may not count as a trusted
    source, depending on the experience level of the user and site
    policy.

    (2) Explicit local site policy permits the client to connect to the
    server in the URL.  For example, if the client knows the site domain
    name, site policy may dictate that any hostname ending in that
    domain is trusted.

    (3) The user confirms that connecting to that domain name with the
    specified credentials and/or mechanism is permitted.

    (4) A mechanism is used which validates the server before passing
    potentially compromising client credentials.

    (5) An authentication mechanism is used which will not reveal
    information to the server which could be used to compromise future
    connections.







Gellens                  Expires August 2003                  [Page 11]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    A URL containing ";AUTH=*" should be treated with extra care since
    it might fall back on a weaker security mechanism.  Finally, clients
    are discouraged from using a plain text password as a fallback with
    ";AUTH=*" unless the connection has strong encryption (e.g., a key
    length of greater than 56 bits).

    Note that if unsafe or reserved characters such as " " or ";" are
    present in the user name or authentication mechanism, they MUST be
    encoded as described in RFC 1738 [BASIC-URL].

8.2.  Relative SMTP URLs

    Relative SMTP URLs are not permitted.

8.3.  Multinational Considerations

    Since 8-bit characters are not permitted in URLs, [UTF8] characters
    are encoded as required by the URL specification [BASIC-URL].

8.4.  Example

    The following example demonstrate how an SMTP client program might
    translate various SMTP URLs into a series of SMTP commands.
    Commands sent from the client to the server are prefixed with "C:",
    and responses sent from the server to the client are prefixed with
    "S:".


    The URL:

            <smtp:rg;AUTH=CRAM-MD5@smtp.example.com:8025>

        Results in the following client commands:

        <client requests password from user>
        <connect to smtp.example.com, port 8025>
         S: 220 smtp.example.com ESMTP server ready
         C: EHLO jgm.example.com
         S: 250-smtp.example.com
         S: 250 AUTH CRAM-MD5 DIGEST-MD5
         C: AUTH CRAM-MD5
         S: 334
         PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
         C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
         S: 235 Authentication successful.






Gellens                  Expires August 2003                  [Page 12]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


8.5.  ABNF for SMTP URL scheme

        The SMTP URL scheme is described using [ABNF]:

        achar            = uchar / "&" / "=" / "~"
                                ; see [BASIC-URL] for "uchar" definition

        auth             = ";AUTH=" ( "*" / enc-auth-type )

        enc-auth-type    = enc-sasl / enc-ext

        enc-ext          = "+" 1*achar
                              ;encoded extension mechanism name

        enc-sasl         = 1*achar
                              ;encoded version of [SASL] "auth_type"

        enc-user         = 1*achar
                              ;encoded version of SMTP mailbox

        smtp-url         = "smtp:" server

        server           = [user-auth "@"] hostport
                              ;See [BASIC-URL] for "hostport" definition

        user-auth        = enc-user [auth]


8.6.  Security Considerations

        Security considerations discussed in the [SMTP-AUTH]
    specification and the [BASIC-URL] specification are relevant.
    Security considerations related to authenticated URLs are discussed
    in section 8.1 of this document.

        Many email clients store the plain text password for later use
    after logging into a server.  Such clients MUST NOT use a stored
    password in response to an SMTP URL without explicit permission from
    the user to supply that password to the specified host name.


9.  Normative 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>




Gellens                  Expires August 2003                  [Page 13]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


        [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",
    workin Progress.
    <ftp://ftp.ietf.org/internet-drafts/draft-ietf-acap-options-xx.txt>

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

        [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-AUTH] J. Myers, "SMTP Service Extension for
    Authentication", RFC 2554, Netscape Communications, March 1999.
    <ftp://ftp.isi.edu/in-notes/rfc2554.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>







Gellens                  Expires August 2003                  [Page 14]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


        [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.  Informative References

        [IPSEC] R. Atkinson, "Security Architecture for the Internet
    Protocol", RFC 1825, August 1995,
    <ftp://ftp.isi.edu/in-notes/rfc1825.txt>

        [SMTP] J. Klensin, "Simple Mail Transfer Protocol", RFC 2821,
    April 2001, <ftp://ftp.isi.edu/in-notes/rfc2821.txt>

        [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", RFC 2246,
    Certicom, January 1999. <ftp://ftp.isi.edu/in-notes/rfc2246.txt>


11.  Security Considerations

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

        Security considerations for SMTP URLs are discussed in section
    8.6.


12.  Acknowledgments







Gellens                  Expires August 2003                  [Page 15]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


        Many thanks to the participants of the IETF ACAP working group
    fortheir help, comments, and suggestions.


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


Intellectual Property Statement

        The IETF takes no position regarding the validity or scope of
    any intellectual property or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; neither does it represent that it
    has made any effort to identify any such rights.  Information on the
    IETF's procedures with respect to rights in standards-track and
    standards-related documentation can be found in BCP-11.  Copies of
    claims of rights made available for publication and any assurances
    of licenses to be made available, or the result of an attempt made
    to obtain a general license or permission for the use of such
    proprietary rights by implementors or users of this specification
    can be obtained from the IETF Secretariat.

        The IETF invites any interested party to bring to its attention
    any copyrights, patents or patent applications, or other proprietary
    rights which may cover technology that may be required to practice
    this standard.  Please address the information to the IETF Executive
    Director.


Full Copyright Statement

        Copyright (C) The Internet Society 2003.  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


Gellens                  Expires August 2003                  [Page 16]


Internet Draft    ACAP Email Personality Dataset Class    February 2003


    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.

        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 2003                  [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/