SMTP Service Extension for Client Identity
draft-storey-smtp-client-id-18

Internet Engineering Task Force                           W. Storey, Ed.
Internet-Draft                                                D. Yu, Ed.
Intended status: Standards Track                         S. Johnson, Ed.
Expires: 1 June 2025                                          LinuxMagic
                                                        28 November 2024

               SMTP Service Extension for Client Identity
                     draft-storey-smtp-client-id-18

Abstract

   Multi-Factor Authentication has rapidly become a driving requirement
   for any internet based technology that requires authentication.
   While a large number of initiatives are active for providing
   solutions to this requirement for Web Browser based applications that
   can generally support real time human interaction for providing a
   secondary method of identification, legacy protocols such as SMTP
   authentication have not yet been revised to provide such support
   despite being a high-risk target for business email compromise,
   possibly as a result of authenticated SMTP activity generally
   expecting to be non-interactive in nature outside of Webmail logins.

   This document defines an extension to the SMTP service protocol
   called "CLIENTID" that a SMTP client can provide an additional unique
   identification token prior to standard credentials authentication
   that the server may then apply as an identify verification method in
   a similar manner to other Multi-Factor authentication techniques.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on 1 June 2025.

Storey, et al.             Expires 1 June 2025                  [Page 1]
Internet-Draft            SMTP Client Identity             November 2024

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Conventions Used in This Document . . . . . . . . . . . .   3
   2.  The CLIENTID Service Extension  . . . . . . . . . . . . . . .   3
   3.  The CLIENTID Keyword of the EHLO Command  . . . . . . . . . .   4
   4.  The CLIENTID Command  . . . . . . . . . . . . . . . . . . . .   4
   5.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  Applying heuristics to CLIENTID . . . . . . . . . . . . .   6
     6.2.  Utility of CLIENTID . . . . . . . . . . . . . . . . . . .   7
     6.3.  Use Cases of CLIENTID . . . . . . . . . . . . . . . . . .   8
     6.4.  Other SMTP Client Identifiers . . . . . . . . . . . . . .   9
     6.5.  Future Considerations . . . . . . . . . . . . . . . . . .   9
     6.6.  Client Identity Types . . . . . . . . . . . . . . . . . .  10
   7.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  UUID Address as Client Identity . . . . . . . . . . . . .  12
     7.2.  Client Identity Without a TLS/SSL Session . . . . . . . .  12
     7.3.  Client Identity Leading to Rejection  . . . . . . . . . .  13
     7.4.  Malformed CLIENTID Command  . . . . . . . . . . . . . . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  15
   Appendix A.  Appendix A.  CLIENTID Product Support  . . . . . . .  16
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

Storey, et al.             Expires 1 June 2025                  [Page 2]
Internet-Draft            SMTP Client Identity             November 2024

1.  Introduction

   The [SMTP] protocol and its extensions describe methods whereby an
   SMTP client may provide identity and/or authentication information to
   an SMTP server.  However, these existing methods are subject to
   limitations and none offer a way to identify the SMTP client with
   absolute confidence.  This document defines an SMTP service extension
   to provide an additional identity token which can represent the SMTP
   client with a higher degree of certainty when accessing the SMTP
   server.

   Typically SMTP clients are identified by establishing an authorized
   connection using the [AUTH] SMTP extension.  SMTP servers are often
   subject to malicious clients attempting to use authorized identities
   not intended for their use (often referred to as a brute-force
   attack).  When such an attack is attempted, the SMTP server may be
   unable to identify the impersonation and restrict such an unintended
   use by someone other than the authorized user of said credentials.
   While there are ways to identify the source of the SMTP client such
   as its IP address or EHLO identity, it would be useful if there was
   an additional way to uniquely identify the client in a method solely
   available across an encrypted channel.

   Using the CLIENTID extension, an SMTP client can provide an
   additional identity token to the server called its "client identity".
   The client identity can provide unique characteristics about the
   client accessing the SMTP service and may be combined with existing
   identification mechanisms in order to identify the client.  An SMTP
   server may then apply additional security policies using this
   identity such as restricting use of the service to clients presenting
   recognized client identities, or only allowing use of authorized
   identities that match previously established client identities.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  The CLIENTID Service Extension

   The following SMTP service extension is hereby defined:

   1.  The name of this [SMTP] service extension is "Client Identity".

