idnits 2.17.1 draft-brotman-ietf-bimi-guidance-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [BCP 14], but that reference does not seem to mention RFC 2119 either. -- The document date (March 8, 2021) is 1116 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BCP 14' is mentioned on line 105, but not defined -- Looks like a reference, but probably isn't: '1' on line 620 -- Looks like a reference, but probably isn't: '2' on line 622 -- Looks like a reference, but probably isn't: '3' on line 624 -- Looks like a reference, but probably isn't: '4' on line 626 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Brotman 3 Internet-Draft Comcast 4 Intended status: Best Current Practice T. Zink 5 Expires: September 9, 2021 Zink Magical Contraptions 6 M. Bradshaw 7 Fastmail 8 March 8, 2021 10 Receivers Guidance for Implementing Branded Indicators for Message 11 Identification (BIMI) 12 draft-brotman-ietf-bimi-guidance-03 14 Abstract 16 This document is meant to assist receivers or other mailbox providers 17 by providing guidance to implementing Brand Indicators for Message 18 Identification (BIMI). This document is a companion to the main BIMI 19 drafts which should first be consulted and reviewed. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 9, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Goals for BIMI . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Should your site implement BIMI? . . . . . . . . . . . . . . 3 59 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 5. Site implementations . . . . . . . . . . . . . . . . . . . . 4 61 6. Validation of a BIMI message . . . . . . . . . . . . . . . . 5 62 6.1. BIMI Site Requirements . . . . . . . . . . . . . . . . . 5 63 6.2. Verified Mark Certificate (VMC) Validation . . . . . . . 6 64 7. Communicating BIMI results between the MTA and the MUA . . . 6 65 7.1. Image Retrieval . . . . . . . . . . . . . . . . . . . . . 6 66 7.2. TTL of cached images . . . . . . . . . . . . . . . . . . 7 67 7.3. Image Display . . . . . . . . . . . . . . . . . . . . . . 7 68 7.4. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 7 69 7.5. Basic flow example . . . . . . . . . . . . . . . . . . . 8 70 7.6. Message Classification . . . . . . . . . . . . . . . . . 9 71 8. Domain Reputation . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Rolling up based upon domain vs organizational domain . . 9 73 8.2. VMC Root of Trust . . . . . . . . . . . . . . . . . . . . 10 74 9. BIMI Playbook Checklist . . . . . . . . . . . . . . . . . . . 10 75 10. Public documentation . . . . . . . . . . . . . . . . . . . . 11 76 10.1. Documentation For Brands: . . . . . . . . . . . . . . . 11 77 10.2. Documentation For Users: . . . . . . . . . . . . . . . . 11 78 11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 11.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 12 80 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 81 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 14.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 14.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 The Brand Indicators for Message Identification (BIMI) specification 90 introduces a method by which Mail User Agent (MUA, e.g., an email 91 client) providers combine DMARC-based message authentication with 92 cryptographic methods to ensure the identity of a sender. If the 93 identity is ensured, the MUA can then retrieve sender-selected 94 iconography to display within the MUA. This displayed iconography 95 grants the sender brand impressions via the BIMI-capable MUA, and 96 should be a driving factor for the adoption of authenticated email. 98 1.1. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in 103 [BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 2. Goals for BIMI 108 As stated in other BIMI drafts, BIMI intends to advance email 109 authentication by granting a sending party brand impressions as long 110 as the message passes authentication mechanisms and meets other 111 receiver qualifications (reputation, encryption, allow listing, et 112 cetera). DMARC currently has wide adoption by some of the Internet's 113 larger brands, but there is still a long tail of small-to-medium size 114 brands (and many large ones) that do not have it. Because BIMI 115 provides a visual presence in the inbox, and because visual 116 impressions are desirable for brands, BIMI provides an incentive for 117 marketers to spur DMARC adoption, whereas a concern purely from 118 security may not. 120 3. Should your site implement BIMI? 122 If your site satisfies the Section 6.1, this is likely a "yes". 124 As email has evolved over the past three decades, it is no longer a 125 medium of merely exchanging text, but of enabling people to build 126 rich experiences on top of it. BIMI provides an incentive for brands 127 to send email more securely because the desired behavior - a visual 128 imprint in the inbox - first requires DMARC adoption. 130 4. Terminology 132 The following terms are used throughout this document. 134 o MTA 136 o MUA 138 o DKIM 140 o SPF 142 o DMARC 144 o Alignment 145 o Verified Mark Certificate (VMC) 147 o Recipient Domain 149 o Sending Domain 151 o MVA 153 For definitions of these terms, see the Appendix. 155 5. Site implementations 157 In order for a site to correctly implement BIMI, the receiver must be 158 able to perform the following: 160 o Validate SPF 162 o Validate DKIM signatures 164 o Validate DMARC 166 o Discover and fetch a BIMI assertion record using DNS 168 o Fetch a SVG using HTTPS 170 o Validate a SVG using a profile 172 o Add Authentication-Results and BIMI-* Headers to a message 174 Optionally, for a site to correctly implement BIMI Verified Mark 175 Certificate (VMC) verification, the receiver must be able to perform 176 the following: 178 o Fetch a VMC using HTTPS 180 o Validate a VMC (a new kind of Extended Validation (EV) 181 certificate) 183 o Extract a SVG from a VMC 185 A site may wish to implement URI alteration and image caching for 186 hosted recipients. By implementing BIMI, a site agrees that through 187 some combination of trust mechanisms, it will instruct a BIMI-capable 188 MUA to display the image fetched from a URI within the message 189 headers. This URI is created after the MTA authenticates a message, 190 and is also able to authenticate the VMC associated with the sending 191 domain. Discussion of these trust mechanisms is beyond the scope of 192 this document. 194 6. Validation of a BIMI message 196 6.1. BIMI Site Requirements 198 In the BIMI specification, a message MUST be authenticated via DMARC. 199 As stated in the DMARC draft, this requires that only one of DKIM or 200 SPF must successfully pass validation with alignment with the 201 organizational domain in the From: address. However, for additional 202 local security measures, a receiving site may choose to create 203 additional requirements for senders in order to verify BIMI (that is, 204 indicate to a downstream MUA that it is safe to load a BIMI logo in 205 the email client) 207 This may include, but is not limited to: 209 o Requiring both DKIM and SPF to validate and align with the 210 organizational domain in the From: address (whereas DMARC only 211 requires one of SPF or DKIM to align with the From: domain) 213 o SPF "strength" requirements (e.g., requiring "-all", disallowing 214 usage of "?all" or not allowing inclusion of overly large address 215 spaces) 217 o SMTP delivery via TLS 219 o Feedback Loop registration or other method of registration with 220 the receiving site 222 o Domain reputation via a DNS allow list or other reputation system 224 These localized requirements are at the discretion of the receiving 225 site. In general, the stricter the criteria, the less chance there 226 is of an MUA erroneously showing a logo and giving the wrong signal 227 to a user. 229 Upon receipt of an email, a receiver that implements BIMI should 230 remove or rename any previously existing BIMI-* headers other than 231 BIMI-Selector, as they may have come from an attacker (as long as the 232 BIMI-Selector is covered by the DKIM signature; if not, it should be 233 removed, renamed, or ignored). 235 Additionally: 237 o It may be useful to have messages exiting a site to have those 238 BIMI-* headers removed as well. 240 o It is useful for a site that has not implemented BIMI to remove 241 those headers so that an MUA that does make use of those headers 242 would not accidentally display a BIMI image when the message has 243 not been properly authenticated by the email receiver (even though 244 an MUA should not make use of BIMI headers and instead rely upon 245 settings from the mailstore, it is possible that some MUAs will 246 nevertheless use headers without taking appropriate precautions). 248 6.2. Verified Mark Certificate (VMC) Validation 250 (Currently, see document in Reference below) 252 7. Communicating BIMI results between the MTA and the MUA 254 In order for a receiver that has implemented BIMI to notify an MUA 255 that it should display the images: 257 o An MTA must verify BIMI, and if it passes, add additional headers 258 containing the logo to be displayed. 260 The MUA must check to see if a message passed BIMI before loading the 261 BIMI image. 263 While the MTA MAY stamp BIMI-related information in the message 264 headers, they should not be relied upon by an MUA without additional 265 checks to make sure they were added by a trusted source, for example, 266 making sure the MTA strips existing headers on ingress, or by 267 checking for a bimi pass in a trusted Authentication-Results header. 269 7.1. Image Retrieval 271 A core part of the BIMI specification is that the MUA will retrieve 272 an image file to display for each BIMI-validated message. There are 273 multiple ways to accomplish this, for example: 275 o In its most basic setup, a BIMI-capable MUA could retrieve the 276 image file directly from the site specified in the BIMI-Location 277 header. 279 o A BIMI capable MTA will add a header containing the Base64 encoded 280 SVG of the image file. The MUA can use this header to retrieve 281 the already validated image file for display. This is the 282 recommended method of image retrieval as the work of retrieval and 283 validation has already been done by the MTA. 285 o Other providers may choose to cache the associated images in a 286 local store which could be used as the BIMI resource address in 287 the headers of a BIMI-approved message in a sort of proxy 288 configuration. 290 7.2. TTL of cached images 292 In some circumstances it is necessary to cache the images that an MUA 293 would want to load. For example, if a domain owner has a short TTL 294 time, it would force the MUA to look it up in an unreasonably short 295 period of time. In this case, a receiver may want to set its own 296 TTL. 298 One option is to set it to several hours, or a day; another option is 299 to set the TTL to the same as the expiration period in the VMC that 300 contains the BIMI image. The downside is that the caching mechanism 301 might need to check for certificate revocation, and then re-fetch 302 images. 304 7.3. Image Display 306 Although BIMI does not define an aspect ratio for Brand Indicators it 307 is expected that the majority of receivers will display them in a 308 square or circular space. Is it recommended to brands that their 309 Indicators should be constructed to display in a 1:1 aspect ratio, 310 receivers should design the user interface display for BIMI 311 Indicators with this in mind. 313 7.4. Privacy Concerns 315 There is some concern that the retrieval of the iconography could 316 result in a privacy leak. 317 As the images are retrieved, it's possible that the image provider 318 could track the retrieving system in some way. This has implications 319 whether it be the sender or provider that is hosting the image. For 320 example, a sender could include a singular selector for a single 321 recipient, or a provider could append a tracking string to the image 322 URI in the header. 324 A receiver may choose to track the number of selectors an 325 organizational domain is permitted to use and deny processing if this 326 exceeds a defined limit. Similarly, a receiver may choose to track 327 and limit distinct Indicator URLs. 329 MTAs are encouraged to cache BIMI Records, VMCs, and Indicators to 330 limit tracking. 332 MUAs are encouraged to extract Indicators from the BIMI-Indicator 333 header rather than retrieving them directly from the source, as doing 334 so will limit any data exposure to the MTA processing the message. 335 The BIMI approved SVG profile prohibits an SVG from loading external 336 elements, this removes the risk of tracking when an Indicator is 337 shown in the client. 339 An in-depth discussion of all the potential privacy leaks with 340 respect to loading or embedding images is outside the scope of this 341 document. 343 7.5. Basic flow example 345 One sample implementation of BIMI by a receiver, who does everything 346 on-the-fly, is as following: 348 o Upon receipt of a message, the receiver checks to see if the 349 message passes aligned-SPF or DKIM, and DMARC, and ensures that 350 the sending domain has a DMARC policy of "quarantine" or "reject" 351 per local receiver policy, while properly applying the appropriate 352 DMARC policy to the message. 354 o If the message passes prior checks, the receiver will then check 355 to see if the domain in the From: address has a BIMI record (or, 356 if the message has a BIMI-Selector header that is covered by the 357 DKIM-Signature, uses that to do the BIMI query in DNS). 359 o If a BIMI record is found, the receiver then retrieves the VMC 360 from the location that the BIMI record points to, and attempts to 361 verify the VMC using a trusted root certificate. . 363 o Upon successful verification of the VMC, the receiver extracts the 364 verified image from the VMC. If the SVG also passes the SVG 365 validation steps then this is a successful BIMI verification. 367 o If the BIMI verification fails then the MTA must not indicate to 368 the MUA to show a BIMI image. The MUA MAY show a default image 369 such as a set of initials, or unidentified sender. 371 o The email receiver then does the rest of its anti-spam, anti- 372 malware, and anti-phishing checks as discussed in Section 7.6 373 below. 375 o The email receiver then adds the relevant Authentication-Results 376 and BIMI-* headers to the message to signal to the downstream 377 email client that the message passed BIMI and that is safe to load 378 the logo. 380 o Eventually, the MUA checks the BIMI-* headers, decodes the image 381 in the BIMI-Indicator header, and displays it as the sender photo 382 (or however else it chooses to render the BIMI logo in conjunction 383 with the message). 385 7.6. Message Classification 387 The successful validation of BIMI does NOT indicate that a message is 388 not spam, malware, or phishing. 390 It is expected that receivers undertake their usual message filtering 391 and classification steps, and take the results of these checks into 392 consideration when deciding if a BIMI Indicator should be shown to 393 the user. 395 If classification is preformed before BIMI is evaluated then a 396 receiver MAY CHOOSE to skip BIMI processing for that message, in this 397 case they SHOULD add a bimi=skipped entry to the Authentication- 398 Results header for that message, and SHOULD add a comment stating the 399 reasons for skipping BIMI processing. 401 If a message is classified as phishing or malware then the MUA SHOULD 402 NOT display the logo. 404 If a message is classified as spam (meaning that the message comes 405 from a known brand, but contains spammy content), then the email 406 receiver MAY choose not to display the logo. 408 8. Domain Reputation 410 Receivers are advised to consider incorporating local sources of 411 domain trust intelligence into the processes which ultimately 412 determine whether or not BIMI logos are displayed. Simply because a 413 sending domain passes BIMI requirements does not mean the images 414 should automatically be displayed in the MUA; a site may impose 415 further restrictions based on domain reputation. 417 One source of additional reputation intelligence could be a platform 418 that the email provider has created to calculate domain trust based 419 on historical traffic; another is an explicit list of trusted domains 420 that has been curated by an individual provider; a third is a list 421 that is purchased from a vendor that might be a pass/fail or a scored 422 list; another option is some mix of any of the previous three. 424 8.1. Rolling up based upon domain vs organizational domain 426 BIMI is designed to be able to work on selectors, and so in theory a 427 brand/domain could specify multiple BIMI logos and differentiate them 428 on a per-domain (per-selector) basis. The advantage for the brand is 429 that they can choose the image they want the user to see depending 430 upon various conditions (e.g., seasonal images, regional images, 431 etc.). 433 However, for an email receiver, it may be easier to roll up BIMI 434 logos on an organizational domain basis. One reason may be for the 435 purposes of reputation, another may be for simplifying management of 436 images. In this case, it would need to be made clear to brands that 437 this is how the loading of BIMI images works. This documentation 438 could live on a postmaster site, under technical documentation, or 439 other official page maintained by the receiver. It could then be 440 referred to when sending organizations ask about how to on-board to 441 BIMI at the receiver, and provide official guidance about the way it 442 works at the site. 444 If rolling up by organizational domain, then it may make sense to use 445 a "lowest common denominator" approach. That is, an organizational 446 domain must meet all the requirements for BIMI, rather than only a 447 subdomain. The reason for this is that if sub.brand.com gets an 448 image due to having strong authentication policies, but brand.com 449 does not, then this may cause confusion because a user may learn to 450 associate sub.brand.com and its image with brand.com; and if 451 brand.com can be spoofed even though sub.brand.com cannot, that can 452 lead to users becoming more susceptible to phishing from brand.com. 454 To alleviate this, receivers may wish to show logos only for domains 455 that have organizational domains with strong DMARC policies. Or, if 456 an organizational domain does not have a strong DMARC policy but a 457 subdomain does, then it may treat the organizational domain as if it 458 does have a strong DMARC policy so as to prevent a phisher or spammer 459 from impersonating the brand or any of its subdomains. 461 A strong DMARC policy may be defined as one which has some level of 462 enforcement. ie, a p=quarantine policy with an effective pct=100, or 463 a p=reject policy. 465 8.2. VMC Root of Trust 467 VMCs are verified back to their issuing Certificate Authority (CA). 468 Receivers may wish to maintain their own list of trusted CAs for BIMI 469 rather than relying on a generally available bundle of trusted Root 470 Certificates such as those distributed with browsers or operating 471 systems. The Authindicators Working Group will maintain a list of 472 known VMC Root CA Certificates to help bootstrap such a list. 474 9. BIMI Playbook Checklist 476 There are several factors to consider for email receivers on things 477 that can go wrong; below are a handful of considerations: 479 o Failing to verify a VMC 480 o Failing to extract an Indicator from a validated VMC 482 o Failing to validate a SVG against the recommended profile 484 o Failing to parse a gzipped SVG Indicator 486 o Failing to load a logo in the email client 488 o Failing to access the logo (e.g., permissions errors) 490 o Connectivity problems to the logo 492 o Failing to display a correct logo in the email client 494 o Having the wrong logo stored for a brand (i.e., uploading it to a 495 local store but associating it with the wrong brand) 497 o Caching a logo for too long after it has updated 499 There are many reasons why a logo may fail to load; having tools to 500 investigate (logs, headers in messages, internal documentation that 501 is clearly written, having the knowledge pushed out to multiple 502 escalation channels) is important for investigation. 504 10. Public documentation 506 10.1. Documentation For Brands: 508 It is ideal to publish the criteria that is used by your site to 509 determine when BIMI will be displayed. It is fine to say that you 510 use some internal domain reputation metrics as additional criteria to 511 determine whether or not a logo should be displayed, and it isn't 512 necessary to give away the exact nature of the algorithm other than 513 to say "You must maintain good sending practices." 515 If you use an explicit allow list, a site may want to list the 516 minimum requirements, and the method of applying to be listed. 517 Similarly, a provider may wish to state what type of activity will 518 revoke the decision to display logos previously approved. 520 10.2. Documentation For Users: 522 BIMI is not meant to instill additional trust in messages, and it is 523 important to make this known to your users. All messages, even those 524 with logos, should still be treated with (mild) skepticism, and any 525 action regarding the message should still be individually evaluated. 526 It's possible for a site that has a high trust value to become 527 compromised and send fraudulent messages that could compromise a 528 user's system. Ensure your customers have a place that documents 529 BIMI and demonstrates how to check messages for fraud. 531 11. Appendix 533 11.1. Glossary 535 o MUA - Mail User Agent - The application used to read messages by 536 the end user. This could be a thick client or a web-based 537 application. 539 o MTA - Mail Transfer Agent - Software used to transfer messages 540 between two systems, typically between two sites, using SMTP as 541 the protocol. 543 o SPF - Sender Policy Framework [1] - SPF is a framework that 544 designates which systems should be sending for a given domain. 545 This can be a list of IPs, CIDRs, or references to DNS records. 546 As the sender should be controlling their DNS, they should 547 understand which IPs should be sending as their domain. 549 o DKIM - DomainKeys Identified Mail [2] - DKIM is a system by which 550 a chosen set of headers, combined with the message contents, are 551 cryptographically signed, and then validated by the receiving 552 system. Using DNS, the receiving system can retrieve a public 553 key, and then validate the signature within the headers of a 554 message. When implemented properly, the systems responsible for 555 sending the messages for a given domain name should be the only 556 ones capable of creating messages that correctly validates. 558 o DMARC - Domain-based Message Authentication, Reporting, and 559 Conformance [3] - DMARC is a message authentication mechanism that 560 works with SPF and DKIM. The BIMI specification requires that a 561 message passes DMARC. In order for a message to pass DMARC, one 562 of SPF or DKIM must successfully validate, and the domain in the 563 From: address must align with the domain that passed SPF or DKIM. 565 o Alignment - Alignment refers to the organizational domain, as 566 defined by DMARC, of the domain in the From: address being the 567 same as the organizational domain that passed SPF or DKIM. For 568 example, baz.example.com has an organizational domain of 569 example.com; bar.foo.example.com also has an organizational domain 570 of example.com. It aligns with org.example.com, because both have 571 the same organizational domain. A definition of organizational 572 domain and methods of discovery may be found in the DMARC [4] RFC. 574 o MVA - Mark Verifying Authority - An entity that a receiver uses to 575 certify that the iconography that they intend to use with BIMI is 576 properly/legally licensed for their use. 578 o DRA - Dispute Resolution Authority - This organization will 579 moderate between two entities that believe they are both entitled 580 to use a logo. Receivers should then abide by the decision of the 581 DRA as it pertains to logo usage in the MUA. 583 o VMC - Verified Mark Certificate - An Extended Validation 584 Certificate is used in conjunction with BIMI to create a place 585 where information pertaining to iconography for a sending domain 586 can be securely verified. In the case of BIMI, hashes for an MVA- 587 approved set of iconography will be stored in a field within the 588 certificate. This should allow a receiver site to validate the 589 retrieved imagery before putting the BIMI image URI into the 590 message headers. 592 12. Contributors 594 TBD 596 13. References 598 The full BIMI verification spec can be found at: 599 602 Verified Mark Certificates Usage: 605 14. References 607 14.1. Normative References 609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 610 Requirement Levels", BCP 14, RFC 2119, 611 DOI 10.17487/RFC2119, March 1997, 612 . 614 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 615 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 616 May 2017, . 618 14.2. URIs 620 [1] https://tools.ietf.org/html/rfc7208 622 [2] https://tools.ietf.org/html/rfc6376 624 [3] https://tools.ietf.org/html/rfc7489 626 [4] https://tools.ietf.org/html/rfc7489 628 Authors' Addresses 630 Alex Brotman 631 Comcast 633 Email: alex_brotman@comcast.com 635 Terry Zink 636 Zink Magical Contraptions 638 Email: tzink@terryzink.com 640 Marc Bradshaw 641 Fastmail 643 Email: marc@fastmailteam.com