idnits 2.17.1 draft-storey-smtp-client-id-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: As this extension provides an additional means of communicating information from a client to a server it is clear 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 authetication tokens to be shared and/or reused and/or be publically 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. -- The document date (June 1, 2021) is 1059 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'SASL' is mentioned on line 395, but not defined Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT W. Storey 3 LinuxMagic 4 Intended Status: Standards Track 5 Expires December 1, 2021 June 1, 2021 7 SMTP Service Extension for Client Identity 8 10 Abstract 12 This document defines an extension for the Simple Mail Transfer 13 Protocol (SMTP) called "CLIENTID" to provide a method for clients to 14 indicate an identity to the server. 16 This identity is an additional token that may be used for security 17 and/or informational purposes, and with it a server may optionally 18 apply heuristics using this token. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/1id-abstracts.html 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html 39 Copyright Notice 41 Copyright (c) 2016 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction ................................................. 3 57 2. The CLIENTID Service Extension ............................... 4 58 3. The CLIENTID Keyword of the EHLO Command ..................... 4 59 4. The CLIENTID Command ......................................... 4 60 5. Formal Syntax ................................................ 5 61 6. Discussion ................................................... 6 62 6.1. Applying heuristics to CLIENTID ......................... 6 63 6.2. Utility of CLIENTID ..................................... 6 64 6.3. Use Cases of CLIENTID ................................... 8 65 6.4. Other SMTP Client Identifiers ........................... 9 66 6.5. Future Considerations ................................... 9 67 7. Client Identity Types ........................................ 9 68 8. Examples ..................................................... 11 69 8.1 UUID Address as Client Identity .......................... 11 70 8.2 Client Identity Without a TLS/SSL Session ................ 12 71 8.3 Client Identity Leading to Rejection ..................... 12 72 8.4 Malformed CLIENTID Command ............................... 13 73 9. Security Considerations ...................................... 13 74 10. IANA Considerations .......................................... 13 75 10.1 SMTP Extension Registration ............................. 14 76 11. References ................................................... 14 77 11.1 Normative References .................................... 14 78 Appendix A. CLIENTID Product Support ............................ 14 79 Contributors ..................................................... 15 80 Authors' Addresses ............................................... 15 82 1. Introduction 84 The [SMTP] protocol and its extensions describe methods whereby an 85 SMTP client may provide identity and/or authentication information to 86 an SMTP server. However, these existing methods are subject to 87 limitations and none offer a way to identify the SMTP client with 88 absolute confidence. This document defines an SMTP service extension 89 to provide an additional identity token which can represent the SMTP 90 client with a higher degree of certainty when accessing the SMTP 91 server. 93 Typically SMTP clients are identified by establishing an authorized 94 connection using the [AUTH] SMTP extension. SMTP servers are often 95 subject to malicious clients attempting to use authorized identities 96 not intended for their use (often referred to as a brute-force 97 attack). When such an attack is attempted, the SMTP server may be 98 unable to identify the impersonation and restrict such an unintended 99 use by someone other than the authorized user of said credentials. 100 While there are ways to identify the source of the SMTP client such 101 as its IP address or EHLO identity, it would be useful if there was 102 an additional way to uniquely identify the client in a method solely 103 available across an encrypted channel. 105 Using the CLIENTID extension, an SMTP client can provide an 106 additional identity token to the server called its "client identity". 108 The client identity can provide unique characteristics about the 109 client accessing the SMTP service and may be combined with existing 110 identification mechanisms in order to identify the client. An SMTP 111 server may then apply additional security policies using this 112 identity such as restricting use of the service to clients presenting 113 recognized client identities, or only allowing use of authorized 114 identities that match previously established client identities. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in [KEYWORDS]. 120 2. The CLIENTID Service Extension 122 The following SMTP service extension is hereby defined: 124 1. The name of this [SMTP] service extension is "Client Identity". 126 2. The EHLO keyword value associated with this extension is 127 "CLIENTID". 129 3. The CLIENTID keyword has no parameters. 131 4. A new [SMTP] verb "CLIENTID" is defined. 133 5. No parameter is added to any SMTP command. 135 6. This extension is appropriate for the submission protocol 136 [SUBMIT]. 138 3. The CLIENTID Keyword of the EHLO Command 140 The CLIENTID keyword is used to tell the SMTP client that the SMTP 141 server supports the CLIENTID service extension. Though certain 142 conditions must be met before the CLIENTID keyword can be advertised. 144 1. An SMTP server MUST NOT advertise the CLIENTID keyword in any EHLO 145 responses if the CLIENTID extension support is not enabled. 147 2. An SMTP server MUST NOT advertise the CLIENTID keyword in any EHLO 148 response if the connection is not encrypted. 150 3. An SMTP server MUST advertise the CLIENTID keyword in all EHLO 151 responses after the connection is successfully encrypted (if 152 CLIENTID is supported). 154 4. The CLIENTID Command 156 The format for the CLIENTID command is: 158 CLIENTID client-id-type client-id-token 160 Arguments: 162 client-id-type: A string identifying the identity type the 163 client is providing. It MUST be between 1 and 16 characters 164 and comprised of only alphanumeric and dash characters. 166 client-id-token: A string identifying the client. It MUST 167 be between 1 and 128 printable characters. 169 Restrictions: 171 An SMTP client MUST NOT issue a CLIENTID command unless a 172 TLS/SSL session has been negotiated as described in [STARTTLS] 173 or through other means such as over a historical SMTP-SSL 174 connection. An SMTP server MUST reject any CLIENTID command 175 sent before establishing an encrypted connection with a 500 176 reply. 178 An SMTP client MUST only issue the CLIENTID command after the 179 SMTP server advertises the CLIENTID keyword via an EHLO 180 command. An SMTP server MUST reject a CLIENTID command prior 181 to advertsing the CLIENTID keyword via an EHLO command. 183 An SMTP server MUST reject any CLIENTID command that is not 184 well formatted with a 501 reply. 186 An SMTP client MUST NOT issue any subsequent CLIENTID commands 187 after a successful CLIENTID command in the same session. An 188 SMTP server MUST reject any subsequent CLIENTID commands after 189 a successful CLIENTID command in the same session with a 503 190 reply. 192 An SMTP client MUST issue any CLIENTID commands prior to 193 issuing an [AUTH] command. An SMTP server MUST reject any 194 CLIENTID command after receiving an [AUTH] command with a 503 195 reply. 197 Several SMTP service extensions such as [AUTH] require that an 198 SMTP session be reset to an initial state under conditions 199 such as after applying a security layer. An SMTP server MUST 200 discard any CLIENTID information after such a reset. 202 5. Formal Syntax 204 The following syntax specification uses the Augmented Backus-Naur 205 Form notation as specified in [ABNF]. Non-terminals referenced but 206 not defined below are as defined by [ABNF]. 208 Except as noted otherwise, all alphabetic characters are case- 209 insensitive. 211 client-id-type-char = ALPHA / DIGIT / "-" 212 ;; alphanumeric and dash character 214 client-id-type = 1*16 client-id-type-char 215 client-id-token = 1*128 VCHAR 216 ;; any printable US-ASCII character 218 6. Discussion 220 6.1 Applying heuristics to CLIENTID 222 This section discusses the possible heuristics that can be applied to 223 the information that is presented via the CLIENTID command. This 224 information includes whether a valid CLIENTID command was issued, the 225 client identity type and the client identity token. 227 1. An SMTP server MAY choose to require that a successful CLIENTID 228 command be issued, or that a particular client type be presented 229 before processing or accpeting an authentication request. 231 2. An SMTP server MAY reject any authentication request not preceded 232 with a client identity type that matches ACL's or rules as defined 233 in the SMTP server. 235 3. An SMTP server MAY reject any authentication request preceded by a 236 CLIENTID command that contains a client identity type or client 237 identity token that the server chooses not to accept for any 238 reason such as by policy. 240 4. An SMTP server MAY reject any authentication request preceded by a 241 CLIENTID command that contains a client identity type or client 242 identity token that the server has chosen to disable or revoke use 243 of either temporarily or permanently. 245 5. An SMTP server MAY reject any authentication request where the 246 provided client identity is not on the list of permitted clients 247 for the account holder. 249 The SMTP server SHOULD only ever reject an SMTP client based on 250 CLIENTID information during or after the authentication 251 process/handler. In the interest of limiting the amount of 252 information being revealed, the rejection message SHOULD be as 253 generic as possible and SHOULD NOT reveal any information on the 254 heuristics or rules on which it bases it's decisions. 256 Even if the client identity type and/or client identity token are not 257 recognized, supported or permitted by the server and/or the owner of 258 the authentication credentials, the presented information may still 259 be useful for analysis. 261 6.2 Utility of CLIENTID 263 Regardless of how frowned upon, users commonly reuse authorization 264 information (like the username and password pair) across multiple 265 services. When one service is compromised, malicious actors can also 266 gain access to other services where the user also used the same 267 credentials. Based on this representative problem alone, the utility 268 of CLIENTID as an additional layer of determining the rights to 269 present such authorization information becomes quickly apparent. 271 The utility of CLIENTID may be seen by considering the following: 273 1. An SMTP client may be present on a device that does not have a 274 useful domain name or network address, such as a mobile 275 device, so its EHLO identity may be ambiguous. 277 2. An SMTP client may utilize the same SMTP server with multiple 278 different authorized identities, so an identity that persists 279 across authorized identities is lacking. 281 3. An authorized identity may make use of multiple discrete 282 devices over different SMTP sessions, so an identity 283 persisting on one device is lacking. 285 4. The SMTP DATA payload does not need to be inspected for this 286 identity. 288 5. Connection information, a type of identity, such as network 289 address frequently changes. 291 However, this extends beyond just the restriction of authentication. 292 While it might be argued that this can be served as a special form of 293 SASL, by implementing this in the SMTP service itself, the SMTP 294 service can choose before allowing a connection to be passed to a 295 SASL implementation, allowing it to perform other heuristics, such as 296 identifying brute force attacks more effeciently. 298 The recent evolution of the internet as a whole has brought about 299 large scale data breaches, compromised botnets comprising of millions 300 of nodes, the transition to Carrier Grade NAT and the flourishing of 301 IoT devices means traditional methods of protecting against brute 302 force attacks have become much more difficult. Traditional methods 303 such as rate limiting and/or blocking access by IP are no longer 304 viable without introducing collateral effects, such as either 305 blocking legitimate user, or creating the conditions that allow DOS 306 (Denial of Service) to legitimate users. 308 Historically, SMTP and other services used what is technically a two 309 factor, the email/user and password, albeit not effective in that the 310 email is a KNOWN value. And with the propensity for users to use a 311 simple password, and the hundreds of millions of email addresses 312 exposed in data breaches, or available by other means the ability to 313 brute force is quite simple. While of course it is recommended that 314 users use longer and more secure passwords, this is not the de facto 315 situation, and the threats when credentials get compromised are 316 significant. And with 'botnet' operators able to engage millions of 317 IoT in a distributed brute force, the status quo is in danger. Adding 318 another non-public factor to be used as part of access control adds 319 a strength against brute force by many factors and accomplishes it in 320 a backwards compatible fashion, encouraging adoption. 322 Under brute force attacks, rate limiting or blocking by IP Address 323 was possible with little damage. But with the proliferaction of IoT 324 devices, smart phones, and the run-out of IP space, we have 325 conditions where thousands of devices could be behind an IP Address, 326 or IP(s) that are dynamic with devices changing IP(s) in minutes, 327 blocking or rate limiting an IP bears risks of blocking legitimate 328 users. By implementing a level of uniqueness to a connecting device, 329 it introduces the ability to restrict or block a subset from 330 connecting to the service for either brute force or dictionary 331 attacks, while still allowing other devices to continue to be able to 332 present authentication successfully. 334 While 'forgery' and/or the use of random client identifier is 335 possible, such behavior is also more readily detectable when a device 336 identifier is presented. 338 1. The SMTP server, when faced with hundreds of devices behind the 339 same IP address, during an attack can restrict authentication 340 attempts to only connections presenting a valid client identifier 341 token. 343 2. The SMTP server, during an attack, can restrict authentication to 344 only historically known devices. 346 3. The SMTP server can differentiate between many different devices 347 behind the same IP, and apply maximum connections per device, 348 rather than maximum connections per IP. 350 4. While a person may present authentication credentials from many 351 different geographical locations, eg, home, office, and travel, a 352 single device will not in general be able to be in two 353 geographical locations at the same time. The SMTP server will 354 have new information to apply to threat detection heuristics, ie 355 to treat the use of the same client identifier token from two 356 locations, as a possible brute force or forgery situation. 358 6.3 Use Cases of CLIENTID 360 The SMTP server may use the additional information from CLIENTID with 361 its interactions with SMTP clients in the following manner: 363 1. Restrict use of an authorized identity to a set of client 364 identities, thereby offering an added level of security. For 365 example, the use of an authorized identity may only be permitted 366 from a single device using the client identity as a form of 367 whitelisting. 369 2. Identify that the same client identity is used to access multiple 370 authorized identities and restrict access to the SMTP service. 371 For example, a client that has successfully gained access to many 372 authorized identities may be identified through its use of a 373 shared client identity. 375 3. Retain knowledge of client identities previously presented with an 376 authorized identity and if an identity not previously seen is used 377 restrict access to the SMTP service. 379 4. Require that the SMTP client present a token such as a license key 380 established outside of the SMTP session in order to make use of 381 any authorized identity; 383 5. Apply different security policies to clients that provide a client 384 identity versus those which do not. For example, provide clients 385 providing such an identity with additional trust. 387 6. Ability to rate limit or block based on the presented client 388 identifier token when multiple devices use a shared IP address 389 without affecting other devices. 391 7. Ability to detect distributed and localized dictionary attacks 392 and brute force attacks. 394 8. Use the client identifier token as a third factor to be passed 395 to authentication methods. [SASL] 397 6.4. Other SMTP Client Identifiers 399 The [SMTP] protocol and its extensions describe methods whereby an 400 SMTP client may provide identity information to an SMTP server. Some 401 of these identities are listed for contrast: 403 1. The client connection source provides an IP address associated 404 with the SMTP session. This may be accompanied by a PTR record 405 and/or GeoIP information. 407 2. The EHLO command allows a client to identify itself with a domain 408 or address for an SMTP session. 410 3. The [AUTH] SMTP extension allows the client to establish an 411 authorized identity for an SMTP session. 413 4. The MAIL command identifies a specific sender for a mail 414 transaction. 416 6.5. Future Considerations 418 In the future there may be a demand for being able to provide 419 multiple CLIENTID commands with different client identity types. 420 For instance, it may be desirable for a device to identify itself, 421 both with a hardware device identifier and a software identifier. 422 We believe this to be out of scope, and can be accomodated with a 423 special client identifier token which encapsulates both. 425 7. Client Identity Types 427 This document does not specify any CLIENTID identity type that MUST 428 be supported. The client identity type is meant to be defined by 429 the client implementation that is designed to access the SMTP server 430 and protocol. For instance, many SMTP client software implementations 431 already create a distinct UUID for each account. Some commercial 432 email clients have a license key. Some physical devices that need to 433 of client identity type that conforms to the definition, it is 434 interact with SMTP might have a unique hardware ID or MAC Address. 436 While there is no pre-defined list of client identity type defined by 437 this RFC, and all SMTP servers should be prepared to accept any form 438 suggested that SMTP client developers carefully consider the name of 439 the client identity type. For example, rather that using a 440 client identity type of UUID, consider the advantages of making it 441 more distinct, eg "UUID". This way the SMTP 442 server can better record histories, eg the difference between say 443 a Thunderbird generated unique id, and a Mutt generated unique id. 445 Some examples of identity type might be UUID, LICENSE, 446 DEVICE_ID, MAC and/or COOKIE. It is expected that the most common 447 types might be related to distinct UUID, LICENSEKEY, or HARDWAREID. 449 An SMTP server SHOULD NOT reject an unidentified CLIENTID type, 450 except for specific policy use cases. 452 It is envisioned that in the future it will be useful to propose 453 a set of standardized client-identity-type to help with validation, 454 or to allow the SMTP server to apply ACL rules on expected types, 455 this would be an extension to this RFC. 457 1. UUID 459 UUID is a common practice to represent either a individual user, 460 hardware device or software installation associated with a 461 specific individual. The support of UUID enables existing UUID 462 implementations to be used to semi-uniquely identify a device 463 associated with an individual. A definition of the format should 464 be considered. Otherwise non-standard UUID might be a separate 465 type specific to the software implementation, for instance 466 TBIRD-UUID. 468 2. LICENSE 470 An SMTP client may find it useful to identify the license key of 471 software it is using. Such licenses are typically crafted such 472 that they are unique and useful to identify a software 473 installation. This is more normally suited for a software 474 designed for a single-user. While LICENSE could be standard type 475 again, it might more more helpful to specify a vendor specific 476 type such as BBLICENSEKEY. 478 3. DEVICE_ID 480 Many hardware devices are designed to be used by a single 481 individual and already have an associated hardware device id. 482 While a standard type might be defined, it also might be more 483 helpful to use a vendor specific type, such as ATOM-DEVICEID. 485 4. MAC 487 The MAC address traditionally was used as a worldwide identifier 488 both of the unique device, as well as it's vendor and product 489 category, however this is not always the case anymore, in the case 490 of it's usage in 'virtual' devices. But for many hardware devices 491 which are required to access a defined SMTP resource, the MAC 492 address may still be a simple unique identifier. MAC should NOT 493 be used, unless this is a MAC address that can be associated to a 494 vendor using standard MAC registration information as defined or 495 set by the IEEE Standards Association and is meant to represent a 496 unique device. 498 5. COOKIE 500 While not guranteed to be consistent many web applications are 501 designed to access SMTP directly and may need to have a 502 semi-unique identifier available as part of the web based 503 transaction. It is assumed that COOKIE encompasses the group of 504 web based tokens known to persist from session to session. A 505 specific web based application can provide sufficient information 506 in the actual client-identifier-token to differentiate between 507 applications and or websites, and are convenient as they can be 508 related to very specific domains, and are universally available to 509 web application designers. 511 As a reminder, an SMTP server SHOULD NOT retain and/or store the 512 CLIENTID information WITH authentication credentials or 513 authentication systems directly, but the SMTP service MAY 514 associate the CLIENTID with a specific account holder, eg to create 515 a history file of known CLIENTID tokens associated or permitted to 516 access or present authentication credentials for that account holder. 518 This document recommends that a server associates a set of flags that 519 describes how the CLIENTID command should be handled for any given 520 client identity type. 522 1. Handled but treat as not presented (ignored, no persistance) 523 2. Store in SMTP session but treat as not presented (for debug) 524 3. Store in the SMTP session, so it is available to System log 525 4. Store in the SMTP session, so it is available to User log 526 5. Use for authentication 527 6. Use for alert when authentication fails 528 7. Use for alert when authentication succeeds 529 8. Unused 531 8. Examples 533 8.1 UUID Address as Client Identity 535 C: [connection established] 536 S: 220 server.example.com ESMTP ready 537 C: EHLO client.example.net 538 S: 250-server.example.com 539 S: 250-STARTTLS 540 S: 250 AUTH LOGIN 541 C: STARTTLS 542 S: 220 Go ahead 543 C: 544 C & S: 545 C & S: 546 C: EHLO client.example.net 547 S: 250-server.example.com 548 S: 250-AUTH LOGIN 549 S: 250 CLIENTID 550 C: CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 551 S: 250 OK 552 C: AUTH LOGIN dGVzdAB0ZXN0ADEyMzQ= 553 S: 235 Authentication successful 554 C: MAIL FROM: 555 S: 250 OK 556 C: RCPT TO: 557 S: 250 OK 558 C: DATA 559 S: 354 Ready for message content 560 C: 561 C: . 562 S: 250 OK 563 C: QUIT 564 S: 221 server.example.com Service closing transmission channel 566 8.2 Client Identity Without a TLS/SSL Session 568 C: [connection established over a plaintext connection] 569 S: 220 server.example.com ESMTP ready 570 C: EHLO client.example.net 571 S: 250-server.example.com 572 S: 250 STARTTLS 573 C: CLIENTID MAC 08:9e:01:70:f6:46 574 S: 500 Syntax error, command unrecognised 575 C: MAIL FROM: 576 S: 250 OK 577 C: QUIT 578 S: 221 server.example.com Service closing transmission channel 580 The server rejects use of the CLIENTID command as no TLS/SSL session 581 was yet established. 583 8.3 Client Identity Leading to Rejection 585 C: [connection established over a plaintext connection] 586 S: 220 server.example.com ESMTP ready 587 C: EHLO client.example.net 588 S: 250-server.example.com 589 S: 250 STARTTLS 590 C: STARTTLS 591 S: 220 Go ahead 592 C: 593 C & S: 594 C & S: 595 C: EHLO client.example.net 596 S: 250-server.example.com 597 S: 250 CLIENTID 598 C: CLIENTID MAC 08:9e:01:70:f6:46 599 S: 250 OK 600 C: AUTH LOGIN dGVzdAB0ZXN0ADEyMzQ= 601 S: 235 Authentication successful 602 S: 550 Server policy does not permit your use of this mail system 603 C: QUIT 604 S: 221 server.example.com Service closing transmission channel 606 The server rejects use of the mail system after deciding that the 607 provided client identity does not establish sufficient privileges. 609 8.4 Malformed CLIENTID Command 611 C: [connection established over a plaintext connection] 612 S: 220 server.example.com ESMTP ready 613 C: EHLO client.example.net 614 S: 250-server.example.com 615 S: 250 STARTTLS 616 C: STARTTLS 617 S: 220 Go ahead 618 C: 619 C & S: 620 C & S: 621 C: EHLO client.example.net 622 S: 250-server.example.com 623 S: 250 CLIENTID 624 C: CLIENTID MAC 625 S: 501 Syntax error in parameters or arguments 626 C: QUIT 627 S: 221 server.example.com Service closing transmission channel 629 The server rejects the CLIENTID command as it is not well formed due 630 to there being only a single parameter provided. 632 9. Security Considerations 634 As this extension provides an additional means of communicating 635 information from a client to a server it is clear there is additional 636 information divulged to the server. This may have privacy 637 considerations depending on the client identity type or its contents. 638 For example, it may reveal a MAC address of the device used to 639 communicate with a server that would not previously have been 640 revealed. While it has been useful to use identifier such as email 641 address for authentication it is easy for these authetication tokens 642 to be shared and/or reused and/or be publically available for other 643 purposes. An SMTP server and or its operators SHOULD not share 644 any CLIENTID information presented with a third party as it may 645 represent or be linked to an individual and SHOULD never be shared in 646 association with authentication tokens. 648 As well, while this service extension requires that the identity 649 information only be transmitted over an encrypted channel to reduce 650 the risk of eavesdropping, it does not specify any policies or 651 practices required in the establishment of such a channel, and so it 652 is the responsibility of the client and the server to determine that 653 the communication medium meets their requirements. 655 10. IANA Considerations 657 10.1 SMTP Extension Registration 659 Section 2.2.2 of [SMTP] sets out the procedure for registering a new 660 SMTP extension. 662 This extension will need to be registered. 664 11. References 666 11.1. Normative References 668 [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for 669 Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 670 10.17487/RFC5234, January 2008, . 673 [AUTH] Siemborski, R., Ed., and A. Melnikov, Ed., "SMTP Service 674 Extension for Authentication", RFC 4954, DOI 675 10.17487/RFC4954, July 2007, . 678 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, DOI 680 10.17487/RFC2119, March 1997, . 683 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 684 DOI 10.17487/RFC5321, October 2008, . 687 [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over 688 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 689 February 2002, . 691 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", 692 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 693 . 695 Appendix A. CLIENTID Product Support 697 Since publishing the SMTP Client Identity RFC draft, multiple email 698 server and client vendors have implemented CLIENTID support into 699 their products, e.g. MailEnable, MagicMail, SaneBox, BlueMail, 700 emClient, and Thunderbird. 702 Contributors 704 Michael Peddemors 705 LinuxMagic 707 Authors' Addresses 709 William Storey 710 LinuxMagic 711 #405 - 860 Homer St. 712 Vancouver, British Columbia 713 CA V6B 2W5 715 EMail: william@linuxmagic.com 717 Deion Yu 718 LinuxMagic 719 #405 - 860 Homer St. 720 Vancouver, British Columbia 721 CA V6B 2W5 723 EMail: deiony@linuxmagic.com