Storey, et al.             Expires 1 June 2025                  [Page 3]
Internet-Draft            SMTP Client Identity             November 2024

   2.  The EHLO keyword value associated with this extension is
       "CLIENTID".

   3.  The CLIENTID keyword has no parameters.

   4.  A new [SMTP] verb "CLIENTID" is defined.

   5.  No parameter is added to any SMTP command.

   6.  This extension is appropriate for the submission protocol
       [SUBMIT].

3.  The CLIENTID Keyword of the EHLO Command

   The CLIENTID keyword is used to tell the SMTP client that the SMTP
   server supports the CLIENTID service extension.  Though certain
   conditions must be met before the CLIENTID keyword can be advertised.

   1.  An SMTP server MUST NOT advertise the CLIENTID keyword in any
       EHLO responses if the CLIENTID extension support is not enabled.

   2.  An SMTP server MUST NOT advertise the CLIENTID keyword in any
       EHLO response if the connection is not encrypted.

   3.  An SMTP server MUST advertise the CLIENTID keyword in all EHLO
       responses after the connection is successfully encrypted (if
       CLIENTID is supported).

   4.  [PIPELINING] SHOULD NOT be advertised in conjunction with
       CLIENTID as [PIPELINING] is considered to be incompatible with
       CLIENTID.

4.  The CLIENTID Command

   The format for the CLIENTID command is:

   CLIENTID client-id-type client-id-token

       Arguments:

             client-id-type: A string identifying the identity type the
             client is providing.  It MUST be between 1 and 16
             characters and comprised of only alphanumeric and dash
             characters.

             client-id-token: A string identifying the client.  It MUST
             be between 1 and 128 printable characters.

Storey, et al.             Expires 1 June 2025                  [Page 4]
Internet-Draft            SMTP Client Identity             November 2024

   Restrictions:

   An SMTP client MUST NOT issue a CLIENTID command unless a TLS/SSL
   session has been negotiated as described in [STARTTLS] or through
   other means such as over an end to end SMTP-SSL connection.  An SMTP
   server MUST reject any CLIENTID command sent before establishing an
   encrypted connection with a 500 or 502 reply to indicate an
   unsupported or unimplemented command response.

   An SMTP client MUST only issue the CLIENTID command after the SMTP
   server advertises the CLIENTID keyword via an EHLO command.  An SMTP
   server MUST reject a CLIENTID command prior to advertising the
   CLIENTID keyword via an EHLO command.

   An SMTP server MUST reject any CLIENTID command that is not well
   formatted with a 501 reply.  An SMTP client MUST NOT issue any
   subsequent CLIENTID commands after a successful CLIENTID command in
   the same session.  An SMTP server MUST reject any subsequent CLIENTID
   commands after a successful CLIENTID command in the same session with
   a 503 reply.

   An SMTP client MUST issue any CLIENTID commands prior to issuing an
   [AUTH] command.  An SMTP server MUST reject any CLIENTID command
   after receiving an [AUTH] command with a 503 reply.

   SMTP service extensions such as [AUTH], and [SMTP] Command EHLO
   require that an SMTP session be reset to an initial state after
   completion of the command.  An SMTP server MUST discard any CLIENTID
   information after such a reset.

5.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form notation as specified in [ABNF].  Non-terminals referenced but
   not defined below are as defined by [ABNF].

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.

         client-id-type-char = ALPHA / DIGIT / "-"
                             ;; alphanumeric and dash character

         client-id-type      = 1*16 client-id-type-char

         client-id-token     = 1*128 VCHAR
                             ;; any printable US-ASCII character

