idnits 2.17.1 draft-vesely-vhlo-06.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 == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (June 16, 2010) is 5062 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 4408 (Obsoleted by RFC 7208) -- Obsolete informational reference (is this intentional?): RFC 4409 (Obsoleted by RFC 6409) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5672 (Obsoleted by RFC 6376) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Vesely 3 Internet-Draft June 16, 2010 4 Intended status: Standards Track 5 Expires: December 18, 2010 7 Verified Hello SMTP extension 8 draft-vesely-vhlo-06 10 Abstract 12 Verified Hello (VHLO) is an SMTP extension for managing authorization 13 by policy, as done for whitelisting messages. The VHLO command verb 14 provides for weak authentication of SMTP clients and policy 15 negotiation. 17 Policies and reputation are being increasingly used to identify 18 messages worthiness. However, they are currently enforced by 19 rejecting SMTP transactions, or discarding messages. Feedback is 20 scarce, also because reply codes are difficult to interpret 21 automatically. Negotiation is not provided for. VHLO is designed so 22 that servers can provide feedback to their clients about which 23 vouching services or authentication methods they require. 24 Credentials can also be negotiated on the fly, in order to allow 25 clients to learn whether messages will be whitelisted by the 26 receiving server before actually transmitting them. Negotiation and 27 feedback are intended to ease rapid diffusion of popular reputation 28 systems and authentication methods. A IANA register is defined for 29 extending the set of available methods. 31 The VHLO command is similar to EHLO, but accepts a series of 32 parameters. The sender communicates the mail domain name of the 33 organization on whose behalf it operates, along with any vouching 34 services (VBR) for its reputation. On the other hand, the sending 35 host's affiliation with that mail domain is checked by DNS lookups 36 (MX, PTR, or SPF) or using DKIM. DNSBLs and Greylisting are also 37 considered. 39 Weakly authenticated clients enjoy an intermediate level of trust: 40 they have no relying privileges, but may attempt to deliver mail to 41 local users, are whitelisted from some filters, and may receive DSNs 42 and feedback-loop abuse reports as needed. However, failing to 43 succesfully negotiate VHLO authentication does not preclude a 44 client's ability to relay mail: It may relay as usual; that is to 45 say, without knowing whether the credentials it tries to provide have 46 any meaning for the receiving server. 48 Status of this Memo 49 This Internet-Draft is submitted in full conformance with the 50 provisions of BCP 78 and BCP 79. 52 Internet-Drafts are working documents of the Internet Engineering 53 Task Force (IETF). Note that other groups may also distribute 54 working documents as Internet-Drafts. The list of current Internet- 55 Drafts is at http://datatracker.ietf.org/drafts/current/. 57 Internet-Drafts are draft documents valid for a maximum of six months 58 and may be updated, replaced, or obsoleted by other documents at any 59 time. It is inappropriate to use Internet-Drafts as reference 60 material or to cite them other than as "work in progress." 62 This Internet-Draft will expire on December 18, 2010. 64 Copyright Notice 66 Copyright (c) 2010 IETF Trust and the persons identified as the 67 document authors. All rights reserved. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents 73 carefully, as they describe your rights and restrictions with respect 74 to this document. Code Components extracted from this document must 75 include Simplified BSD License text as described in Section 4.e of 76 the Trust Legal Provisions and are provided without warranty as 77 described in the Simplified BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 1.1. Prime delivery . . . . . . . . . . . . . . . . . . . . . . 4 83 1.2. Domains as branding . . . . . . . . . . . . . . . . . . . 5 84 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 85 2. Definition and Registration of the VHLO Extension . . . . . . 5 86 3. Behavior of SMTP client and server . . . . . . . . . . . . . . 6 87 3.1. Syntax of the VHLO command . . . . . . . . . . . . . . . . 7 88 3.2. Server side checks on the Domain . . . . . . . . . . . . . 8 89 3.2.1. Greylisting check . . . . . . . . . . . . . . . . . . 8 90 3.2.2. DNSBL check . . . . . . . . . . . . . . . . . . . . . 9 91 3.2.3. SPF check . . . . . . . . . . . . . . . . . . . . . . 9 92 3.2.4. MX check . . . . . . . . . . . . . . . . . . . . . . . 9 93 3.2.5. PTR and 'iprev' checks . . . . . . . . . . . . . . . . 9 94 3.2.6. VBR check . . . . . . . . . . . . . . . . . . . . . . 10 95 3.2.7. DKIM check . . . . . . . . . . . . . . . . . . . . . . 11 96 3.3. Responses to the VHLO command . . . . . . . . . . . . . . 12 97 3.3.1. Overview of possible responses . . . . . . . . . . . . 12 98 3.3.2. Positive response . . . . . . . . . . . . . . . . . . 13 99 3.3.2.1. VHLO parameter and MAIL FROM command . . . . . . . 13 100 3.3.3. Transient error responses . . . . . . . . . . . . . . 13 101 3.3.4. Negative responses . . . . . . . . . . . . . . . . . . 14 102 3.3.5. Diagnosis of failed VHLO commands . . . . . . . . . . 14 103 3.4. Restrictions and further server side checks . . . . . . . 15 104 3.4.1. MAIL FROM restriction . . . . . . . . . . . . . . . . 16 105 3.4.2. VBR restriction . . . . . . . . . . . . . . . . . . . 16 106 3.4.3. DKIM-Signature headers existence and verification . . 16 107 3.4.4. Greylisting restrictions . . . . . . . . . . . . . . . 17 108 4. Forwarding of messages accepted under VHLO . . . . . . . . . . 17 109 5. Submission strategy . . . . . . . . . . . . . . . . . . . . . 18 110 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 111 6.1. IANA Mail Parameters . . . . . . . . . . . . . . . . . . . 19 112 6.2. IANA VHLO methods . . . . . . . . . . . . . . . . . . . . 19 113 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 114 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 115 8.1. Normative References . . . . . . . . . . . . . . . . . . . 22 116 8.2. Informative References . . . . . . . . . . . . . . . . . . 22 117 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 23 118 A.1. Prime delivery message transfer . . . . . . . . . . . . . 23 119 A.2. Failure after DNSBL check . . . . . . . . . . . . . . . . 24 120 A.3. Failure on the MAIL FROM restriction check . . . . . . . . 24 121 A.4. Automatically finding a common vouching service . . . . . 24 122 A.5. Reattempting Greylisted transmission . . . . . . . . . . . 25 123 A.6. Mandating DKIM usage . . . . . . . . . . . . . . . . . . . 25 124 A.7. Requiring extra DKIM tags . . . . . . . . . . . . . . . . 26 125 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 127 1. Introduction 129 The SMTP extension defined by this memo provides a VHLO command verb 130 that takes a registered domain name, instead of the client identity 131 taken by EHLO. The declared Domain identifies the organization that 132 is responsible for sending the messages. Two kinds of verifications 133 are required to validate the VHLO command: 135 the Domain is trustworthy, and 137 the SMTP client is affiliated with the Domain. 139 Not all mail messages are amenable to be transmitted in the framework 140 of a VHLO command, only those transmitted on behalf of the weakly 141 authenticated Domain. If weak authentication succeeds, the client 142 can transmit messages that will enjoy prime delivery (Section 1.1). 143 If it fails, the client is told what requirements it misses, so that 144 its administrators know exactly what to do in order to gain 145 acceptance. Such feedback is deemed necessary and sufficient for 146 triggering widespread deployment of domain whitelists, a.k.a. RHSWL 147 (right hand side whitelists), as discussed below (Section 1.2). 149 1.1. Prime delivery 151 The term "prime delivery" is used to indicate that a message is not 152 tagged as spam, quarantined, silently dropped, or delivered to junk 153 folders. Here, a junk folder is one from where unread messages are 154 normally deleted, or moved to another junk folder, without human 155 intervention. In addition, prime delivery implies that messages are 156 not altered in such a way as to make them less visible or discourage 157 users from displaying their content. 159 In case the message has to be forwarded to another internal or 160 external server, its transmission SHOULD attempt to preserve the 161 trust and reputation that was granted on acceptance, as detailed in 162 Section 4, always reporting failure to relay. 164 End users may operate their own content filtering. They can do so 165 within their clients, or setting up their own filtering recipes 166 within per-user sections of the Mail Delivery Agent configuration. 167 Prime delivery only concerns stock filters that operate for all 168 users. In case users can configure their mailboxes by making on/off 169 decisions about specific content filters, implementing prime delivery 170 involves dynamically turning off the relevant filters. For the sake 171 of reliability, the delivery agent SHOULD ensure that prime delivery 172 is consistently flagged by Authentication Status [RFC5451] headers, 173 and known IMAP keywords. Administrators should educate their users 174 on how to appropriately whitelist messages flagged that way. 176 1.2. Domains as branding 178 DNS domain names can be used as a brand, and reputation records based 179 on them last longer than those based on IP addresses. While a domain 180 is not formally required for sending email messages, Verified Hello 181 provides for a framework where only messages sent on behalf of an 182 authenticated domain are accepted. In this respect, this extension 183 is only useful for relaying messages across domain boundaries, which 184 typically happens after Message Submission [RFC4409]. 186 1.3. Requirements Language 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [RFC2119]. 192 2. Definition and Registration of the VHLO Extension 194 According to [RFC5321] provisions, the definition for this extension 195 goes as follows: 197 o the textual name of this extension is "Verified Hello"; 199 o the EHLO keyword associated with the extension is "VHLO"; 201 o the parameter associated with the EHLO keyword is a random value 202 up to 16 octets long (see Section 3.3.2.1); 204 o this extension defines one additional verb, VHLO, whose only 205 mandatory parameter is the Domain name of the sender, possibly 206 followed by one parameter for each reputation tag (see 207 Section 3.1); 209 o VHLO is also defined as one additional parameter to the MAIL verb 210 (see Section 3.3.2.1), no parameters are defined for the RCPT 211 verb; 213 o supporting the extension affects the behavior of a server and 214 client SMTP as described in Section 3; and 216 o the maximum length of the MAIL command is increased by 22 octets, 217 while the RCPT command is not affected. 219 Finally, as required by [RFC4409], this extension is NOT RECOMMENDED 220 on the Submission port. 222 3. Behavior of SMTP client and server 224 The VHLO command is used by a client to request prime delivery 225 (Section 1.1) of messages. If the server accepts the command by 226 giving a positive response (see Section 3.3.2), the messages 227 transmitted thereafter are said to be in the framework of that VHLO 228 command. 230 The framework terminates on any of the following, whichever comes 231 first: 233 the end of the SMTP session, 235 a further successful VHLO command, or 237 a further successful EHLO command. 239 An SMTP session contains zero or more VHLO frameworks, and each VHLO 240 framework contains zero or more transactions. 242 An SMTP client MAY issue the VHLO command as part of a session 243 initiation, before initiating a mail transaction. That is to say, 244 right after the EHLO command, or instead of it. (In the latter case, 245 of course, the client has to infer that the server supports this 246 extension by some other means.) Clients MAY attempt the VHLO command 247 various times with different parameters, as long as the receiving 248 server allows further retries (see Section 3.3.4). 250 If no EHLO command has been issued by the client, the server assumes 251 an EHLO command with an address literal matching the remote address. 252 However, if the client specified the PTR parameter, the server MAY 253 assume an EHLO command with the resolved host name. 255 Clients failing to issue a successful VHLO command MAY transmit 256 messages using regular transactions, outside of any VHLO framework. 257 If the server supports VHLO, and issued reply codes 550 or 553 to 258 indicate that relaying from the given Domain is not wanted in the 259 current state, then if the client's configuration includes a list of 260 alternative MSAs that it may use as smart hosts in such cases, then 261 the client SHOULD relay through an alternative MSA instead (see 262 Section 5). 264 After successfully transmitting one or more messages in the framework 265 of a successful VHLO command, a client MAY issue another VHLO command 266 to transmit more messages. At any time in a VHLO framework, except 267 during a transaction, a client MAY issue an EHLO command to transmit 268 messages outside of any VHLO framework. Changing framework is 269 required when new messages are transmitted on behalf of a different 270 Domain, or with different VHLO parameters. 272 Messages transmitted in a VHLO framework are subject to the MAIL FROM 273 restriction, and, possibly, to the DKIM-Signature headers existence 274 and verification, the VBR restriction, and any Greylisting 275 restrictions (see Section 3.4). A message satisfying all those 276 restrictions is said to be compatible with the VHLO parameters. 278 By giving a positive reply to VHLO, a server commits itself to accept 279 messages compatible with the given VHLO parameters, and grants them 280 prime delivery. Prime delivery overrides any other policy that might 281 otherwise encourage the server to discard messages, such as ADSP 282 [RFC5617]. While this section indicates circumstances for the 283 failure of each single check, it is up to the local policy to 284 establish what combinations of successful checks yield positive 285 responses. Missing requirements are communicated to the client as 286 described below (Section 3.3.5). 288 3.1. Syntax of the VHLO command 290 The only mandatory argument to VHLO is the Domain. The syntax is as 291 follows: 293 vhlo = "VHLO" SP Domain *( SP auth-rept-claim) CRLF 295 auth-rept-claim = auth-rept-tag [ ":" tag-spec-param ] 297 auth-rept-tag = "GID" / "MX" / "PTR" / "VBR" / "DKIM" / further-tag 299 tag-spec-param = gid-param / vbr-param / dkim-param / further-param 301 where the Domain is the fully-qualified DNS domain name delegated to 302 the entity or organization that is responsible for sending the 303 message(s) that will be transmitted in the framework of this command. 304 Note that, unlike the EHLO command, the Domain is not necessarily the 305 host name of the SMTP client. 307 The maximum line length of the VHLO command is 1000 octets, including 308 the terminating CRLF. 310 When the authentication method corresponding to a VBR or DKIM auth- 311 rept-tag fails, it may be recovered automatically as described in 312 Section 3.3.5. The remaining methods defined in this document don't 313 provide for negotiation. 315 The GID auth-rept-tag and its associated gid-param SHOULD be supplied 316 in the special cases described in sections Greylisting check, and 317 Greylisting restrictions. 319 The remaining arguments MAY be supplied to authenticate the domain 320 name or provide hints for its reputation. These arguments are 321 supplied spontaneously by the client, up to the maximum line length. 323 3.2. Server side checks on the Domain 325 The receiving server SHOULD check that the supplied domain is valid 326 and reckon its reputation. The server is not limited by the checking 327 methods indicated in the parameters. Checks that are normally 328 carried out anyway don't even have a corresponding auth-rept-tag, but 329 are mentioned below. 331 Some circumstances may require to terminate a VHLO framework and 332 start a new one, with varied Domain or parameters. Typically, only a 333 part of the checks need to be carried out again. 335 3.2.1. Greylisting check 337 The GID auth-rept-tag provides the value of a VHLO framework that had 338 been given by this same server or a related MX during a previous SMTP 339 session: 341 gid-param = original-vhlo-string 343 The receiving server SHOULD check that the original-vhlo-string 344 corresponds to the value that it or a related MX has given as random- 345 string in response to a successful VHLO command. Use of the GID 346 auth-rept-tag is reserved for retrying the transmission of messages 347 that suffered a transient failure in the framework of the 348 corresponding VHLO command, as described in Section 3.3.2.1. 350 If the server applies Greylisting[greylisting], it MAY use the 351 provided gid-param, if supplied, as an additional key to a group of 352 messages, besides other data items used to implement Greylisting. If 353 using this parameter, the server MUST still check that the other data 354 items correspond, and that the sender accomplishes the directives 355 described in Greylisting restrictions. 357 The server SHOULD NOT issue a negative response for improper usage of 358 this parameter. However, if bad faith can be ascertained, the server 359 MAY add that knowledge to the sending Domain's reputation. On the 360 other hand, using this parameter eases the task of verifying that a 361 Domain's servers adopt a regular retrying behavior. Such knowledge 362 MAY also be added to the Domain's reputation. It is RECOMMENDED that 363 Domains with enough reputation are whitelisted from Greylisting. 365 3.2.2. DNSBL check 367 The server SHOULD check any relevant DNSBL, and, if a DNSBL that the 368 server, according to its policy, considers trustworthy for either 369 rejecting messages or degrading their worthiness, gives a positive 370 match, then the server SHOULD issue a negative 550 response to VHLO. 371 See [RFC5782] for details on this check. 373 3.2.3. SPF check 375 Checking SPF SHOULD be omitted when the MX or DKIM parameters are 376 specified by the client. Otherwise, if the server carries out SPF 377 checks, it SHOULD check the supplied Domain using the method 378 described in [RFC4408], and, if that results in a "fail" or 379 "permerror", the server SHOULD issue a negative 550 response. For 380 "temperror" see Section 3.3.3. According to its policy, the server 381 MAY issue a negative response when the result is anything but "pass". 382 However, if the client specified the PTR parameter, then the "none", 383 "neutral", and "softfail" SPF results SHOULD also be accepted. 385 Administrators of a Domain who do not take responsibility for 386 messages transmitted by specific hosts, even if those hosts would be 387 related to the Domain according to the PTR and 'iprev' checks, SHOULD 388 use SPF to exclude those addresses, so that the SPF check results in 389 "fail". 391 Note that the so-called "helo check" often gets a result of "none" 392 because [RFC4408] does not provide for SPF (or TXT) RRs to be valid 393 for a whole zone, and many hostmasters omit to define an SPF policy 394 for each host. Unlike EHLO, the Domain argument taken by VHLO points 395 to the sending domain, not the host. Because of the MAIL FROM 396 restriction (Section 3.4.1), no further SPF checks are required for 397 transactions in the framework of this VHLO command. 399 3.2.4. MX check 401 The MX auth-rept-tag suggests that the client is connecting from an 402 IP address that belongs to one of the Domain's MX servers. The 403 receiving server SHOULD lookup the MX records of the given Domain and 404 successively lookup the addresses (A or AAAA depending on the 405 connection) of each of the hosts listed therein, until it finds a 406 matching address or the list is exhausted. If no match was found, 407 the server SHOULD issue a negative 550 response. 409 3.2.5. PTR and 'iprev' checks 411 The PTR auth-rept-tag suggests that the client is connecting from an 412 IP address that can be resolved backward to an host name under the 413 given Domain's hierarchy. 415 The receiving server SHOULD lookup the PTR records for the connecting 416 address and verify that at least one of the returned RRs, after 417 resolving any CNAME, results in a host name whose rightmost part 418 matches the Domain. If no match was found, the server SHOULD issue a 419 negative 550 response. 421 The server SHOULD also check that the name found thereby resolves 422 forward, possibly through a CNAME, to the connecting address, as 423 indicated by the 'iprev' Authentication Method described in 424 [RFC5451]. In case the 'iprev' check fails, the server SHOULD issue 425 a negative 550 response. 427 3.2.6. VBR check 429 The VBR auth-rept-tag provides a list of vouching services: 431 vbr-param = [ "mc=" type-string ";" "mv=" ] certifier-list 433 certifier-list = domain-name *( ":" domain-name ) 435 If the receiving server has a list of trusted vouching services, it 436 SHOULD carry out the VBR validation process as it would be done for a 437 VBR-Info header containing the corresponding elements, see [RFC5518]. 438 In particular, the type-string defaults to "all", and the domain to 439 certify is the given Domain. The server SHALL remove from the 440 certifier-list provided by the client any certifier not mentioned in 441 its list of trusted vouching services. If the resulting list is 442 empty, the server SHOULD issue a negative 555 response, passing its 443 full list of trusted vouching services as indicated in Section 3.3.5. 444 Otherwise, the server SHOULD proceed with querying one or more 445 services in the resulting list. If any of those queries fails for 446 non-transient reasons, the server SHOULD issue a 550 response. If 447 all the services in the resulting list fail for a transient reason, 448 the server SHOULD issue either a 455 response (formatted as if the 449 failed services were not trusted) or a 450 or 451 response. 451 The meaning of the list of trusted vouching services configured 452 within the server is that any single vouch suffices. In case a more 453 complicated logic is needed, e.g. service A and either B or C or else 454 service D, it has to be implemented as an ad-hoc mashup of vouching 455 services to be presented as a single service. 457 Domains within a closed set may enjoy mutual whitelisting by setting 458 up their own ad-hoc vouching server. 460 3.2.7. DKIM check 462 The DKIM auth-rept-tag asserts that all messages transmitted in the 463 given VHLO framework have a valid DKIM-Signature header field whose 464 domain (d) tag matches the Domain in the VHLO command. 466 The parameter contains additional properties of such signatures: 468 See [RFC4871] for imported ABNF 470 dkim-param = sig-s-tag *( ";" sig-tag ) 472 where the sig-s-tag is the s=selector string, while the optional sig- 473 tag's are selected parts of the DKIM-Signature header field. Note 474 that the parameter MUST NOT contain any whitespace, although it is 475 allowed in the signature header. At least the sig-s-tag for the 476 selector (and the sig-q-tag if a query method different than "dns/ 477 txt" is used) MUST be provided. In addition, in case multiple 478 signatures are present whose domain (d) tag equals the Domain, then 479 the client MUST include a sig-b-tag, that is a b=base64data string 480 containing the signature data, or its first bytes, so that the 481 receiving server can unambiguously identify which signature 482 determines a message's compatibility with the VHLO framework. Any 483 other tag from the DKIM-Signature MAY be present in the parameter. 485 The receiving server MAY fetch the public key required to verify the 486 DKIM signatures. If the key does not exist, the server SHOULD issue 487 a negative 550 response. 489 The receiving server may be picky about DKIM signatures; that is to 490 say, it may reject or drop messages based on there being too few 491 signed fields, too weak algorithm used for signing, too old signature 492 timestamp, and similar policy requirements. In such case, it SHOULD 493 verify that the tags accompanying the parameter are sufficient to 494 make a decision, and issue a negative 555 response otherwise, passing 495 the full list of the tags it needs, as indicated in Section 3.3.5. 496 The machine readable part of such response SHALL contain any required 497 sig-tag, with or without a value. Values given for header list, 498 signature timestamp, and expiration date are not meant to be exact, 499 but to specify minimal requirements, and the client may retry with 500 compatible values. 502 Header fields (h) are compatible if the dkim-param contains more 503 fields than required by the 555 reply. The dkim-param may contain 504 fields required by the reply even if they are not present in the 505 actual DKIM-Signature, provided that they are not present in the 506 message's header. 508 Timestamp (t) is compatible if it is actually more recent in the 509 dkim-param than required in the 555 reply. 511 Expiration time (x) is compatible if it is actually more 512 permissive than required in the 555 reply. 514 In case the server can determine from the content of the tags present 515 in the parameter that the DKIM-Signature is not adequate for its 516 policy, it SHOULD issue a negative response 550, 553, or 555. 518 3.3. Responses to the VHLO command 520 An organization's servers accept incoming mail messages according to 521 some policies. The requisites for according a positive reply to a 522 VHLO command SHOULD NOT be less strict than those for accepting an 523 incoming message. In particular, if a policy states that certain 524 conditions imply that a message would be accepted with some reserves, 525 it should likely state that VHLO is denied under the same conditions. 527 When processing the optional auth-rept-claim's parameters, the server 528 MUST ignore any parameter whose tag it does not support or 529 understand. 531 In case of unsuccessful response, the server retains its previous 532 state. 534 3.3.1. Overview of possible responses 536 250 Domain OK, greetings and extension list 538 450 VHLO temporarily unavailable 540 451 VHLO aborted: error in processing 542 455 Parameter temporarily unverifiable 544 500 Syntax error, command unrecognized 546 501 Syntax error in parameters or arguments 548 502 Command not implemented 550 503 Bad sequence of commands 552 550 Missing required qualification 554 553 Domain rejected by policy 555 555 Failed for recoverable reason 557 3.3.2. Positive response 559 If the checks carried out on the Domain and the connection indicate 560 that the server will wholeheartedly accept messages from the client, 561 the server returns a 250 reply code. The response is a multi-line 562 response with the same format as the EHLO response (ehlo-ok-rsp in 563 [RFC5321]), with the keywords for all the SMTP extensions available 564 as a consequence of entering this VHLO framework. 566 Upon a positive response, the client MUST reset any flags and 567 variables associated to SMTP extensions that it may have since 568 previous EHLO or VHLO commands in the same session. 570 3.3.2.1. VHLO parameter and MAIL FROM command 572 The server response to the VHLO and EHLO commands includes the VHLO 573 keyword along with a randomly generated token of up to 16 octets. 574 The format of the relevant line is as follows: 576 ehlo-line = "VHLO" SP random-string 578 random-string = 1*16( %d33-60 / %d62-126 ) 579 ; any CHAR excluding "=", SP, and control 580 ; characters. 582 The random string supplied by the server MUST be repeated by the 583 client as the value of the VHLO parameter to the MAIL command, for 584 each transaction in the framework of this VHLO command. This is 585 meant to guard against blind attacks and to ease Greylisting checks. 587 3.3.3. Transient error responses 589 If the the server is temporarily unable to carry out any required 590 check on the Domain, it SHOULD return the 451 reply code. Then, the 591 client SHOULD quit the session and retry at a later time. 593 The server MAY return the 450 reply code to indicate that it is not 594 able or willing to reckon the client's reputation during this 595 session, irrespectively of any parameter supplied. In this case, the 596 client MAY try an EHLO command instead, to transmit messages outside 597 of any VHLO framework. 599 The server MAY return the 455 reply code to indicate that it is 600 temporarily unable to carry out the checks implied by one or more 601 specific parameters. It is possible that a positive response is 602 given if the client repeats the command using different auth-rept- 603 claim's or different tag-spec-param's. The text of the response 604 SHOULD indicate the parameters that are still available as described 605 in Section 3.3.5. 607 3.3.4. Negative responses 609 If the the server cannot grant prime delivery (Section 1.1) because 610 of a missing parameter or parameter's value in the VHLO command, it 611 SHOULD return the 550 or 555 reply codes indicating the missing 612 parameters and arguments as described in Section 3.3.5. 614 The server MAY return the 553 reply code to indicate that it will 615 never grant prime delivery for the given Domain to the current 616 client, whatever auth-rept-claim's the client may supply. 618 The server MUST return the 503 reply code (bad sequence of commands) 619 if a VHLO command is issued while a transaction is active. 621 Servers that don't support this extension MAY return the 500 or 502 622 reply codes. 624 After a 555 reply code, the client MAY retry a VHLO command with the 625 parameters modified accordingly. Otherwise, if it is unable to 626 satisfy the server requirements, the client SHOULD proceed as if it 627 obtained a 500 reply code. It is RECOMMENDED that the client 628 application logs the missing requirements, so that administrators 629 know how to gain access to the given server. 631 After reply codes 500, 502, 550, and 553, the client MUST NOT attempt 632 more VHLO commands during the current session. In addition, after 633 reply codes 550 and 553, the client SHOULD NOT ever attempt any 634 further VHLO command to an MX server of the current target for 635 messages originating from the given Domain; this implies caching the 636 domains pair in a buffer that will be cleared by either configuration 637 updates or overrun (in theory, VHLO should not be retried until the 638 relevant datum changes in any of the involved servers, including 639 third parties). 641 After reply codes 500, 502, 550, 553, and 555, the client MAY quit 642 the session and send the message through an alternative relay as 643 described in Section 5. Alternatively, the client MAY try an EHLO 644 command, if it hasn't issued one already, and transmit messages 645 outside of any VHLO framework. 647 3.3.5. Diagnosis of failed VHLO commands 649 Normally, a client supplies all the claims that can possibly result 650 in increased reputation, except for line length limitations. VBR's 651 certifier-list's, for example, might grow quite long and clients may 652 be unable to store them on a single line. However, servers can issue 653 multi-line responses containing the complete list, so that a client 654 can select the correct certifiers to include in the next attempt. As 655 some failures can be worked around automatically, failure responses 656 SHALL contain both human readable text and machine readable text. 657 Formally, reply codes 455, 550, and 555 to the VHLO verb have the 658 following syntax: 660 See [RFC5234] for imported ABNF 662 Failure-resp = *( Failure-code "-" [ diag-text ] CRLF ) 663 Failure-code [ SP diag-text ] CRLF 665 Failure-code = %x34-35 %x35 %x35 667 diag-text = hread-text / (":" mread-text) 669 hread-text = 1*( %d09 / %d32-57 / %d59-126 ) *VCHAR 670 ; the first character must not be ":" 672 mread-text = auth-rept-claim / check-failed 674 check-failed = check-keyword ":" check-spec-info 676 check-keyword = auth-rept-tag / "SPF" 678 check-spec-info = hread-text 679 ; a column separated domain name list for VBR, 680 ; a domain name or URL for DNSBL, 681 ; required result or failure reason for SPF, 682 ; required tags or failure reason for DKIM, 683 ; n/a for MX, GID, PTR 685 A server SHOULD NOT vary its requirements during a given session. 687 If a client manages to issue a successful VHLO command for a given 688 Domain after a previous attempt failed, it MAY store the parameters 689 for future reuse. However, the server requirements MAY be changed in 690 future sessions. 692 3.4. Restrictions and further server side checks 694 Messages transmitted in the framework of a successful VHLO command 695 are subject to the restrictions detailed in this section. Clients 696 MUST NOT attempt to break these restrictions. Servers SHOULD check 697 that clients comply. 699 3.4.1. MAIL FROM restriction 701 Non-empty arguments of the MAIL FROM commands are restricted to 702 addresses whose domain part consists of the authenticated Domain. 704 In addition, the server MUST check that the VHLO parameter is 705 included and that the corresponding value matches the random string 706 that the server generated on giving the positive response to the VHLO 707 command. 709 3.4.2. VBR restriction 711 If the VHLO command in whose framework the message is received 712 contained a VBR tag, the message MAY have a VBR-Info header. If that 713 header is present, it MUST be compatible with the given vbr-param. 714 Compatible here means that it mentions at least the certifier that 715 the server trusts and verified before accepting the relevant VHLO 716 command. 718 If a VBR-Info header is not present, the receiving server MAY add one 719 based on the Domain given, the certifiers it trusts and verified, and 720 its guess of the type of content among those mentioned in the RR(s) 721 obtained during the verification query. 723 3.4.3. DKIM-Signature headers existence and verification 725 If the VHLO command in whose framework the message is received 726 contained a DKIM tag, the message MUST have a valid DKIM-Signature 727 header field, compatible with the given dkim-param. Compatible here 728 means that the domain (d) of the DKIM-Signature is the same, the 729 selector (s) is the same one given in the parameter, and any sig-tag 730 on the signature that was also present in the VHLO parameter has a 731 value compatible with what has been given in the parameter. Again, 732 compatible means different things for different tags: 734 Header fields (h) are compatible if the actual signature contains 735 more fields than dkim-param. However, the signature may not 736 contain some fields, present in the dkim-param, but not actually 737 present in the message header, and still be compatible. 739 Timestamp (t) is compatible if it is actually more recent than 740 advertised in dkim-param. 742 Expiration time (x) is compatible if it is actually more 743 permissive than advertised in dkim-param. 745 Signature data (b) is compatible if the actual signature begins 746 with the same sequence of bytes contained in the dkim-param, and 747 if it this unambiguously identifies it among signatures by the 748 given Domain. 750 If the server verifies signatures on the fly, the verification fails, 751 and such failure would prevent the message from having a prime 752 delivery (Section 1.1), the server SHOULD reject the message instead. 754 Note that the server does not need to verify more than one signature. 756 3.4.4. Greylisting restrictions 758 If transmission of a message in the framework of a VHLO command fails 759 due to transient conditions (4xx reply codes), and the transmission 760 was not itself a retry, the sending server SHOULD annotate the 761 current VHLO parameter in the message's meta data while it queues the 762 message for further retries. We refer to this piece of data as 763 original-vhlo-string. Typically, a message's meta data includes the 764 envelope and possibly the failure reason, and is used by a server to 765 devise a sending strategy as described in section 4.5.4.1 of 766 [RFC5321]. (Note that we are talking about transient failures in the 767 transmission of a message, i.e. after MAIL, RCPT, DATA, or data 768 completion by .; not the VHLO command.) 770 The current VHLO parameter should be added to meta data only after 771 the very first failure; in particular, not if a previous attempt to 772 transmit the message has happened before, whether in the framework of 773 a VHLO command or not. This implies that use of VHLO is restricted 774 to hosts who are able to discern new messages from retried attempts. 776 When attempting to retransmit a queued message that has this 777 original-vhlo-string in its meta data, the sending client SHOULD 778 transmit such string using the GID auth-rept-tag with 780 gid-param = original-vhlo-string 782 Only messages that share the same original-vhlo-string may be 783 transmitted in the framework of a VHLO command that used the GID 784 auth-rept-tag with that value. This implies that the sending client 785 MUST terminate the current VHLO framework in case the next message's 786 original-vhlo-string differs from the gid-param used to establish it 787 (where no gid-param matches an empty original-vhlo-string.) 789 4. Forwarding of messages accepted under VHLO 791 A message accepted in the framework of a VHLO command deserves prime 792 delivery (Section 1.1). However, the receiving server possibly does 793 not host the mailboxes of the relevant recipients directly. For 794 example, it may be a boundary or secondary exchanger, a vanity 795 address server, or it may be following user-specific forwarding 796 instructions. For this specification, we just distinguish if the 797 message is forwarded within the same organization or to an external 798 domain. 800 If the message is forwarded internally, all hosts MUST be configured 801 so as to honor the promise of prime delivery that border or secondary 802 exchangers grant on their behalf. If, for whatever reason, prime 803 delivery is not possible, a failure notification MUST be sent to the 804 Return-Path address, if any. Even if sending notifications is 805 expected to be fairly safe at this point, it is RECOMMENDED that any 806 organization-wide policy that can be applied on acceptance produces 807 an on-line rejection rather than a delayed failure notification. 809 If the message is forwarded to an external domain, the SMTP client 810 SHOULD attempt to transmit it in the framework of a VHLO command, 811 unless either it can determine that the target host does not 812 implement this SMTP extension, or it has some other arrangement with 813 the target host that grants prime delivery (e.g. using strong 814 authentication as provided by [ff]). 816 VHLO may be used for forwarding in two different ways: 818 If the forwarder is affiliated with the original Domain or if the 819 message contains a valid DKIM signature from it, then the message 820 can be sent using the original envelope's originator address. The 821 Domain declared as VHLO parameter is the original one. (This is 822 as "Alias expansion".) 824 Otherwise, the Domain in the VHLO parameter is the forwarder's 825 domain and the originator address MUST be changed (e.g. using 826 [srs]). (This is as "List expansion".) 828 Failure to relay MUST always be reported as indicated by [RFC5321]. 829 In particular, any reason that may be considered valid for not 830 issuing a failure notification SHOULD be ruled out before giving a 831 positive reply to the VHLO command. 833 5. Submission strategy 835 In order to avoid hassles, several smaller MTAs are configured to use 836 external Mail Submission Agents (MSAs) as smart hosts. One 837 collateral advantage of using Verified Hello is that falling back to 838 smart hosts can be confined to specific cases, depending on the 839 outcome of the weak authentication process. The postmasters of a 840 sending domain can resort to smart hosts while they collect feedback. 842 Then, for the increased privacy and efficiency that direct delivery 843 yields, they'll have the ability to select what combination of 844 mechanisms and brands will satisfy the majority of their targets, and 845 decide to implement those requirements. 847 The VHLO command, by allowing to check deliverability in advance, 848 enables clients to use smart hosts optionally. Rather than 849 configuring a fixed mail-out path for certain target domains, relays 850 can dynamically adjust their strategy according to the target host's 851 response to the VHLO command. The list of preferred VBR certifiers 852 provided by a 555 negative response may be used as keys to build a 853 corresponding list of smart hosts that can be used as Mail Submission 854 Agents, provided that the certifiers of each smart host are known. 856 To implement this strategy, a relay's configuration needs a list of 857 alternative MSAs, consisting in one or more entries containing a host 858 name, a username/password pair, and an optional list of VBR 859 certifiers of that MSA. The latter field should be updated 860 dynamically whenever it does not correspond to the list returned with 861 a 555 negative reply from the smart host; it is RECOMMENDED to log 862 such updates as appropriate. Other means to dynamically select an 863 MSA, and how to determine the default one MAY also be provided for. 865 6. IANA Considerations 867 6.1. IANA Mail Parameters 869 This extension will have to be inserted in the mail-parameters 870 assignments IANA registry. The keyword VHLO should appear 872 o as a Registry Keyword, along with the "Verified Hello" 873 description, this document's reference, and a "+" for SMTP only, 874 and 876 o as an SMTP extension keyword that has a parameter, after the 877 "Verified Hello" description column, before the "Random ID" 878 parameter description and this document's reference that terminate 879 its row. 881 Formally, VHLO is not a service type, as it requires or assumes EHLO. 883 6.2. IANA VHLO methods 885 A registry is needed for tracking the auth-rept-tag / check-keyword 886 that must be unique in the diagnostic text. New methods may be 887 defined publishing their own RFCs where semantic and syntactic 888 details are explained, including error response and diagnosis. This 889 document defines 891 +---------+----------------------------------+-----------+ 892 | Keyword | Parameter/Description | Reference | 893 +---------+----------------------------------+-----------+ 894 | DKIM | Key selector, query method, etc. | [this] | 895 | DNSBL | None. Diagnostic only. | [this] | 896 | GID | Greylisting ID. | [this] | 897 | MX | None. DNS lookup. | [this] | 898 | PTR | None. rDNS lookup. | [this] | 899 | SPF | None. Diagnostic only. | [this] | 900 | VBR | Certifier list. | [this] | 901 +---------+----------------------------------+-----------+ 903 Initial registry values 905 7. Security Considerations 907 Global communications require that SMTP servers accept mail coming 908 from unknown hosts. This requirement rules out strong authentication 909 schemes, because, by definition, it is not possible to authenticate 910 unknown entities. Historically, Internet protocols granted some 911 trust to any host, since sporting a global IP address was deemed a 912 sufficient credential. When more restrictive criteria became 913 required, a number of mechanisms have emerged for identifying the 914 sender. DNS and rDNS are used to check the relationship between the 915 sender's IP address and its domain. However, using EHLO, the 916 sender's domain can only be guessed at. Some mechanisms, e.g. rDNS, 917 are not universally available, and, although good senders try and 918 facilitate the identification of themselves by setting up DNS as well 919 as they can, receivers provide no feedback on their effort. Since 920 senders don't know which mechanism, if any, would satisfy the 921 requirements of a target server, they can only follow generic 922 guidelines, outdated static policy pages, and rare support team's 923 hints whose validity is not imperishable. 925 This document proposes an intermediate level of trust. An SMTP 926 client is being authenticated based on weak evidence, originating 927 from the DNS and the TCP layer: 929 o The IP address of the remote client is known from the TCP layer. 930 Verification of the random string implies it is fairly difficult 931 to forge it. 933 o Any of the MX, PTR, or SPF checks confirms that the IP address is 934 somehow authorized by the organization who owns the Domain. 936 o The DNSBL check implies that the IP address is not that of a known 937 attacker. 939 The two remaining checks, DKIM and VBR, may provide two additional 940 characterizations of the messages being transmitted. DKIM ensures 941 that messages have passed through the domain's signing process, which 942 presumably implies that any sender's local policy has been enforced. 943 In this respect, DKIM can be regarded as an open authorization to 944 impersonate the original Domain for the purpose of forwarding a 945 signed message. See [RFC5617], [RFC5672], and [RFC5863] for further 946 insight on DKIM semantics. 948 VBR, depending on the certifier's policy, may generically ensure that 949 the sending domain is well behaved. A vouching service may 950 scrutinize the DNS settings of a given domain, verify its whois 951 record, check their spam rate using honeypots, investigate the 952 domain's users, receive and process copies of the abuse reports 953 issued against messages emitted by that domain, verify that reported 954 spammers get blocked according to some policy, or otherwise establish 955 the domain reputation. The possibility to communicate the preferred 956 vouching services may work as an incentive for the advertised service 957 providers. 959 The authentication provided by this extension is weaker than SMTP 960 Authentication [RFC4954]. Therefore, it SHOULD NOT be used instead 961 of it. 963 Diagnostic messages provided with negative responses to the VHLO 964 command may disclose acceptance policies of the target domain. This 965 is not considered harmful, since such policies are usually public. 966 Letting a sender know which mechanism failed is a risk only in case 967 of security through obscurity. Mechanisms that are secure by design 968 don't have to be kept secret. The mechanisms considered in this memo 969 only involve DNSBL, SPF, MX, PTR, VBR, and DKIM. However, Verified 970 Hello provides for extensibility of this authentication/reputation 971 (auth-rept) mechanisms base. Giving feedback is important for 972 mechanism management, as it allows popular mechanisms to gain 973 momentum. In addition, some mechanisms reference a different domain 974 that makes explicit assertions about the reputation of the sender's 975 domain. This is where the branding practice comes into play. As the 976 number of domains that give reputation indications may grow much more 977 quickly than the number of mechanisms, feedback is specially 978 important for spreading their popularity. In this respect, Verified 979 Hello is not yet another authentication mechanism. It is a framework 980 for managing those mechanisms. 982 However, in case a Domain's security structure depends on keeping 983 that information secret, the server should carefully consider what 984 diagnostic messages it provides to what clients. It is possible to 985 provide VHLO services to selected domains only, and discarding the 986 rest with the reply code 553. 988 8. References 990 8.1. Normative References 992 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 993 Requirement Levels", BCP 14, RFC 2119, March 1997. 995 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 996 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 997 Signatures", RFC 4871, May 2007. 999 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1000 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1002 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1003 October 2008. 1005 [RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By 1006 Reference", RFC 5518, April 2009. 1008 8.2. Informative References 1010 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 1011 for Authorizing Use of Domains in E-Mail, Version 1", 1012 RFC 4408, April 2006. 1014 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", 1015 RFC 4409, April 2006. 1017 [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension 1018 for Authentication", RFC 4954, July 2007. 1020 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 1021 Message Authentication Status", RFC 5451, April 2009. 1023 [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, 1024 "DomainKeys Identified Mail (DKIM) Author Domain Signing 1025 Practices (ADSP)", RFC 5617, August 2009. 1027 [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) 1028 Signatures -- Update", RFC 5672, August 2009. 1030 [RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782, 1031 February 2010. 1033 [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, 1034 "DomainKeys Identified Mail (DKIM) Development, 1035 Deployment, and Operations", RFC 5863, May 2010. 1037 [ff] FixForwarding.org, "solution proposed", 2009, 1038 . 1040 [greylisting] 1041 Greylisting.org, "Greylisting.org - a great weapon against 1042 spammers", 2009, . 1044 [srs] Libsrs2.org, "libsrs2 - Home", 2004, 1045 . 1047 Appendix A. Examples 1049 Some examples showing the relevant snippet of client-server dialog. 1051 A.1. Prime delivery message transfer 1053 Complete example where the client successfully transfers a message 1055 S: 220 example.com SMTP server ready 1056 C: VHLO example.net 1057 S: 250-example.com greetings example.net 1058 250 VHLO 0123456789ABCDEF 1059 C: MAIL FROM: VHLO=0123456789ABCDEF 1060 S: 250 Ok 1061 C: RCPT TO: 1062 S: 250 Ok 1063 C: DATA 1064 S: 354 Go ahead 1065 S: From: author@example.net 1066 To: dest@example.com 1067 Subject: test 1069 This is transmitted with prime delivery! 1070 . 1071 S: 250 Ok 1072 C: QUIT 1073 S: 221 Bye 1075 A.2. Failure after DNSBL check 1077 Colons have been replaced in the automatic message to formally 1078 preserve machine readability 1080 C: VHLO example.net 1081 S: 555-You are blacklisted 1082 555 :DNSBL:see http_//www.dnsbl.example/query/bl?ip=192.0.2.3 1083 C: QUIT 1084 S: 221 Bye 1086 Alternatively, the failure can be signaled as usual. Since feedback 1087 plays a minor role for negative (black) vouching, the following is 1088 likely to get an equivalent effect. 1090 C: VHLO example.net 1091 S: 550-You are blacklisted 1092 550 see http://www.dnsbl.example/query/bl?ip=192.0.2.3 1093 C: QUIT 1094 S: 221 Bye 1096 A.3. Failure on the MAIL FROM restriction check 1098 In this snippet, the domain names are mismatched 1100 C: VHLO example.net 1101 S: 250-example.com greetings example.net 1102 250 VHLO 0123456789ABCDEF 1103 C: MAIL FROM: VHLO=0123456789ABCDEF 1104 S: 550 Domain origin mismatch 1105 C: QUIT 1106 S: 221 Bye 1108 A.4. Automatically finding a common vouching service 1110 In this snippet, the client finds a valid VBR name 1112 C: VHLO example.net MX VBR:vouch1.example:vouch2.example 1113 S: 555-we only accept these :VBR:vouch97.example:vouch98.example 1114 555-:VBR:vouch99.example:vouch100.example:vouch101:example 1115 555 :VBR:vouch102:example:vouch103:example:vouch104:example 1116 C: VHLO example.net MX VBR:vouch100.example:vouch101.example 1117 S: 250-example.com greetings example.net 1118 250 VHLO 0123456789ABCDEF 1120 A.5. Reattempting Greylisted transmission 1122 On a first attempt the client got greylisted 1124 S: 220 example.com SMTP server ready 1125 C: VHLO example.net 1126 S: 250-example.com greetings example.net 1127 250 VHLO FirstTime 1128 C: MAIL FROM: VHLO=FirstTime 1129 S: 250 Ok 1130 C: RCPT TO: 1131 S: 450 You are greylisted, retry after 5 mins. 1132 C: QUIT 1133 S: 221 Bye 1135 ... 5 minutes later ... 1137 S: 220 example.com SMTP server ready 1138 C: VHLO example.net GID:FirstTime 1139 S: 250-example.com greetings example.net 1140 250 VHLO SecondTime 1141 C: MAIL FROM: VHLO=SecondTime 1142 S: 250 Ok 1143 C: RCPT TO: 1144 S: 250 Ok 1145 C: DATA 1146 S: 354 Go ahead 1147 S: From: author@example.net 1148 To: dest@example.com 1149 Subject: test 1151 This is transmitted after greylisting delay! 1152 . 1153 S: 250 Ok 1154 C: QUIT 1155 S: 221 Bye 1157 A.6. Mandating DKIM usage 1158 In this snippet, the server requires DKIM signature for specific 1159 headers. The client might have turned for alternative delivery, EHLO 1160 or alternative MSA, if it could not comply. In addition, a common 1161 vouching service is automatically found as in the example above 1162 (Appendix A.4). 1164 C: VHLO example.net VBR:v1.example:v2.example 1165 S: 555-we only accept these :VBR:v97.example:v98.example 1166 555-:VBR:v99.example:v100.example:v101:example 1167 555-:VBR:v102:example:v103:example:v104:example 1168 555 :DKIM:h=to:from:cc:date 1169 C: VHLO example.net VBR:v100.example DKIM:s=mail;h=to:from:cc:date 1170 S: 250-example.com greetings example.net 1171 250 VHLO 0123456789ABCDEF 1173 A.7. Requiring extra DKIM tags 1175 In this snippet, the server wants to know the timestamp and 1176 expiration of the signature. Note that this almost certainly will 1177 require a new VHLO framework in case further message for that Domain 1178 have to be relayed. 1180 C: VHLO example.net DKIM:s=mail 1181 S: 555-we want to check signature timestamp and expiration time 1182 555 :DKIM:t=;x= 1183 C: VHLO example.net DKIM:s=mail;t=1117574938;x=1118006938 1184 S: 250-example.com greetings example.net 1185 250 VHLO 0123456789ABCDEF 1187 Author's Address 1189 Alessandro Vesely 1190 v. L. Anelli 13 1191 Milano, MI 20122 1192 IT 1194 Email: vesely@tana.it