idnits 2.17.1 draft-brotman-ietf-bimi-guidance-00.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 (February 6, 2019) is 1878 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: 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 102, but not defined Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 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, Inc 4 Intended status: Best Current Practice T. Zink 5 Expires: August 10, 2019 Zink Magical Contraptions 6 February 6, 2019 8 Receivers Guidance for Implementing Branded Indicators for Message 9 Identification (BIMI) 10 draft-brotman-ietf-bimi-guidance-00 12 Abstract 14 This document is meant to assist receivers or other mailbox providers 15 by providing guidance to implementing Brand Indicators for Message 16 Identification (BIMI). This document is a companion to the main BIMI 17 drafts which should first be consulted and reviewed. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 10, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Goals for BIMI . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Should your site implement BIMI? . . . . . . . . . . . . . . 3 57 3.1. If your site satisfies the requirements, this is likely a 58 "yes". . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Site implementations . . . . . . . . . . . . . . . . . . . . 4 60 5. Validation of a BIMI message . . . . . . . . . . . . . . . . 4 61 5.1. BIMI Site Requirements . . . . . . . . . . . . . . . . . 5 62 5.2. BIMI Certificate Validation . . . . . . . . . . . . . . . 6 63 6. Communicating BIMI results between the MTA and the MUA . . . 6 64 6.1. Image Retrieval . . . . . . . . . . . . . . . . . . . . . 6 65 6.2. TTL of cached images . . . . . . . . . . . . . . . . . . 7 66 6.3. Privacy Concerns . . . . . . . . . . . . . . . . . . . . 7 67 6.4. Basic flow example . . . . . . . . . . . . . . . . . . . 7 68 7. Domain Reputation . . . . . . . . . . . . . . . . . . . . . . 8 69 7.1. Rolling up based upon domain vs organizational domain . . 9 70 8. Working with MVAs . . . . . . . . . . . . . . . . . . . . . . 10 71 8.1. Resolving disputes . . . . . . . . . . . . . . . . . . . 11 72 9. Troubleshooting BIMI . . . . . . . . . . . . . . . . . . . . 11 73 10. Public documentation . . . . . . . . . . . . . . . . . . . . 12 74 10.1. For Brands: . . . . . . . . . . . . . . . . . . . . . . 12 75 10.2. For users: . . . . . . . . . . . . . . . . . . . . . . . 12 76 11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 11.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 13 78 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 79 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 14. Normative References . . . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 83 1. Introduction 85 The Brand Indicators for Message Identification (BIMI) specification 86 introduces a method by which Mail User Agent (MUA, e.g, an email 87 client) providers combine DMARC-based message authentication in 88 addition to cryptographic methods to ensure the identity of a sender, 89 and then to retrieve iconography that the sender has selected. The 90 iconography can then be displayed within the MUA. The displayed 91 iconography grants the sender brand impressions via the BIMI-capable 92 MUA, and should be a driving factor for the adoption of authenticated 93 email. 95 1.1. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in 100 [BCP 14] [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Goals for BIMI 105 As stated in other BIMI drafts, BIMI intends to advance email 106 authentication by granting a sending party brand impressions as long 107 as the message passes authentication mechanisms and and meets other 108 receiver qualifications (reputation, encryption, whitelisting, et 109 cetera). DMARC currently has wide adoption by some of the 110 InternetaEUR[TM]s larger brands, but there is still a long tail of 111 small-to-medium size brands (and many large ones) that do not have 112 it. Because BIMI provides a visual presence in the inbox, and 113 because visual impressions are desirable for brands, BIMI provides an 114 incentive for marketers to spur DMARC adoption, whereas a concern 115 purely from security may not. 117 3. Should your site implement BIMI? 119 3.1. If your site satisfies the requirements, this is likely a "yes". 121 As email has evolved over the past three decades, it is no longer a 122 medium of merely exchanging text, but of enabling people to build 123 rich experiences on top of it. BIMI provides an incentive for brands 124 to send email more securely because the desired behavior - a visual 125 imprint in the inbox - first requires DMARC adoption. 127 #Terminology 129 The following terms are used throughout this document. 131 o MTA 133 o MUA 135 o DKIM 137 o SPF 139 o DMARC 141 o Alignment 142 o BIMI Certificates 144 o IMAP 146 o Recipient Domain 148 o Sending Domain 150 o MVA 152 o FBL 154 For definitions of these terms, see the Appendix. 156 4. Site implementations 158 In order for a site to correctly implement BIMI, the receiver must be 159 able to perform the following: 161 o Validate SPF 163 o Validate DKIM signatures 165 o Validate DMARC 167 o Validate a BIMI Certificate (a new kind of Extended Validation 168 (EV) certificate) 170 o Fetch an image located at an https location 172 o For some receivers, an additional requirement is a BIMI-capable 173 IMAP daemon, or another method of a mail server signaling to an 174 MUA that it is safe to load a BIMI image , as well as securely 175 pointing to the BIMI location to pull it from. 177 A site may wish to implement URI alteration and image caching for 178 hosted recipients. By implementing BIMI, a site agrees that through 179 some combination of trust mechanisms, it will instruct a BIMI-capable 180 MUA to display the image fetched from a URI within the message 181 headers. This URI is created after the MTA authenticates a message, 182 and is also able to authenticate the BIMI certificate associated with 183 the sending domain. 185 5. Validation of a BIMI message 186 5.1. BIMI Site Requirements 188 In the BIMI specification, a message MUST be authenticated via DMARC. 189 As stated in the DMARC draft, this requires that only one of DKIM or 190 SPF must successfully pass validation. However, for additional local 191 security measures, a receiving site may create additional 192 requirements for senders in order to verify BIMI (that is, indicate 193 to a downstream MUA that it is safe to load a BIMI logo in the email 194 client) 195 This may include, but is not limited to: 197 o Requiring both DKIM and SPF to validate and align with the 198 organizational domain in the From: address (whereas DMARC only 199 requires one of SPF or DKIM to align with the From: domain) 201 o A DMARC policy of quarantine or reject 203 o SPF "strength" requirements (e.g., requiring "-all", disallowing 204 usage of "?all" or "+all", or not allowing inclusion of overly 205 large address spaces) 207 o SMTP delivery via TLS 209 o Feedback Loop registration or other method of registration with 210 the receiving site. 212 These localized requirements are at the discretion of the receiving 213 site. In general, the stricter the criteria, the less chance there 214 is of an MUA erroneously showing a logo and giving the wrong signal 215 to a user. 217 Upon receipt of an email, a receiver that implements BIMI should 218 remove or rename any previously existing BIMI-* headers other than 219 BIMI-Selector, as they may have come from an attacker (as long as the 220 BIMI-Selector is covered by the DKIM signature; if not, it should be 221 removed, renamed, or ignored). 223 Additionally: 225 o It may be useful to have messages exiting a site to have those 226 BIMI-* headers removed as well. 228 o It is useful for a site that has not implemented BIMI to remove 229 those headers so that an MUA that does make use of those headers 230 would not accidentally display a BIMI image when the message has 231 not been properly authenticated by the email receiver (even though 232 an MUA should not make use of BIMI headers and instead rely upon 233 settings from the mailstore, it is possible that some MUAs will 234 nevertheless use headers without taking appropriate precautions). 236 5.2. BIMI Certificate Validation 238 (Currently, see document in Reference below) 240 6. Communicating BIMI results between the MTA and the MUA 242 In order for a receiver that has implemented BIMI to notify an MUA 243 that it should display the images: 245 o An MTA must verify BIMI and if successful, write to the mail store 246 (where the messages are saved) that the message passed BIMI, and 247 it is safe to load the logo. For example, in an IMAP mailstore, a 248 flag on the message could be set that indicates that the message 249 passed BIMI, and a second flag that tells the MUA where to get the 250 BIMI logo from. 252 o When displaying a message, the MUA does not look for any BIMI 253 headers stamped by the MTA, but instead relies upon the mailstore 254 flags or message properties that a message passed BIMI, and use 255 that to decide show the logo. The MUA then pulls the required 256 image and displays it as appropriate. 258 Alternatively, the MUA may also look for the flag in the mailstore 259 and then attempt to extract the key/value pairs from the BIMI- 260 Location headers. In either case, the MUA must first check to see if 261 a message passed BIMI before loading the 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. 266 6.1. Image Retrieval 268 A core part of the BIMI specification is that the MUA will retrieve 269 an image file to display for each BIMI-validated message. There are 270 multiple ways to accomplish this, for example: 272 o In its most basic setup, a BIMI-capable MUA could retrieve that 273 image file directly from the site specified in the BIMI record. 275 o Other providers may choose to cache the associated images in a 276 local store which could be used as the BIMI resource address in 277 the headers of a BIMI-approved message in a sort of proxy 278 configuration. 280 6.2. TTL of cached images 282 In some circumstances it is necessary to cache the images that an MUA 283 would want to load. For example, if a domain owner has a short TTL 284 time, it would force the MUA to look it up in an unreasonably short 285 period of time. In this case, a receiver may want to set its own 286 TTL. 288 One option is to set it to several hours, or a day; another option is 289 to set the TTL to the same as the expiration period in the BIMI 290 certificate that points to the BIMI image. The downside is that the 291 caching mechanism might need to check for certificate revocation, and 292 then re-fetch images. 294 6.3. Privacy Concerns 296 There is some concern that the retrieval of the iconography could 297 result in a privacy leak. 298 As the images are retrieved, it's possible that the image provider 299 could track the retrieving system in some way. This has implications 300 whether it be the sender or provider that is hosting the image. For 301 example, a sender could include a singular selector for a single 302 recipient, or a provider could append a tracking string to the image 303 URI in the header. 305 An in-depth discussion of all the potential privacy leaks with 306 respect to loading or embedding images is outside the scope of this 307 document. 309 6.4. Basic flow example 311 One sample implementation of BIMI by a receiver, who does everything 312 on-the-fly, is as following: 314 o An email receiver has established a relationship with several 315 MVAs, trusts them, and has received their public keys for 316 verifying BIMI certificates. The email receiver makes these keys 317 available to its mail servers (e.g., by distributing local copies 318 to each server). [NOTE: Use of MVA above per Thede] 320 o Upon receipt of a message, the receiver checks to see if the 321 message passes aligned-SPF or DKIM, and DMARC, and ensures that 322 the sending domain has a DMARC policy of "quarantine" or "reject" 323 per local receiver policy, while properly applying the appropriate 324 DMARC policy to the message. 326 o If the message passes prior checks, the receiver will then check 327 to see if the domain in the From: address has a BIMI record (or, 328 if the message has a BIMI-Selector header that is covered by the 329 DKIM-Signature, uses that to do the BIMI query in DNS). 331 o If a BIMI record is found, the receiver then retrieves the BIMI 332 certificate from the location that the BIMI record points to, and 333 attempts to verify the BIMI cert with each public key it has from 334 the MVAs that it works with. 336 o Upon successful verification of the cert, the receiver checks to 337 see if the signed image hash in the BIMI cert matches any of the 338 hashes of the images that the BIMI record points to (the receiver, 339 in this instance, is not storing any of the images locally, but 340 instead is downloading them on-the-fly). If a hash of a 341 downloaded image from the BIMI record matches the hash in the BIMI 342 cert, this is a successful BIMI verification. 344 o If the BIMI verification does not verify, then the MTA must not 345 indicate to the MUA to show a BIMI image. The MUA MAY show a 346 default image such as a set of initials, or unidentified sender. 348 o The email receiver then does the rest of its anti-spam, anti- 349 malware, and anti-phishing checks (these checks may be performed 350 before BIMI is verified). If a message fails a phishing or 351 malware checks, the email receiver must not say the message passed 352 BIMI. If a message is neither malware nor phishing but is 353 detected as spam (meaning that the message comes from a known 354 brand, but contains spammy content), then the email receiver may 355 optionally say that the message passed BIMI (and therefore a 356 receiver should show the image) but it is up to the receiver. 358 o The email receiver then sets either the appropriate IMAP flags, or 359 other mailstore flag, or other message property that signals to a 360 downstream email client that the message passed BIMI and is safe 361 to load the logo, along with a pointer to the logo (e.g., to the 362 https location specified in the BIMI record). 364 o What eventually happens is the email client then looks at the 365 flags set by the email receiver (MTA). If the flags are set to 366 show a BIMI logo, then the email client downloads the image and 367 displays it in the sender photo (or however else it chooses to 368 render the BIMI logo in conjunction with the message). 370 7. Domain Reputation 372 Receivers are advised to consider incorporating local sources of 373 domain trust intelligence into the processes which ultimately 374 determine whether or not BIMI logos are displayed. Simply because a 375 sending domain passes BIMI requirements does not mean the images 376 should automatically be displayed in the MUA; a site may impose 377 further restrictions based on domain reputation. 379 One source of additional reputation intelligence could be a platform 380 that the email provider has created to calculate domain trust based 381 on historical traffic; another is an explicit list of trusted domains 382 that has been curated by an individual provider; a third is a list 383 that is purchased from a vendor that might be a pass/fail or a scored 384 list; another option is some mix of any of the previous three. 386 7.1. Rolling up based upon domain vs organizational domain 388 BIMI is designed to be able to work on selectors, and so in theory a 389 brand/domain could specify multiple BIMI logos and differentiate them 390 on a per-domain (per-selector) basis. The advantage for the brand is 391 that they can choose the image they want the user to see depending 392 upon various conditions (e.g., seasonal images, regional images, 393 etc.). 395 However, for an email receiver, it may be easier to roll up BIMI 396 logos on an organizational domain basis. One reason may be for the 397 purposes of reputation, another may be for simplifying management of 398 images. In this case, it would need to be made clear to brands that 399 this is how the loading of BIMI images works. This documentation 400 could live on a postmaster site, under technical documentation, or 401 other official page maintained by the receiver. It could then be 402 referred to when sending organizations ask about how to on-board to 403 BIMI at the receiver, and provide official guidance about the way it 404 works at the site. 406 If rolling up by organizational domain, then it may make sense to use 407 a "lowest common denominator" approach. That is, an organizational 408 domain must meet all the requirements for BIMI, rather than only a 409 subdomain. The reason for this is that if sub.brand.com gets an 410 image due to having strong authentication policies, but brand.com 411 does not, then this may cause confusion because a user may learn to 412 associate sub.brand.com and its image with brand.com; and if 413 brand.com can be spoofed even though sub.brand.com cannot, that can 414 lead to users becoming more susceptible to phishing from brand.com. 416 To alleviate this, receivers may wish to show logos only for domains 417 that have organizational domains with strong DMARC policies. Or, if 418 an organizational domain does not have a strong DMARC policy but a 419 subdomain does, then it may treat the organizational domain as if it 420 does have a strong DMARC policy so as to prevent a phisher or spammer 421 from impersonating the brand or any of its subdomains. 423 8. Working with MVAs 425 Email receivers need to know whether or not itaEUR[TM]s safe to 426 download and display an image. That is, an attacker could go through 427 the trouble of creating a BIMI logo and uploading it, but the logo 428 may look visually similar to a real brand. For example, a spammer or 429 phisher could create a lookalike domain for a well-known brand such 430 as Paypal, then copy/paste (or slightly modify) the logo. 432 To prevent this, an email receiver could choose to verify logos of 433 known brands by themselves (do it all in-house) and establish its own 434 internal processes, or it could use a Mark Verifying Authority (MVA). 435 The receiver could then outsource the maintenance of the list of 436 trusted brands to the MVA, and simply download the list of brands and 437 images from the MVA and display the logos in its email clients. 439 However, even here a receiver would need to exercise caution. It 440 needs to ensure that MVAs follow best practices, respond to 441 complaints, and do a good job of vetting brands. If users ultimately 442 end up getting phished because they trust signals in the email 443 client, then it is the email receiver that will suffer the brunt of 444 the complaints and loss of reputation, rather than the MVA. 446 Therefore, an email receiver still needs to track complaints from its 447 users, especially with respect to phishing and impersonation, and 448 then send the feedback back to the MVA. If an MVA still generates 449 too many complaints, this could be indicative of a rogue MVA (one 450 that intentionally signs up malicious accounts), or a 451 aEURoesloppyaEUR MVA (one with internal processes that not 452 rigorous enough, or are designed to maximize revenue at the cost of 453 lax security). 455 An email receiver should use multiple MVAs to reduce the risk of 456 becoming too reliant upon a single MVA in case they have to stop 457 using it, and therefore lose many dozens, hundreds, or thousands of 458 images with no replacement and thereby contributing to user 459 dissatisfaction confusion. Furthermore, because MVAs may be revoked, 460 brands may wish to diversify their own risk by getting certified by 461 at least two MVAs. The reason for doing this is that if the MVA they 462 use ever gets revoked by an email receiver because of its bad 463 practices, then their own brand will suffer penalties (not having a 464 logo displayed) despite never having done anything wrong. By 465 researching multiple MVAs, a brand can reduce the chances that losing 466 one by a receiver affects their brand. 468 For this reason, brands are encouraged to get certified at multiple 469 MVAs, and receivers are encouraged to use multiple MVAs. 471 8.1. Resolving disputes 473 From time to time, disputes may arise between brands where one brand 474 says that another is infringing on its logo. 476 A brand owner would want to have all email receivers stop showing 477 logos for the infringing brand because it could damage its own 478 brandaEUR[TM]s reputation. However, an email receiver is not 479 necessarily in a good position to determine what constitutes 480 legitimate usage of a logo, nor determine ownership of a logo, nor 481 may want the legal risk associated with making this determination. 483 Therefore, email receivers are strongly encouraged to partner with 484 Dispute Resolution Agencies. These agencies specialize in copyright 485 infringement resolution. An affected party would then contact the 486 Dispute Resolution Agency, rather than the email receiver, who would 487 then make the decision about if use of the logo were legitimate. 488 Then, they would publish the result of the dispute publicly where it 489 could be viewed by anyone. 491 MVAs should respect the decision of the courts and any brand found to 492 be infringing ought to be removed from their list of domains for 493 which they load BIMI logos for. The issuing MVA of the infringing 494 brandaEUR[TM]s BIMI Certificate should formally revoke it. However, 495 this is not guaranteed in the case of a rogue MVA or a sloppy MVA. 496 Therefore, email receivers should also pay attention to the Dispute 497 Resolution Agencies, and any results that they say are infringing 498 should be prevented from loading in their email clients. The email 499 receiver should also keep track of how often disputes occur and are 500 found against various MVAs, as an MVA with too many disputes ruled 501 against it could be evidence of a sloppy MVA or a rogue MVA. 503 9. Troubleshooting BIMI 505 There are several factors to consider for email receivers on things 506 that can go wrong, below are a handful of considerations: 508 o Failing to verify BIMI certs when they otherwise should be. This 509 can be caused by: 511 o Not having the key to a corresponding MVA 513 o Not having access to the key when required 515 o The wrong key is associated with the wrong MVA 517 o Failing to load a logo in the email client 518 o Failing to access the logo (e.g., permissions errors) 520 o Connectivity problems to the logo 522 o Failing to display a correct logo in the email client 524 o Having the wrong logo stored for a brand (i.e., uploading it to a 525 local store but associating it with the wrong brand) 527 o Caching a logo for too long after it has updated 529 There are many reasons why a logo may fail to load; having tools to 530 investigate (logs, headers in messages, internal documentation that 531 is clearly written, having the knowledge pushed out to multiple 532 escalation channels) are important for investigation. 534 10. Public documentation 536 10.1. For Brands: 538 It is ideal to publish the criteria that is used by your site to 539 determine when BIMI will be displayed. It is fine to say that you 540 use some internal domain reputation metrics as additional criteria to 541 determine whether or not a logo should be displayed, and it 542 isnaEUR[TM]t necessary to give away the exact nature of the algorithm 543 other than to say "You must maintain good sending practices." 545 If you use an explicit whitelist, a site may want to list the minimum 546 requirements, and the method of applying to be whitelisted. 547 Similarly, a provider may wish to state what type of activity will 548 revoke the decision to display logos previously approved. 550 10.2. For users: 552 BIMI is not meant to instill additional trust in messages, and it is 553 important to make this known to your users. All messages, even those 554 with logos, should still be treated with (mild) skepticism, and any 555 action regarding the message should still be individually evaluated. 556 ItaEUR[TM]s possible for a site that has a high trust value to become 557 compromised and send fraudulent messages that could compromise a 558 useraEUR[TM]s system. Ensure your customers have a place that 559 documents BIMI and demonstrates how to check messages for fraud. 561 11. Appendix 562 11.1. Glossary 564 o MUA - Mail User Agent - The application used to read messages by 565 the end user. This could be a thick client or a web-based 566 application. 568 o MTA - Mail Transfer Agent - Software used to transfer messages 569 between two systems, typically between two sites, using SMTP as 570 the protocol. 572 o SPF - SPF is a framework that designates which systems should be 573 sending for a given domain. This can be a list of IPs, CIDRs, or 574 references to DNS records. As the sender should be controlling 575 their DNS, they should understand which IPs should be sending as 576 their domain. 578 o DKIM - DKIM is a system by which a chosen set of headers, combined 579 with the message contents, are cryptographically signed, and then 580 validated by the receiving system. Using DNS, the receiving 581 system can retrieve a public key, and then validate the signature 582 within the headers of a message. When implemented properly, the 583 systems responsible for sending the messages for a given domain 584 name should be the only ones capable of creating messages that 585 correctly validates. Provided that certain restrictions are met, 586 DKIM is one possible technology a receiver could utilize to 587 authenticate messages in the context of BIMI. 589 o DMARC - DMARC is a message authentication mechanism that works 590 with SPF and DKIM. The BIMI specification requires that a message 591 passes DMARC. In order for a message to pass DMARC, one of SPF or 592 DKIM must successfully validate, and the domain in the From: 593 address must align with the domain that passed SPF or DKIM. 595 o MVA - Mark Verifying Authority - An entity that a receiver uses to 596 certify that the iconography that they intend to use with BIMI is 597 properly/legally licensed for their use. 599 o DRA - Dispute Resolution Authority - This organization will 600 moderate between two entities that believe they are both entitled 601 to use a logo. Receivers should then abide by the decision of the 602 DRA as it pertains to logo usage in the MUA. 604 o Alignment - Alignment refers to the organizational domain, as 605 defined by DMARC, of the domain in the From: address being the 606 same as the organizational domain that passed SPF or DKIM. For 607 example, foo.example.com has an organizational domain of 608 example.com; bar.foo.example.com also has an organizational domain 609 of example.com. It aligns with org.example.com, because both have 610 the same organizational domain. 612 o BIMI Certificates - An Extended Validation Certificate is used in 613 conjunction with BIMI to create a place where information 614 pertaining to iconography for a sending domain can be securely 615 verified. In the case of BIMI, hashes for an MVA-approved set of 616 iconography will be stored in a field within the certificate. 617 This should allow a receiver site to validate the retrieved 618 imagery before putting the BIMI image URI into the message 619 headers. 621 o Terry Zink - Alex BrotmanaEUR[TM]s best friend. 623 12. Contributors 625 TBD 627 13. References 629 The full BIMI verification spec can be found at: 630 633 Verified Mark Certificates Usage: 636 14. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", BCP 14, RFC 2119, 640 DOI 10.17487/RFC2119, March 1997, 641 . 643 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 644 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 645 May 2017, . 647 Authors' Addresses 649 Alex Brotman 650 Comcast, Inc 652 Email: alex_brotman@comcast.com 653 Terry Zink 654 Zink Magical Contraptions 656 Email: tzink@terryzink.com