Storey, et al.             Expires 1 June 2025                  [Page 5]
Internet-Draft            SMTP Client Identity             November 2024

6.  Discussion

6.1.  Applying heuristics to CLIENTID

   This section discusses the possible heuristics that can be applied to
   the information that is presented via the CLIENTID command.  This
   information includes whether a valid CLIENTID command was issued, the
   client identity type and the client identity token.

   1.  An SMTP server MAY choose to require that a successful CLIENTID
       command be issued, or that a particular client type be presented
       before processing or accepting an authentication request.

   2.  An SMTP server MAY reject any authentication request not preceded
       with a client identity type that matches ACL's or rules as
       defined in the SMTP server.

   3.  An SMTP server MAY reject any authentication request preceded by
       a CLIENTID command that contains a client identity type or client
       identity token that the server chooses not to accept for any
       reason such as by policy.

   4.  An SMTP server MAY reject any authentication request preceded by
       a CLIENTID command that contains a client identity type or client
       identity token that the server has chosen to disable or revoke
       use of either temporarily or permanently.

   5.  An SMTP server MAY reject any authentication request where the
       provided client identity is not on the list of permitted clients
       for the account holder.

   The SMTP server SHOULD only ever reject an SMTP client based on
   CLIENTID information during or after the authentication process/
   handler.  In the interest of limiting the amount of information being
   revealed, the rejection message SHOULD be as generic as possible and
   SHOULD NOT reveal any information on the heuristics or rules on which
   it bases it's decisions.

   Even if the client identity type and/or client identity token are not
   recognized, supported or permitted by the server and/or the owner of
   the authentication credentials, the presented information may still
   be useful for heuristics such as threat analysis.

Storey, et al.             Expires 1 June 2025                  [Page 6]
Internet-Draft            SMTP Client Identity             November 2024

6.2.  Utility of CLIENTID

   Regardless of how frowned upon, users commonly reuse authorization
   information (like the username and password pair) across multiple
   services.  When one service is compromised, malicious actors can also
   gain access to other services where the user also used the same
   credentials.  Based on this representative problem alone, the utility
   of CLIENTID as an additional layer of determining the rights to
   present such authorization information becomes quickly apparent.

   The utility of CLIENTID may be seen by considering the following:

   1.  An SMTP client may be present on a device that does not have a
       useful domain name or network address, such as a mobile device,
       so its EHLO identity may be ambiguous.

   2.  An authorized identity may make use of multiple discrete devices
       over different SMTP sessions, so an identity persisting on one
       device is lacking.

   3.  The SMTP DATA payload does not need to be inspected for this
       identity.

   4.  Connection information, a type of identity, such as network
       address frequently changes.

   However, this extends beyond just the restriction of authentication.
   While it might be argued that this can be served as a special form of
   SASL, by implementing this in the SMTP service itself, the SMTP
   service can choose before allowing a connection to be passed to a
   SASL implementation, allowing it to perform other heuristics, such as
   identifying brute force attacks more efficiently.

   The traditional methods of defending against these types of attacks
   such as tracking the rate of failed password attempts and
   subsequently blocking by IP address are no longer viable without
   collateral damage as thousands of devices could potentially be behind
   the same IP address as more ISPs adopt the CGN/LSN/NAT444 standard,
   i.e. blocking an IP address due to the actions of a single malicious
   actor bears the risk of blocking legitimate users.

   By introducing CLIENTID as another non-public factor to be used in
   tandem with the user and password combination, authentication becomes
   much more resilient against brute force attacks.  The email addresses
   and passwords exposed from the data breaches will no longer be
   sufficient to authenticate.  Security and mitigation methods such as
   limiting the rate in which authentication attempts can be made from a
   single IP address can be carried out by the CLIENTID identifier

