idnits 2.17.1 draft-storey-smtp-client-id-09.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 4, 2020) is 1393 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 392, 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 4, 2020 June 4, 2020 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 ......................................... 5 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 ................................... 7 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 .......................................... 14 75 10.1 SMTP Extension Registration ............................. 14 76 11. References ................................................... 14 77 11.1 Normative References .................................... 14 79 1. Introduction 81 The [SMTP] protocol and its extensions describe methods whereby an 82 SMTP client may provide identity and/or authentication information to 83 an SMTP server. However, these existing methods are subject to 84 limitations and none offer a way to identify the SMTP client with 85 absolute confidence. This document defines an SMTP service extension 86 to provide an additional identity token which can represent the SMTP 87 client with a higher degree of certainty when accessing the SMTP 88 server. 90 Typically SMTP clients are identified by establishing an authorized 91 connection using the [AUTH] SMTP extension. SMTP servers are often 92 subject to malicious clients attempting to use authorized identities 93 not intended for their use (often referred to as a brute-force 94 attack). When such an attack is attempted, the SMTP server may be 95 unable to identify the impersonation and restrict such an unintended 96 use by someone other than the authorized user of said credentials. 97 While there are ways to identify the source of the SMTP client such 98 as its IP address or EHLO identity, it would be useful if there was 99 an additional way to uniquely identify the client in a method solely 100 available across an encrypted channel. 102 Using the CLIENTID extension, an SMTP client can provide an 103 additional identity token to the server called its "client identity". 104 The client identity can provide unique characteristics about the 105 client accessing the SMTP service and may be combined with existing 106 identification mechanisms in order to identify the client. An SMTP 107 server may then apply additional security policies using this 108 identity such as restricting use of the service to clients presenting 109 recognized client identities, or only allowing use of authorized 110 identities that match previously established client identities. 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [KEYWORDS]. 116 2. The CLIENTID Service Extension 118 The following SMTP service extension is hereby defined: 120 1. The name of this [SMTP] service extension is "Client Identity". 122 2. The EHLO keyword value associated with this extension is 123 "CLIENTID". 125 3. The CLIENTID keyword has no parameters. 127 4. A new [SMTP] verb "CLIENTID" is defined. 129 5. No parameter is added to any SMTP command. 131 6. This extension is appropriate for the submission protocol 132 [SUBMIT]. 134 3. The CLIENTID Keyword of the EHLO Command 136 The CLIENTID keyword is used to tell the SMTP client that the SMTP 137 server supports the CLIENTID service extension. Though certain 138 conditions must be met before the CLIENTID keyword can be advertised. 140 1. An SMTP server MUST NOT advertise the CLIENTID keyword in any EHLO 141 responses if the CLIENTID extension support is not enabled. 143 2. An SMTP server MUST NOT advertise the CLIENTID keyword in any EHLO 144 response if the connection is not encrypted. 146 3. An SMTP server MUST advertise the CLIENTID keyword in all EHLO 147 responses after the connection is successfully encrypted (if 148 CLIENTID is supported). 150 4. The CLIENTID Command 152 The format for the CLIENTID command is: 154 CLIENTID client-id-type client-id-token 156 Arguments: 158 client-id-type: A string identifying the identity type the 159 client is providing. It MUST be between 1 and 16 characters 160 and comprised of only alphanumeric and dash characters. 162 client-id-token: A string identifying the client. It MUST 163 be between 1 and 128 printable characters. 165 Restrictions: 167 An SMTP client MUST NOT issue a CLIENTID command unless a 168 TLS/SSL session has been negotiated as described in [STARTTLS] 169 or through other means such as over a historical SMTP-SSL 170 connection. An SMTP server MUST reject any CLIENTID command 171 sent before establishing an encrypted connection with a 500 172 reply. 174 An SMTP client MUST only issue the CLIENTID command after the 175 SMTP server advertises the CLIENTID keyword via an EHLO 176 command. An SMTP server MUST reject a CLIENTID command prior 177 to advertsing the CLIENTID keyword via an EHLO command. 179 An SMTP server MUST reject any CLIENTID command that is not 180 well formatted with a 501 reply. 182 An SMTP client MUST NOT issue any subsequent CLIENTID commands 183 after a successful CLIENTID command in the same session. An 184 SMTP server MUST reject any subsequent CLIENTID commands after 185 a successful CLIENTID command in the same session with a 503 186 reply. 188 An SMTP client MUST issue any CLIENTID commands prior to 189 issuing an [AUTH] command. An SMTP server MUST reject any 190 CLIENTID command after receiving an [AUTH] command with a 503 191 reply. 193 Several SMTP service extensions such as [AUTH] require that an 194 SMTP session be reset to an initial state under conditions 195 such as after applying a security layer. An SMTP server MUST 196 discard any CLIENTID information after such a reset. 198 5. Formal Syntax 200 The following syntax specification uses the Augmented Backus-Naur 201 Form notation as specified in [ABNF]. Non-terminals referenced but 202 not defined below are as defined by [ABNF]. 204 Except as noted otherwise, all alphabetic characters are case- 205 insensitive. 207 client-id-type-char = ALPHA / DIGIT / "-" 208 ;; alphanumeric and dash character 210 client-id-type = 1*16 client-id-type-char 212 client-id-token = 1*128 VCHAR 213 ;; any printable US-ASCII character 215 6. Discussion 217 6.1 Applying heuristics to CLIENTID 219 This section discusses the possible heuristics that can be applied to 220 the information that is presented via the CLIENTID command. This 221 information includes whether a valid CLIENTID command was issued, the 222 client identity type and the client identity token. 224 1. An SMTP server MAY choose to require that a successful CLIENTID 225 command be issued, or that a particular client type be presented 226 before processing or accpeting an authentication request. 228 2. An SMTP server MAY reject any authentication request not preceded 229 with a client identity type that matches ACL's or rules as defined 230 in the SMTP server. 232 3. An SMTP server MAY reject any authentication request preceded by a 233 CLIENTID command that contains a client identity type or client 234 identity token that the server chooses not to accept for any 235 reason such as by policy. 237 4. An SMTP server MAY reject any authentication request preceded by a 238 CLIENTID command that contains a client identity type or client 239 identity token that the server has chosen to disable or revoke use 240 of either temporarily or permanently. 242 5. An SMTP server MAY reject any authentication request where the 243 provided client identity is not on the list of permitted clients 244 for the account holder. 246 The SMTP server SHOULD only ever reject an SMTP client based on 247 CLIENTID information during or after the authentication 248 process/handler. In the interest of limiting the amount of 249 information being revealed, the rejection message SHOULD be as 250 generic as possible and SHOULD NOT reveal any information on the 251 heuristics or rules on which it bases it's decisions. 253 Even if the client identity type and/or client identity token are not 254 recognized, supported or permitted by the server and/or the owner of 255 the authentication credentials, the presented information may still 256 be useful for analysis. 258 6.2 Utility of CLIENTID 260 Regardless of how frowned upon, users commonly reuse authorization 261 information (like the username and password pair) across multiple 262 services. When one service is compromised, malicious actors can also 263 gain access to other services where the user also used the same 264 credentials. Based on this representative problem alone, the utility 265 of CLIENTID as an additional layer of determining the rights to 266 present such authorization information becomes quickly apparent. 268 The utility of CLIENTID may be seen by considering the following: 270 1. An SMTP client may be present on a device that does not have a 271 useful domain name or network address, such as a mobile 272 device, so its EHLO identity may be ambiguous. 274 2. An SMTP client may utilize the same SMTP server with multiple 275 different authorized identities, so an identity that persists 276 across authorized identities is lacking. 278 3. An authorized identity may make use of multiple discrete 279 devices over different SMTP sessions, so an identity 280 persisting on one device is lacking. 282 4. The SMTP DATA payload does not need to be inspected for this 283 identity. 285 5. Connection information, a type of identity, such as network 286 address frequently changes. 288 However, this extends beyond just the restriction of authentication. 289 While it might be argued that this can be served as a special form of 290 SASL, by implementing this in the SMTP service itself, the SMTP 291 service can choose before allowing a connection to be passed to a 292 SASL implementation, allowing it to perform other heuristics, such as 293 identifying brute force attacks more effeciently. 295 The recent evolution of the internet as a whole has brought about 296 large scale data breaches, compromised botnets comprising of millions 297 of nodes, the transition to Carrier Grade NAT and the flourishing of 298 IoT devices means traditional methods of protecting against brute 299 force attacks have become much more difficult. Traditional methods 300 such as rate limiting and/or blocking access by IP are no longer 301 viable without introducing collateral effects, such as either 302 blocking legitimate user, or creating the conditions that allow DOS 303 (Denial of Service) to legitimate users. 305 Historically, SMTP and other services used what is technically a two 306 factor, the email/user and password, albeit not effective in that the 307 email is a KNOWN value. And with the propensity for users to use a 308 simple password, and the hundreds of millions of email addresses 309 exposed in data breaches, or available by other means the ability to 310 brute force is quite simple. While of course it is recommended that 311 users use longer and more secure passwords, this is not the de facto 312 situation, and the threats when credentials get compromised are 313 significant. And with 'botnet' operators able to engage millions of 314 IoT in a distributed brute force, the status quo is in danger. Adding 315 another non-public factor to be used as part of access control adds 316 a strength against brute force by many factors and accomplishes it in 317 a backwards compatible fashion, encouraging adoption. 319 Under brute force attacks, rate limiting or blocking by IP Address 320 was possible with little damage. But with the proliferaction of IoT 321 devices, smart phones, and the run-out of IP space, we have 322 conditions where thousands of devices could be behind an IP Address, 323 or IP(s) that are dynamic with devices changing IP(s) in minutes, 324 blocking or rate limiting an IP bears risks of blocking legitimate 325 users. By implementing a level of uniqueness to a connecting device, 326 it introduces the ability to restrict or block a subset from 327 connecting to the service for either brute force or dictionary 328 attacks, while still allowing other devices to continue to be able to 329 present authentication successfully. 331 While 'forgery' and/or the use of random client identifier is 332 possible, such behavior is also more readily detectable when a device 333 identifier is presented. 335 1. The SMTP server, when faced with hundreds of devices behind the 336 same IP address, during an attack can restrict authentication 337 attempts to only connections presenting a valid client identifier 338 token. 340 2. The SMTP server, during an attack, can restrict authentication to 341 only historically known devices. 343 3. The SMTP server can differentiate between many different devices 344 behind the same IP, and apply maximum connections per device, 345 rather than maximum connections per IP. 347 4. While a person may present authentication credentials from many 348 different geographical locations, eg, home, office, and travel, a 349 single device will not in general be able to be in two 350 geographical locations at the same time. The SMTP server will 351 have new information to apply to threat detection heuristics, ie 352 to treat the use of the same client identifier token from two 353 locations, as a possible brute force or forgery situation. 355 6.3 Use Cases of CLIENTID 357 The SMTP server may use the additional information from CLIENTID with 358 its interactions with SMTP clients in the following manner: 360 1. Restrict use of an authorized identity to a set of client 361 identities, thereby offering an added level of security. For 362 example, the use of an authorized identity may only be permitted 363 from a single device using the client identity as a form of 364 whitelisting. 366 2. Identify that the same client identity is used to access multiple 367 authorized identities and restrict access to the SMTP service. 368 For example, a client that has successfully gained access to many 369 authorized identities may be identified through its use of a 370 shared client identity. 372 3. Retain knowledge of client identities previously presented with an 373 authorized identity and if an identity not previously seen is used 374 restrict access to the SMTP service. 376 4. Require that the SMTP client present a token such as a license key 377 established outside of the SMTP session in order to make use of 378 any authorized identity; 380 5. Apply different security policies to clients that provide a client 381 identity versus those which do not. For example, provide clients 382 providing such an identity with additional trust. 384 6. Ability to rate limit or block based on the presented client 385 identifier token when multiple devices use a shared IP address 386 without affecting other devices. 388 7. Ability to detect distributed and localized dictionary attacks 389 and brute force attacks. 391 8. Use the client identifier token as a third factor to be passed 392 to authentication methods. [SASL] 394 6.4. Other SMTP Client Identifiers 396 The [SMTP] protocol and its extensions describe methods whereby an 397 SMTP client may provide identity information to an SMTP server. Some 398 of these identities are listed for contrast: 400 1. The client connection source provides an IP address associated 401 with the SMTP session. This may be accompanied by a PTR record 402 and/or GeoIP information. 404 2. The EHLO command allows a client to identify itself with a domain 405 or address for an SMTP session. 407 3. The [AUTH] SMTP extension allows the client to establish an 408 authorized identity for an SMTP session. 410 4. The MAIL command identifies a specific sender for a mail 411 transaction. 413 6.5. Future Considerations 415 In the future there may be a demand for being able to provide 416 multiple CLIENTID commands with different client identity types. 417 For instance, it may be desirable for a device to identify itself, 418 both with a hardware device identifier and a software identifier. 419 We believe this to be out of scope, and can be accomodated with a 420 special client identifier token which encapsulates both. 422 7. Client Identity Types 424 This document does not specify any CLIENTID identity type that MUST 425 be supported. The client identity type is meant to be defined by 426 the client implementation that is designed to access the SMTP server 427 and protocol. For instance, many SMTP client software implementations 428 already create a distinct UUID for each account. Some commercial 429 email clients have a license key. Some physical devices that need to 430 of client identity type that conforms to the definition, it is 431 interact with SMTP might have a unique hardware ID or MAC Address. 433 While there is no pre-defined list of client identity type defined by 434 this RFC, and all SMTP servers should be prepared to accept any form 435 suggested that SMTP client developers carefully consider the name of 436 the client identity type. For example, rather that using a 437 client identity type of UUID, consider the advantages of making it 438 more distinct, eg "UUID". This way the SMTP 439 server can better record histories, eg the difference between say 440 a Thunderbird generated unique id, and a Mutt generated unique id. 442 Some examples of identity type might be UUID, LICENSE, 443 DEVICE_ID, MAC and/or COOKIE. It is expected that the most common 444 types might be related to distinct UUID, LICENSEKEY, or HARDWAREID. 446 An SMTP server SHOULD NOT reject an unidentified CLIENTID type, 447 except for specific policy use cases. 449 It is envisioned that in the future it will be useful to propose 450 a set of standardized client-identity-type to help with validation, 451 or to allow the SMTP server to apply ACL rules on expected types, 452 this would be an extension to this RFC. 454 1. UUID 456 UUID is a common practice to represent either a individual user, 457 hardware device or software installation associated with a 458 specific individual. The support of UUID enables existing UUID 459 implementations to be used to semi-uniquely identify a device 460 associated with an individual. A definition of the format should 461 be considered. Otherwise non-standard UUID might be a separate 462 type specific to the software implementation, for instance 463 TBIRD-UUID. 465 2. LICENSE 467 An SMTP client may find it useful to identify the license key of 468 software it is using. Such licenses are typically crafted such 469 that they are unique and useful to identify a software 470 installation. This is more normally suited for a software 471 designed for a single-user. While LICENSE could be standard type 472 again, it might more more helpful to specify a vendor specific 473 type such as BBLICENSEKEY. 475 3. DEVICE_ID 477 Many hardware devices are designed to be used by a single 478 individual and already have an associated hardware device id. 479 While a standard type might be defined, it also might be more 480 helpful to use a vendor specific type, such as ATOM-DEVICEID. 482 4. MAC 484 The MAC address traditionally was used as a worldwide identifier 485 both of the unique device, as well as it's vendor and product 486 category, however this is not always the case anymore, in the case 487 of it's usage in 'virtual' devices. But for many hardware devices 488 which are required to access a defined SMTP resource, the MAC 489 address may still be a simple unique identifier. MAC should NOT 490 be used, unless this is a MAC address that can be associated to a 491 vendor using standard MAC registration information as defined or 492 set by the IEEE Standards Association and is meant to represent a 493 unique device. 495 5. COOKIE 497 While not guranteed to be consistent many web applications are 498 designed to access SMTP directly and may need to have a 499 semi-unique identifier available as part of the web based 500 transaction. It is assumed that COOKIE encompasses the group of 501 web based tokens known to persist from session to session. A 502 specific web based application can provide sufficient information 503 in the actual client-identifier-token to differentiate between 504 applications and or websites, and are convenient as they can be 505 related to very specific domains, and are universally available to 506 web application designers. 508 As a reminder, an SMTP server SHOULD NOT retain and/or store the 509 CLIENTID information WITH authentication credentials or 510 authentication systems directly, but the SMTP service MAY 511 associate the CLIENTID with a specific account holder, eg to create 512 a history file of known CLIENTID tokens associated or permitted to 513 access or present authentication credentials for that account holder. 515 This document recommends that a server associates a set of flags that 516 describes how the CLIENTID command should be handled for any given 517 client identity type. 519 1. Handled but treat as not presented (ignored, no persistance) 520 2. Store in SMTP session but treat as not presented (for debug) 521 3. Store in the SMTP session, so it is available to System log 522 4. Store in the SMTP session, so it is available to User log 523 5. Use for authentication 524 6. Use for alert when authentication fails 525 7. Use for alert when authentication succeeds 526 8. Unused 528 8. Examples 530 8.1 UUID Address as Client Identity 532 C: [connection established] 533 S: 220 server.example.com ESMTP ready 534 C: EHLO client.example.net 535 S: 250-server.example.com 536 S: 250-STARTTLS 537 S: 250 AUTH LOGIN 538 C: STARTTLS 539 S: 220 Go ahead 540 C: 541 C & S: 542 C & S: 543 C: EHLO client.example.net 544 S: 250-server.example.com 545 S: 250-AUTH LOGIN 546 S: 250 CLIENTID 547 C: CLIENTID UUID 23bf83be-aad7-46aa-9e0f-39191ccf402f 548 S: 250 OK 549 C: AUTH LOGIN dGVzdAB0ZXN0ADEyMzQ= 550 S: 235 Authentication successful 551 C: MAIL FROM: 552 S: 250 OK 553 C: RCPT TO: 554 S: 250 OK 555 C: DATA 556 S: 354 Ready for message content 557 C: 558 C: . 559 S: 250 OK 560 C: QUIT 561 S: 221 server.example.com Service closing transmission channel 563 8.2 Client Identity Without a TLS/SSL Session 565 C: [connection established over a plaintext connection] 566 S: 220 server.example.com ESMTP ready 567 C: EHLO client.example.net 568 S: 250-server.example.com 569 S: 250 STARTTLS 570 C: CLIENTID MAC 08:9e:01:70:f6:46 571 S: 500 Syntax error, command unrecognised 572 C: MAIL FROM: 573 S: 250 OK 574 C: QUIT 575 S: 221 server.example.com Service closing transmission channel 577 The server rejects use of the CLIENTID command as no TLS/SSL session 578 was yet established. 580 8.3 Client Identity Leading to Rejection 582 C: [connection established over a plaintext connection] 583 S: 220 server.example.com ESMTP ready 584 C: EHLO client.example.net 585 S: 250-server.example.com 586 S: 250 STARTTLS 587 C: STARTTLS 588 S: 220 Go ahead 589 C: 590 C & S: 591 C & S: 592 C: EHLO client.example.net 593 S: 250-server.example.com 594 S: 250 CLIENTID 595 C: CLIENTID MAC 08:9e:01:70:f6:46 596 S: 250 OK 597 C: AUTH LOGIN dGVzdAB0ZXN0ADEyMzQ= 598 S: 235 Authentication successful 599 S: 550 Server policy does not permit your use of this mail system 600 C: QUIT 601 S: 221 server.example.com Service closing transmission channel 603 The server rejects use of the mail system after deciding that the 604 provided client identity does not establish sufficient privileges. 606 8.4 Malformed CLIENTID Command 608 C: [connection established over a plaintext connection] 609 S: 220 server.example.com ESMTP ready 610 C: EHLO client.example.net 611 S: 250-server.example.com 612 S: 250 STARTTLS 613 C: STARTTLS 614 S: 220 Go ahead 615 C: 616 C & S: 617 C & S: 618 C: EHLO client.example.net 619 S: 250-server.example.com 620 S: 250 CLIENTID 621 C: CLIENTID MAC 622 S: 501 Syntax error in parameters or arguments 623 C: QUIT 624 S: 221 server.example.com Service closing transmission channel 626 The server rejects the CLIENTID command as it is not well formed due 627 to there being only a single parameter provided. 629 9. Security Considerations 631 As this extension provides an additional means of communicating 632 information from a client to a server it is clear there is additional 633 information divulged to the server. This may have privacy 634 considerations depending on the client identity type or its contents. 635 For example, it may reveal a MAC address of the device used to 636 communicate with a server that would not previously have been 637 revealed. While it has been useful to use identifier such as email 638 address for authentication it is easy for these authetication tokens 639 to be shared and/or reused and/or be publically available for other 640 purposes. An SMTP server and or its operators SHOULD not share 641 any CLIENTID information presented with a third party as it may 642 represent or be linked to an individual and SHOULD never be shared in 643 association with authentication tokens. 645 As well, while this service extension requires that the identity 646 information only be transmitted over an encrypted channel to reduce 647 the risk of eavesdropping, it does not specify any policies or 648 practices required in the establishment of such a channel, and so it 649 is the responsibility of the client and the server to determine that 650 the communication medium meets their requirements. 652 10. IANA Considerations 654 10.1 SMTP Extension Registration 656 Section 2.2.2 of [SMTP] sets out the procedure for registering a new 657 SMTP extension. 659 This extension will need to be registered. 661 11. References 663 11.1. Normative References 665 [ABNF] Crocker, D., Ed., and P. Overell, "Augmented BNF for 666 Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 667 10.17487/RFC5234, January 2008, . 670 [AUTH] Siemborski, R., Ed., and A. Melnikov, Ed., "SMTP Service 671 Extension for Authentication", RFC 4954, DOI 672 10.17487/RFC4954, July 2007, . 675 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, DOI 677 10.17487/RFC2119, March 1997, . 680 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 681 DOI 10.17487/RFC5321, October 2008, . 684 [STARTTLS] Hoffman, P., "SMTP Service Extension for Secure SMTP over 685 Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, 686 February 2002, . 688 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission for Mail", 689 STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, 690 . 692 Contributors 694 Michael Peddemors 695 LinuxMagic 697 Authors' Addresses 699 William Storey 700 LinuxMagic 701 #405 - 860 Homer St. 702 Vancouver, British Columbia 703 CA V6B 2W5 705 EMail: william@linuxmagic.com 707 Deion Yu 708 LinuxMagic 709 #405 - 860 Homer St. 710 Vancouver, British Columbia 711 CA V6B 2W5 713 EMail: deiony@linuxmagic.com