idnits 2.17.1 draft-brotman-ietf-bimi-guidance-05.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 (11 April 2022) is 740 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 119, but not defined Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: 13 October 2022 Zink Magical Contraptions 6 M. Bradshaw 7 Fastmail 8 11 April 2022 10 General Guidance for Implementing Branded Indicators for Message 11 Identification (BIMI) 12 draft-brotman-ietf-bimi-guidance-05 14 Abstract 16 This document is meant to provide guidance to various entities so 17 that they may implement Brand Indicators for Message Identification 18 (BIMI). This document is a companion to various other BIMI drafts, 19 which should first be consulted. 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 13 October 2022. 38 Copyright Notice 40 Copyright (c) 2022 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Revised BSD License text as 49 described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Revised BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Goals for BIMI . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Who should implement BIMI? . . . . . . . . . . . . . . . . . 4 58 3.1. Brands . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Receiver . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.3. MUA Authors . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.4. MTA Authors . . . . . . . . . . . . . . . . . . . . . . . 5 62 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 5. Receivers . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Site implementations . . . . . . . . . . . . . . . . . . 6 65 5.2. Validation of a BIMI message . . . . . . . . . . . . . . 6 66 5.2.1. BIMI processing requirements . . . . . . . . . . . . 7 67 5.2.2. Verified Mark Certificate (VMC) Validation . . . . . 8 68 5.3. Communicating BIMI results between the MTA and the MUA . 8 69 5.4. Image Retrieval . . . . . . . . . . . . . . . . . . . . . 8 70 5.5. Limited use of HTTP Redirects . . . . . . . . . . . . . . 9 71 5.6. TTL of cached images . . . . . . . . . . . . . . . . . . 9 72 6. MUA Authors . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Image Display . . . . . . . . . . . . . . . . . . . . . . 9 74 6.2. Security Concerns . . . . . . . . . . . . . . . . . . . . 9 75 6.3. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 10 76 7. Brands . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Logo Hosting Considerations . . . . . . . . . . . . . . . 10 78 7.2. CDN Considerations . . . . . . . . . . . . . . . . . . . 11 79 7.3. Domains listed in your evidence document . . . . . . . . 11 80 8. Logo Designers . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Known Issues . . . . . . . . . . . . . . . . . . . . . . 11 82 8.2. Adherence to SVG P/S . . . . . . . . . . . . . . . . . . 11 83 8.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 8.4. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 9. Basic flow example . . . . . . . . . . . . . . . . . . . . . 12 86 9.1. Message Classification . . . . . . . . . . . . . . . . . 12 87 10. Domain Reputation . . . . . . . . . . . . . . . . . . . . . . 13 88 10.1. Rolling up based upon domain vs organizational domain . 13 89 10.2. VMC Root of Trust . . . . . . . . . . . . . . . . . . . 14 90 11. BIMI Playbook Checklist . . . . . . . . . . . . . . . . . . . 14 91 12. Public documentation . . . . . . . . . . . . . . . . . . . . 15 92 12.1. Documentation For Brands: . . . . . . . . . . . . . . . 15 93 12.2. Documentation For Users: . . . . . . . . . . . . . . . . 15 94 13. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 13.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 16 96 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 97 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 98 16. Normative References . . . . . . . . . . . . . . . . . . . . 17 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 101 1. Introduction 103 The Brand Indicators for Message Identification (BIMI) specification 104 introduces a method by which Mail User Agent (MUA, e.g., an email 105 client) providers combine DMARC-based message authentication with 106 cryptographic methods to ensure the identity of a sender. If the 107 identity is ensured, the MUA can then retrieve sender-selected 108 iconography to display within the MUA. This displayed iconography 109 grants the sender brand impressions via the BIMI-capable MUA, and 110 should be a driving factor for the adoption of authenticated email. 112 1.1. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in 117 [BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 2. Goals for BIMI 122 As stated in other BIMI drafts, BIMI intends to advance email 123 authentication by granting a sending party brand impressions as long 124 as the message passes authentication mechanisms and meets other 125 receiver qualifications (reputation, encryption, allow listing, et 126 cetera). DMARC currently has wide adoption by some of the Internet's 127 larger brands, but there is still a long tail of small-to-medium size 128 brands (and many large ones) that do not have it. Furthermore, many 129 domains are not employing DMARC enforcement via quarantine or reject 130 policy, which may allow domain impersonation to continue. Because 131 BIMI provides a visual presence in the inbox, and because visual 132 impressions are desirable for brands, BIMI provides an incentive for 133 marketers to spur DMARC adoption, whereas a concern purely from 134 security may not. 136 3. Who should implement BIMI? 138 3.1. Brands 140 Organizations take great care to create and promote the image 141 associated with their brand. By implementing BIMI, and creating 142 additional impressions, an organization can foster a stronger tie 143 with customers. In exchange for positive authentication, and strong 144 DMARC policies, the MBP and MUA may show the associated logos with 145 those messages. It should be noted that the domain holder must 146 implement those strong policy on not just a sub-domain, but also the 147 Organizational Domain. 149 As a Brand holder, you may need to satisfy these requirements: 151 * Ability to alter DNS to host a new TXT record 153 * A web server to host one or two files, depending on your 154 implementation 156 * If you choose to obtain an evidence document, you will need a 157 person to act as a representative for your company 159 * The desire to have DMARC enforcement (quarantine/reject) policies 160 on both the organizational and sub-domains. (ex., example.com and 161 sub.example.com) 163 * In the DMARC record, pct must be absent or 100% 165 However, also note that BIMI may not be for every domain. For 166 example, it seems unlikely that a domain would want to implement BIMI 167 for person-to-person correspondence. Or if a domain is not meant to 168 send email, the domain holder may want to explicitly ensure the 169 domain is exempted from BIMI via the BIMI DNS record. 171 3.2. Receiver 173 If your site satisfies the requirements (#bimi-site-requirements), 174 this is likely a "yes". 176 As email has evolved over the past three decades, it is no longer a 177 medium of merely exchanging text, but of enabling people to build 178 rich experiences on top of it. BIMI provides an incentive for brands 179 to send email more securely because the desired behavior - a visual 180 imprint in the inbox - first requires DMARC adoption. 182 3.3. MUA Authors 184 The Mail User Agent (MUA) is ultimately responsible for displaying 185 BIMI logos. This could be an in-house/proprietary MUA, or something 186 more generally available. While the MUA may enable the display of 187 the logos, the responsibility for validating inbound messages lies 188 with the Receiver/MBP. MUA Authors should also allow users the 189 option to disable BIMI logo display. 191 3.4. MTA Authors 193 The receiving MTA at the destination is the system that is best 194 suited to evaluate message authentication, as well as the DMARC and 195 BIMI policies. The MTA would also be responsible for creating the 196 additional headers that the MUA is meant to utilize. In an ideal 197 world, all MTAs would support BIMI and allow the individual MBPs on 198 deploying BIMI. The MTA would also ideally allow the MBP to 199 alternately utilize a proxy instead of the direct URL retrieved from 200 the BIMI record or evidence document. 202 4. Terminology 204 The following terms are used throughout this document. 206 * MTA 208 * MUA 210 * DKIM 212 * SPF 214 * DMARC 216 * MBP 218 * Alignment 220 * Verified Mark Certificate (VMC) 222 * Recipient Domain 224 * Sending Domain 226 * MVA 228 For definitions of these terms, see the Appendix. 230 5. Receivers 232 5.1. Site implementations 234 In order for a site to correctly implement BIMI, the receiver must be 235 able to perform the following: 237 * Validate SPF 239 * Validate DKIM signatures 241 * Validate DMARC 243 * Discover and fetch a BIMI assertion record using DNS 245 * Fetch a SVG using HTTPS 247 * Validate a SVG using a profile 249 * Add Authentication-Results and BIMI-* Headers to a message 251 Optionally, for a site to correctly implement BIMI evidence document 252 (VMC is one example) verification, the receiver must be able to 253 perform the following: 255 * Fetch the document using HTTPS 257 * Validate the evidence document 259 * Extract a SVG from the evidence document 261 A site may wish to implement URI alteration and image caching for 262 hosted recipients. By implementing BIMI, a site agrees that through 263 some combination of trust mechanisms, it will instruct a BIMI-capable 264 MUA to display the image fetched from a URI within the message 265 headers. This URI is created after the MTA authenticates a message, 266 and is also (optionally) able to authenticate the evidence document 267 associated with the sending domain. Discussion of these trust 268 mechanisms is beyond the scope of this document. 270 5.2. Validation of a BIMI message 271 5.2.1. BIMI processing requirements 273 In the BIMI specification, a message MUST be authenticated via DMARC. 274 As stated in the DMARC draft, this requires that only one of DKIM or 275 SPF must successfully pass validation with alignment with the 276 organizational domain in the From: address. However, for additional 277 local security measures, a receiving site may choose to create 278 additional requirements for senders in order to verify BIMI (that is, 279 indicate to a downstream MUA that it is safe to load a BIMI logo in 280 the email client) 282 This may include, but is not limited to: 284 * Requiring both DKIM and SPF to validate and align with the 285 organizational domain in the From: address (whereas DMARC only 286 requires one of SPF or DKIM to align with the From: domain) 288 * SPF "strength" requirements (e.g., requiring "-all", disallowing 289 usage of "?all" or not allowing inclusion of overly large address 290 spaces) 292 * SMTP delivery via TLS 294 * Feedback Loop registration or other method of registration with 295 the receiving site 297 * Domain reputation via a DNS allow list or other reputation system 299 These localized requirements are at the discretion of the receiving 300 site. In general, the stricter the criteria, the less chance there 301 is of an MUA erroneously showing a logo and giving the wrong signal 302 to a user. 304 Upon receipt of an email, a receiver that implements BIMI should 305 remove or rename any previously existing BIMI-* headers other than 306 BIMI-Selector, as they may have come from an attacker (as long as the 307 BIMI-Selector is covered by the DKIM signature; if not, it should be 308 removed, renamed, or ignored). 310 Additionally: 312 * It may be useful to have messages exiting a site to have those 313 BIMI-* headers removed as well. 315 * It is useful for a site that has not implemented BIMI to remove 316 those headers so that an MUA that does make use of those headers 317 would not accidentally display a BIMI image when the message has 318 not been properly authenticated by the email receiver (even though 319 an MUA should not make use of BIMI headers and instead rely upon 320 settings from the mail store, it is possible that some MUAs will 321 nevertheless use headers without taking appropriate precautions). 323 5.2.2. Verified Mark Certificate (VMC) Validation 325 (Currently, see document in Reference below) 327 5.3. Communicating BIMI results between the MTA and the MUA 329 In order for a receiver that has implemented BIMI to notify an MUA 330 that it should display the images: 332 * An MTA must verify BIMI, and if it passes, add additional headers 333 containing the logo to be displayed. 335 The MUA must check to see if a message passed BIMI before loading the 336 BIMI image. 338 While the MTA MAY stamp BIMI-related information in the message 339 headers, they should not be relied upon by an MUA without additional 340 checks to make sure they were added by a trusted source, for example, 341 making sure the MTA strips existing headers on ingress, or by 342 checking for a bimi pass in a trusted Authentication-Results header. 344 5.4. Image Retrieval 346 A core part of the BIMI specification is that the MUA will retrieve 347 an image file to display for each BIMI-validated message. There are 348 multiple ways to accomplish this, for example: 350 * In its most basic setup, a BIMI-capable MUA could retrieve the 351 image file directly from the site specified in the BIMI-Location 352 header. 354 * A BIMI capable MTA will add a header containing the Base64 encoded 355 SVG of the image file. The MUA can use this header to retrieve 356 the already validated image file for display. This is the 357 recommended method of image retrieval as the work of retrieval and 358 validation has already been done by the MTA. A consideration for 359 this method may be the additional storage requirements for adding 360 a base64-encoded version of the SVG, where the original file could 361 be between 1 and 30 kilobytes, and encoding may add 35% to that 362 size. 364 * Other providers may choose to cache the associated images in a 365 local store which could be used as the BIMI resource address in 366 the headers of a BIMI-approved message in a sort of proxy 367 configuration. 369 5.5. Limited use of HTTP Redirects 371 * Receivers may choose not to follow HTTP redirects when retrieving 372 images or evidence documents, or may choose to follow only a 373 limited number of redirects. 375 * When setting up BIMI, senders should eliminate, or limit the use 376 of HTTP redirects to avoid images being unretrievable by receivers 377 who either do not support the use of HTTP redirection, or have 378 limited its use. 380 5.6. TTL of cached images 382 In some circumstances it is necessary to cache the images that an MUA 383 would want to load. For example, if a domain owner has a short TTL 384 time, it would force the MUA to look it up in an unreasonably short 385 period of time. In this case, a receiver may want to set its own 386 TTL. 388 One option is to set it to several hours, or a day; another option is 389 to set the TTL to the same as the expiration period in the evidence 390 document that contains the BIMI image. The downside is that the 391 caching mechanism might need to check for certificate revocation, and 392 then re-fetch images. 394 6. MUA Authors 396 6.1. Image Display 398 Although BIMI does not define an aspect ratio for Brand Indicators it 399 is expected that the majority of receivers will display them in a 400 square or circular space. Is it recommended to brands that their 401 Indicators should be constructed to display in a 1:1 aspect ratio, 402 receivers should design the user interface display for BIMI 403 Indicators with this in mind. 405 6.2. Security Concerns 407 Receivers should consider the impact of XML bomb or "billion laughs" 408 Denial of Service attacks when handling XML documents such as when 409 validating SVG documents. CVE-2003-1564 (https://cve.mitre.org/cgi- 410 bin/cvename.cgi?name=CVE-2003-1564) is an example of this attack. 412 When validating XML documents, receivers should consider the security 413 and privacy implications of retrieving external entries referenced in 414 those documents. 416 6.3. Privacy Concerns 418 There is some concern that the retrieval of the iconography could 419 result in a privacy leak. 420 As the images are retrieved, it's possible that the image provider 421 could track the retrieving system in some way. This has implications 422 whether it be the sender or provider that is hosting the image. For 423 example, a sender could include a singular selector for a single 424 recipient, or a provider could append a tracking string to the image 425 URI in the header. 427 A receiver may choose to track the number of selectors an 428 organizational domain is permitted to use and deny processing if this 429 exceeds a defined limit. Similarly, a receiver may choose to track 430 and limit distinct Indicator URLs. 432 MTAs are encouraged to cache BIMI Records, evidence documents, and 433 Indicators to limit tracking. 435 MUAs are encouraged to extract Indicators from the BIMI-Indicator 436 header rather than retrieving them directly from the source, as doing 437 so will limit any data exposure to the MTA processing the message. 438 The BIMI approved SVG profile prohibits an SVG from loading external 439 elements, this removes the risk of tracking when an Indicator is 440 shown in the client. 442 An in-depth discussion of all the potential privacy leaks with 443 respect to loading or embedding images is outside the scope of this 444 document. 446 7. Brands 448 7.1. Logo Hosting Considerations 450 The logo you wish to associate with your brand can be hosted 451 anywhere, not necessarily within the domain that will be used to send 452 the messages. Doing so may make it easier to associate during 453 inspection, though it is understood that not all entities have a web 454 server at the domain associated with their email messages. 456 7.2. CDN Considerations 458 If the logo is behind a CDN (Content Delivery Network) this may 459 prevent automated systems from reaching the resource. The automated 460 systems may not appear to be a proper browser experience, and would 461 not be able to correctly respond to a challenge that the CDN may use 462 to protect a site, and therefore unable to retrieve the logo file. 463 If possible, those BIMI logos/resources should be marked as 464 unprotected, allowing any who request the resource to do so without 465 possibility of a challenge. 467 7.3. Domains listed in your evidence document 469 While obtaining an evidence document, an entity is expected to 470 provide at least one domain name. There exists the opportunity to 471 list additional domains in the "SAN" field of the certificate. These 472 domains may or may not match the 5322.From domain, but must match the 473 domain being used in the BIMI assertion record. When using the 474 organizational domain, other third-level domains can take advantage 475 of the evidence document as well. 476 Within the core specification, it is discussed how the evaluator 477 should look at the original domain being used, as well as the 478 Organizational Domain. 480 8. Logo Designers 482 8.1. Known Issues 484 8.2. Adherence to SVG P/S 486 There may be a few issues that designers may experience when trying 487 to adhere to SVG P/S. 489 * SVG P/S is based on SVG Tiny 1.2, which does not allow for certain 490 types of gradients. When trying to convert/save as SVG Tiny 1.2, 491 it will typically result in an embedded raster file. This is not 492 compliant with SVG P/S, and could result in display issues. 494 * When exporting to SVG Tiny 1.2 with Adobe Illustrator, the 495 application will insert x and y attributes within the svg element. 496 These need to be removed to comply with SVG P/S. 498 8.3. Tools 500 8.4. Caveats 501 9. Basic flow example 503 One sample implementation of BIMI by a receiver, who does everything 504 on-the-fly, is as following: 506 * Upon receipt of a message, the receiver checks to see if the 507 message passes aligned-SPF or DKIM, and DMARC, and ensures that 508 the sending domain has a DMARC policy of quarantine or reject per 509 local receiver policy, while properly applying the appropriate 510 DMARC policy to the message. 512 * If the message passes prior checks, the receiver will then check 513 to see if the domain in the From: address has a BIMI record (or, 514 if the message has a BIMI-Selector header that is covered by the 515 DKIM-Signature, uses that to do the BIMI query in DNS). 517 * If a BIMI record is found, the receiver then retrieves the VMC 518 from the location that the BIMI record points to, and attempts to 519 verify the VMC using a trusted root certificate. . 521 * Upon successful verification of the VMC, the receiver extracts the 522 verified image from the VMC. If the SVG also passes the SVG 523 validation steps then this is a successful BIMI verification. 525 * If the BIMI verification fails then the MTA must not indicate to 526 the MUA to show a BIMI image. The MUA MAY show a default image 527 such as a set of initials, or unidentified sender. 529 * The email receiver then does the rest of its anti-spam, anti- 530 malware, and anti-phishing checks as discussed in Message 531 Classification (#message-classification) below. 533 * The email receiver then adds the relevant Authentication-Results 534 and BIMI-* headers to the message to signal to the downstream 535 email client that the message passed BIMI and that is safe to load 536 the logo. 538 * Eventually, the MUA checks the BIMI-* headers, decodes the image 539 in the BIMI-Indicator header, and displays it as the sender photo 540 (or however else it chooses to render the BIMI logo in conjunction 541 with the message). 543 9.1. Message Classification 545 The successful validation of BIMI does NOT indicate that a message is 546 not spam, malware, or phishing. 548 It is expected that receivers undertake their usual message filtering 549 and classification steps, and take the results of these checks into 550 consideration when deciding if a BIMI Indicator should be shown to 551 the user. 553 If classification is performed before BIMI is evaluated then a 554 receiver MAY CHOOSE to skip BIMI processing for that message, in this 555 case they SHOULD add a bimi=skipped entry to the Authentication- 556 Results header for that message, and SHOULD add a comment stating the 557 reasons for skipping BIMI processing. 559 If a message is classified as phishing or malware then the MUA SHOULD 560 NOT display the logo. 562 If a message is classified as spam (meaning that the message comes 563 from a known brand, but contains spammy content), then the email 564 receiver MAY choose not to display the logo. 566 10. Domain Reputation 568 Receivers are advised to consider incorporating local sources of 569 domain trust intelligence into the processes which ultimately 570 determine whether or not BIMI logos are displayed. Simply because a 571 sending domain passes BIMI requirements does not mean the images 572 should automatically be displayed in the MUA; a site may impose 573 further restrictions based on domain reputation. 575 One source of additional reputation intelligence could be a platform 576 that the email provider has created to calculate domain trust based 577 on historical traffic; another is an explicit list of trusted domains 578 that has been curated by an individual provider; a third is a list 579 that is purchased from a vendor that might be a pass/fail or a scored 580 list; another option is some mix of any of the previous three. 582 10.1. Rolling up based upon domain vs organizational domain 584 BIMI is designed to be able to work on selectors, and so in theory a 585 brand/domain could specify multiple BIMI logos and differentiate them 586 on a per-domain (per-selector) basis. The advantage for the brand is 587 that they can choose the image they want the user to see depending 588 upon various conditions (e.g., seasonal images, regional images, 589 etc.). 591 However, for an email receiver, it may be easier to roll up BIMI 592 logos on an organizational domain basis. One reason may be for the 593 purposes of reputation, another may be for simplifying management of 594 images. In this case, it would need to be made clear to brands that 595 this is how the loading of BIMI images works. This documentation 596 could live on a postmaster site, under technical documentation, or 597 other official page maintained by the receiver. It could then be 598 referred to when sending organizations ask about how to on-board to 599 BIMI at the receiver, and provide official guidance about the way it 600 works at the site. 602 If rolling up by organizational domain, then it may make sense to use 603 a "lowest common denominator" approach. That is, an organizational 604 domain must meet all the requirements for BIMI, rather than only a 605 sub-domain. The reason for this is that if sub.brand.com gets an 606 image due to having strong authentication policies, but brand.com 607 does not, then this may cause confusion because a user may learn to 608 associate sub.brand.com and its image with brand.com; and if 609 brand.com can be spoofed even though sub.brand.com cannot, that can 610 lead to users becoming more susceptible to phishing from brand.com. 612 To alleviate this, receivers may wish to show logos only for domains 613 that have organizational domains with strong DMARC policies. Or, if 614 an organizational domain does not have a strong DMARC policy but a 615 sub-domain does, then it may treat the organizational domain as if it 616 does have a strong DMARC policy so as to prevent a phisher or spammer 617 from impersonating the brand or any of its sub-domains. 619 A strong DMARC policy may be defined as one which has some level of 620 enforcement. For example, a p=quarantine policy with an effective 621 pct=100, or a p=reject policy. 623 10.2. VMC Root of Trust 625 VMCs are verified back to their issuing Mark Verifying Authority 626 (MVA). Receivers may wish to maintain their own list of trusted CAs 627 for BIMI rather than relying on a generally available bundle of 628 trusted Root Certificates such as those distributed with browsers or 629 operating systems. The AuthIndicators Working Group will maintain a 630 list of known VMC Root CA Certificates to help bootstrap such a list. 632 11. BIMI Playbook Checklist 634 There are several factors to consider for email receivers on things 635 that can go wrong; below are a handful of considerations: 637 * Failing to verify a VMC 639 * Failing to extract an Indicator from a validated VMC 641 * Failing to validate a SVG against the recommended profile 643 * Failing to parse a gzipped SVG Indicator 644 * Failing to load a logo in the email client 646 * Failing to access the logo (e.g., permissions errors) 648 * Connectivity problems to the logo 650 * Failing to display a correct logo in the email client 652 * Having the wrong logo stored for a brand (i.e., uploading it to a 653 local store but associating it with the wrong brand) 655 * Caching a logo for too long after it has updated 657 There are many reasons why a logo may fail to load; having tools to 658 investigate (logs, headers in messages, internal documentation that 659 is clearly written, having the knowledge pushed out to multiple 660 escalation channels) is important for investigation. 662 12. Public documentation 664 12.1. Documentation For Brands: 666 It is ideal to publish the criteria that is used by your site to 667 determine when BIMI will be displayed. It is fine to say that you 668 use some internal domain reputation metrics as additional criteria to 669 determine whether or not a logo should be displayed, and it isn't 670 necessary to give away the exact nature of the algorithm other than 671 to say "You must maintain good sending practices." 673 If you use an explicit allow list, a site may want to list the 674 minimum requirements, and the method of applying to be listed. 675 Similarly, a provider may wish to state what type of activity will 676 revoke the decision to display logos previously approved. 678 12.2. Documentation For Users: 680 BIMI is not meant to instill additional trust in messages, and it is 681 important to make this known to your users. All messages, even those 682 with logos, should still be treated with (mild) skepticism, and any 683 action regarding the message should still be individually evaluated. 684 It's possible for a site that has a high trust value to become 685 compromised and send fraudulent messages that could compromise a 686 user's system. Ensure your customers have a place that documents 687 BIMI and demonstrates how to check messages for fraud. 689 13. Appendix 691 13.1. Glossary 693 * MUA - Mail User Agent - The application used to read messages by 694 the end user. This could be a thick client or a web-based 695 application. 697 * MTA - Mail Transfer Agent - Software used to transfer messages 698 between two systems, typically between two sites, using SMTP as 699 the protocol. 701 * SPF - Sender Policy Framework (https://tools.ietf.org/html/ 702 rfc7208) - SPF is a framework that designates which systems should 703 be sending for a given domain. This can be a list of IPs, CIDRs, 704 or references to DNS records. As the sender should be controlling 705 their DNS, they should understand which IPs should be sending as 706 their domain. 708 * DKIM - DomainKeys Identified Mail (https://tools.ietf.org/html/ 709 rfc6376) - DKIM is a system by which a chosen set of headers, 710 combined with the message contents, are cryptographically signed, 711 and then validated by the receiving system. Using DNS, the 712 receiving system can retrieve a public key, and then validate the 713 signature within the headers of a message. When implemented 714 properly, the systems responsible for sending the messages for a 715 given domain name should be the only ones capable of creating 716 messages that correctly validates. 718 * DMARC - Domain-based Message Authentication, Reporting, and 719 Conformance (https://tools.ietf.org/html/rfc7489) - DMARC is a 720 message authentication mechanism that works with SPF and DKIM. 721 The BIMI specification requires that a message passes DMARC. In 722 order for a message to pass DMARC, one of SPF or DKIM must 723 successfully validate, and the domain in the From: address must 724 align with the domain that passed SPF or DKIM. 726 * Alignment - Alignment refers to the organizational domain, as 727 defined by DMARC, of the domain in the From: address being the 728 same as the organizational domain that passed SPF or DKIM. For 729 example, baz.example.com has an organizational domain of 730 example.com; bar.foo.example.com also has an organizational domain 731 of example.com. It aligns with org.example.com, because both have 732 the same organizational domain. A definition of organizational 733 domain and methods of discovery may be found in the DMARC 734 (https://tools.ietf.org/html/rfc7489) RFC. 736 * MVA - Mark Verifying Authority - An entity that a receiver uses to 737 certify that the iconography that they intend to use with BIMI is 738 properly/legally licensed for their use. 740 * DRA - Dispute Resolution Authority - This organization will 741 moderate between two entities that believe they are both entitled 742 to use a logo. Receivers should then abide by the decision of the 743 DRA as it pertains to logo usage in the MUA. 745 * VMC - Verified Mark Certificate - An Extended Validation 746 Certificate is used in conjunction with BIMI to create a place 747 where information pertaining to iconography for a sending domain 748 can be securely verified. In the case of BIMI, hashes for an MVA- 749 approved set of iconography will be stored in a field within the 750 certificate. This should allow a receiver site to validate the 751 retrieved imagery before putting the BIMI image URI into the 752 message headers. 754 14. Contributors 756 TBD 758 15. References 760 The full BIMI verification spec can be found at: 761 https://github.com/authindicators/rfc-brand-indicators-for-message- 762 identification (https://github.com/authindicators/rfc-brand- 763 indicators-for-message-identification) 765 Verified Mark Certificates Usage: 767 http://bimigroup.org/resources/VMC_Guidelines_latest.pdf 768 (http://bimigroup.org/resources/VMC_Guidelines_latest.pdf) 770 16. Normative References 772 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 773 Requirement Levels", BCP 14, RFC 2119, 774 DOI 10.17487/RFC2119, March 1997, 775 . 777 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 778 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 779 May 2017, . 781 Authors' Addresses 782 Alex Brotman 783 Comcast 784 Email: alex_brotman@comcast.com 786 Terry Zink 787 Zink Magical Contraptions 788 Email: tzink@terryzink.com 790 Marc Bradshaw 791 Fastmail 792 Email: marc@fastmailteam.com