Storey, et al.             Expires 1 June 2025                  [Page 7]
Internet-Draft            SMTP Client Identity             November 2024

   instead of the IP address, reducing the risk of falsely blocking
   traffic for clients behind a CGN/LSN/NAT444 connection.  CLIENTID
   would also be backwards compatible with existing authentication
   protocols encouraging adoption in a viable manner.

   While 'forgery' and/or the use of random client identifier is
   possible, such behavior is also more readily detectable when a device
   identifier is presented.

   1.  The SMTP server, when faced with hundreds of devices behind the
       same IP address, during an attack can restrict authentication
       attempts to only connections presenting a valid client identifier
       token.

   2.  The SMTP server, during an attack, can restrict authentication to
       only historically known devices.

   3.  The SMTP server can differentiate between many different devices
       behind the same IP, and apply maximum connections per device,
       rather than maximum connections per IP.

   4.  While a person may present authentication credentials from many
       different geographical locations, e.g. home, office, and travel,
       a single device will not in general be able to be in two
       geographical locations at the same time.  The SMTP server will
       have new information to apply to threat detection heuristics,
       i.e. to treat the use of the same client identifier token from
       two locations, as a possible brute force or forgery situation.

6.3.  Use Cases of CLIENTID

   The SMTP server may use the additional information from CLIENTID with
   its interactions with SMTP clients in the following manner:

   1.  Restrict use of an authorized identity to a set of client
       identities, thereby offering an added level of security.  For
       example, the use of an authorized identity may only be permitted
       from a single device using the client identity as a form of
       whitelisting.

   2.  Identify that the same client identity is used to access multiple
       authorized identities and restrict access to the SMTP service.
       For example, a client that has successfully gained access to many
       authorized identities may be identified through its use of a
       shared client identity.

   3.  Retain knowledge of client identities previously presented with

Storey, et al.             Expires 1 June 2025                  [Page 8]
Internet-Draft            SMTP Client Identity             November 2024

       an authorized identity and if an identity not previously seen is
       used restrict access to the SMTP service.

   4.  Require that the SMTP client present a token such as a license
       key established outside of the SMTP session in order to make use
       of any authorized identity;

   5.  Apply different security policies to clients that provide a
       client identity versus those which do not.  For example, provide
       clients providing such an identity with additional trust.

   6.  Ability to rate limit or block based on the presented client
       identifier token when multiple devices use a shared IP address
       without affecting other devices.

   7.  Ability to detect distributed and localized dictionary attacks
       and brute force attacks.

   8.  Use the client identifier token as a third factor to be passed to
       authentication methods.  [SASL]

6.4.  Other SMTP Client Identifiers

   The [SMTP] protocol and its extensions describe methods whereby an
   SMTP client may provide identity information to an SMTP server.  Some
   of these identities are listed for contrast:

   1.  The client connection source provides an IP address associated
       with the SMTP session.  This may be accompanied by a PTR record
       and/or GeoIP information.

   2.  The EHLO command allows a client to identify itself with a domain
       or address for an SMTP session.

   3.  The [AUTH] SMTP extension allows the client to establish an
       authorized identity for an SMTP session.

   4.  The MAIL command identifies a specific sender for a mail
       transaction.

6.5.  Future Considerations

   In the future there may be a demand for being able to provide
   multiple CLIENTID commands with different client identity types.  For
   instance, it may be desirable for a device to identify itself, both
   with a hardware device identifier and a software identifier.  We
   believe this to be out of scope, and can be accommodated with a
   special client identifier token which encapsulates both.

Storey, et al.             Expires 1 June 2025                  [Page 9]
Internet-Draft            SMTP Client Identity             November 2024

   In future, there may be a demand to formalize the methods to describe
   how the CLIENTID command should be handled for any given client
   identity type.  We believe this to currently be out of scope, but
   have created a successful implementation in which a server associates
   a set of flags to describe how it should behave:

   1.  Handled but treat as not presented (ignored, no persistence)

   2.  Store in SMTP session but treat as not presented (for debug)

   3.  Store in the SMTP session, so it is available to System log

   4.  Store in the SMTP session, so it is available to User log

   5.  Use for authentication

   6.  Use for alert when authentication fails

   7.  Use for alert when authentication succeeds

   8.  Unused

6.6.  Client Identity Types

   This document does not specify any CLIENTID identity type that MUST
   be supported.  The client identity type is meant to be defined by the
   client implementation that is designed to access the SMTP server and
   protocol.  For instance, many SMTP client software implementations
   already create a distinct UUID for each account.  Some commercial
   email clients have a license key.

   While there is no pre-defined list of client identity type defined by
   this RFC, and all SMTP servers should be prepared to accept any form
   suggested that SMTP client developers carefully consider the name of
   the client identity type.  For example, rather that using a client
   identity type of UUID, consider the advantages of making it more
   distinct, e.g. "<product_short_code>UUID".  This way the SMTP server
   can better record histories, e.g. the difference between say a
   Thunderbird generated unique id, and a Mutt generated unique id.

   Some examples of identity type might be UUID, LICENSE, DEVICE_ID and/
   or COOKIE.  It is expected that the most common types might be
   related to distinct UUID, LICENSEKEY, or HARDWAREID.

   An SMTP server SHOULD NOT reject an unidentified CLIENTID type,
   except for specific policy use cases.

Storey, et al.             Expires 1 June 2025                 [Page 10]
Internet-Draft            SMTP Client Identity             November 2024

   It is envisioned that in the future it will be useful to propose a
   set of standardized client-identity-type to help with validation, or
   to allow the SMTP server to apply ACL rules on expected types, this
   would be an extension to this RFC.

   1.UUID
      UUID is a common practice to represent either a individual user,
      hardware device or software installation associated with a
      specific individual.  The support of UUID enables existing UUID
      implementations to be used to semi-uniquely identify a device
      associated with an individual.  A definition of the format should
      be considered.  Otherwise non-standard UUID might be a separate
      type specific to the software implementation, for instance TBIRD-
      UUID.

   2.LICENSE
      An IMAP client may find it useful to identify the license key of
      software it is using.  Such licenses are typically crafted such
      that they are unique and useful to identify a software
      installation.  This is more normally suited for a software
      designed for a single-user.  While LICENSE could be standard type
      again, it might more more helpful to specify a vendor specific
      type such as BBLICENSEKEY.

   3.DEVICE_ID
      Many hardware devices are designed to be used by a single
      individual and already have an associated hardware device id.
      While a standard type might be defined, it also might be more
      helpful to use a vendor specific type, such as ATOM-DEVICEID.

   4.COOKIE
      While not guaranteed to be consistent many web applications are
      designed to access IMAP directly and may need to have a semi-
      unique identifier available as part of the web based transaction.
      It is assumed that COOKIE encompasses the group of web based
      tokens known to persist from session to session.  A specific web
      based application can provide sufficient information in the actual
      client-identifier-token to differentiate between applications and
      or websites, and are convenient as they can be related to very
      specific domains, and are universally available to web application
      designers.

   As a reminder, an SMTP server SHOULD NOT retain and/or store the
   CLIENTID information WITH authentication credentials or
   authentication systems directly, but the SMTP service MAY associate
   the CLIENTID with a specific account holder, eg to create a history
   file of known CLIENTID tokens associated or permitted to access or
   present authentication credentials for that account holder.

Storey, et al.             Expires 1 June 2025                 [Page 11]
Internet-Draft            SMTP Client Identity             November 2024

7.  Examples

7.1.  UUID Address as Client Identity

      C: [connection established]
      S: 220 server.example.com ESMTP ready
      C: EHLO client.example.net
      S: 250-server.example.com
      S: 250-STARTTLS
      S: 250 AUTH LOGIN
      C: STARTTLS
      S: 220 Go ahead
      C: <starts TLS negotiation>
      C & S: <negotiate a TLS session>
      C & S: <check result of negotiation>
      C: EHLO client.example.net
      S: 250-server.example.com
      S: 250-AUTH LOGIN
      S: 250 CLIENTID
      C: CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f
      S: 250 OK
      C: AUTH LOGIN dGVzdAB0ZXN0ADEyMzQ=
      S: 235 Authentication successful
      C: MAIL FROM:<sender@example.net>
      S: 250 OK
      C: RCPT TO:<receiver@example.com>
      S: 250 OK
      C: DATA
      S: 354 Ready for message content
      C: <body>
      C: .
      S: 250 OK
      C: QUIT
      S: 221 server.example.com Service closing transmission channel

7.2.  Client Identity Without a TLS/SSL Session

      C: [connection established over a plaintext connection]
      S: 220 server.example.com ESMTP ready
      C: EHLO client.example.net
      S: 250-server.example.com
      S: 250 STARTTLS
      C: CLIENTID MAC 08:9e:01:70:f6:46
      S: 500 Syntax error, command unrecognised
      C: MAIL FROM:<sender@example.net>
      S: 250 OK
      C: QUIT
      S: 221 server.example.com Service closing transmission channel

Storey, et al.             Expires 1 June 2025                 [Page 12]
Internet-Draft            SMTP Client Identity             November 2024

   The server rejects use of the CLIENTID command as no TLS/SSL session
   was yet established.

7.3.  Client Identity Leading to Rejection

      C: [connection established over a plaintext connection]
      S: 220 server.example.com ESMTP ready
      C: EHLO client.example.net
      S: 250-server.example.com
      S: 250 STARTTLS
      C: STARTTLS
      S: 220 Go ahead
      C: <starts TLS negotiation>
      C & S: <negotiate a TLS session>
      C & S: <check result of negotiation>
      C: EHLO client.example.net
      S: 250-server.example.com
      S: 250 CLIENTID
      C: CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f
      S: 250 OK
      C: AUTH LOGIN dGVzdAB0ZXN0ADEyMzQ=
      S: 235 Authentication successful
      S: 550 Server policy does not permit your use of this mail system
      C: QUIT
      S: 221 server.example.com Service closing transmission channel

   The server rejects use of the mail system after deciding that the
   provided client identity does not establish sufficient privileges.

7.4.  Malformed CLIENTID Command

      C: [connection established over a plaintext connection]
      S: 220 server.example.com ESMTP ready
      C: EHLO client.example.net
      S: 250-server.example.com
      S: 250 STARTTLS
      C: STARTTLS
      S: 220 Go ahead
      C: <starts TLS negotiation>
      C & S: <negotiate a TLS session>
      C & S: <check result of negotiation>
      C: EHLO client.example.net
      S: 250-server.example.com
      S: 250 CLIENTID
      C: CLIENTID UUID
      S: 501 Syntax error in parameters or arguments
      C: QUIT
      S: 221 server.example.com Service closing transmission channel

Storey, et al.             Expires 1 June 2025                 [Page 13]
Internet-Draft            SMTP Client Identity             November 2024

   The server rejects the CLIENTID command as it is not well formed due
   to there being only a single parameter provided.

8.  IANA Considerations

   Section 2.2.2 of [SMTP] sets out the procedure for registering a new
   SMTP extension.  This extension will need to be registered.

9.  Security Considerations

   As this extension provides an additional means of communicating
   information from a client to a server, it is clear that there is
   additional information divulged to the server.  This may have privacy
   considerations depending on the client identity type or its contents.
   For example, it may reveal a MAC address of the device used to
   communicate with a server that would not previously have been
   revealed.  While it has been useful to use identifier such as email
   address for authentication, it is easy for these authentication
   tokens to be shared and/or reused and/or be publicly available for
   other purposes.  An SMTP server and/or its operators SHOULD NOT share
   any CLIENTID information presented with a third party as it may
   represent or be linked to an individual and SHOULD never be shared in
   association with authentication tokens.

   In essence, this provides a transparent method of two factor
   authentication requiring no modification to the SMTP resource of the
   client, where the traditional username and password along with any
   one of the unique identifiers can be used to identify a device you
   'own'.  However, great care should be taken by the client when
   deciding on the unique identifier to use and select one that cannot
   be easily discovered.  For example, one could use the MAC address but
   such an identifier may be elementary to discover and forged by
   another device.  While any compromise of a device MAY reveal the
   unique identifier, that problem is beyond the scope of the problem
   that this RFC is designed to solve.  Consider using a different
   unique identifier for each service to avoid having a compromised
   service expose identifiers that can then be used to access another
   service.

   Also, while this service extension requires that the identity
   information only be transmitted over an encrypted channel to reduce
   the risk of eavesdropping, it does not specify any policies or
   practices required in the establishment of such a channel, and so it
   is the responsibility of the client and the server to determine that
   the communication medium meets their requirements.

   An example of service specific device identifiers can be seen in the
   implementation of CLIENTID in the Thunderbird email client.  As well,

Storey, et al.             Expires 1 June 2025                 [Page 14]
Internet-Draft            SMTP Client Identity             November 2024

   while this service extension requires that the identity information
   only be transmitted over an encrypted channel to reduce the risk of
   eavesdropping, it does not specify any policies or practices required
   in the establishment of such a channel, and so it is the
   responsibility of the client and the server to determine that the
   communication medium meets their requirements.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [ABNF]     Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 5234, January 2008,
              <https://www.rfc-editor.org/rfc/rfc5234>.

   [AUTH]     Siemborski, R. and A. Melnikov, "SMTP Service Extension
              for Authentication", RFC 4954, July 2007,
              <https://www.rfc-editor.org/rfc/rfc4954>.

   [PIPELINING]
              Freed, N., "SMTP Service Extension for Command
              Pipelining", RFC 2920, September 2000,
              <https://www.rfc-editor.org/rfc/rfc2920>.

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008, <https://www.rfc-editor.org/rfc/rfc5321>.

   [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002,
              <https://www.rfc-editor.org/rfc/rfc3207>.

   [SUBMIT]   Gellens, R. and J. Klensin, "Message Submission for Mail",
              RFC 6409, November 2011,
              <https://www.rfc-editor.org/rfc/rfc6409>.

   [SASL]     Melnikov, A. and K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", RFC 4422, June 2006,
              <https://www.rfc-editor.org/rfc/rfc4422>.

Storey, et al.             Expires 1 June 2025                 [Page 15]
Internet-Draft            SMTP Client Identity             November 2024

Appendix A.  Appendix A.  CLIENTID Product Support

   Since publishing the SMTP Client Identity RFC draft, multiple email
   server and client vendors have implemented CLIENTID support into
   their products, e.g.  MailEnable, MagicMail, SaneBox, BlueMail,
   emClient, and Thunderbird.

   Given the current usage and adoption of CLIENTID in the public
   domain, this RFC should be considered for a Standards track.

Contributors

   Michael Peddemors
   LinuxMagic

Authors' Addresses

   William Storey (editor)
   LinuxMagic
   #405 - 860 Homer St.
   Vancouver British Columbia V6B 2W5
   Canada

   Email: william@linuxmagic.com

   Deion Yu (editor)
   LinuxMagic
   #405 - 860 Homer St.
   Vancouver British Columbia V6B 2W5
   Canada

   Email: deiony@linuxmagic.com

   Shaun Johnson (editor)
   LinuxMagic
   #405 - 860 Homer St.
   Vancouver British Columbia V6B 2W5
   Canada

   Email: shaun@linuxmagic.com

Storey, et al.             Expires 1 June 2025                 [Page 16]