idnits 2.17.1 draft-brotman-ietf-bimi-guidance-01.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 (August 5, 2019) is 1720 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: February 6, 2020 Zink Magical Contraptions 6 August 5, 2019 8 Receivers Guidance for Implementing Branded Indicators for Message 9 Identification (BIMI) 10 draft-brotman-ietf-bimi-guidance-01 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 February 6, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 InternetA[cents]a'[not]a"[cents]s larger brands, but there is still a 111 long tail of small-to-medium size brands (and many large ones) that 112 do not have it. Because BIMI provides a visual presence in the 113 inbox, and because visual impressions are desirable for brands, BIMI 114 provides an incentive for marketers to spur DMARC adoption, whereas a 115 concern 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 426 itA[cents]a'[not]a"[cents]s safe to download and display an image. 427 That is, an attacker could go through the trouble of creating a BIMI 428 logo and uploading it, but the logo may look visually similar to a 429 real brand. For example, a spammer or phisher could create a 430 lookalike domain for a well-known brand such as Paypal, then copy/ 431 paste (or slightly modify) the logo. 433 To prevent this, an email receiver could choose to verify logos of 434 known brands by themselves (do it all in-house) and establish its own 435 internal processes, or it could use a Mark Verifying Authority (MVA). 436 The receiver could then outsource the maintenance of the list of 437 trusted brands to the MVA, and simply download the list of brands and 438 images from the MVA and display the logos in its email clients. 440 However, even here a receiver would need to exercise caution. It 441 needs to ensure that MVAs follow best practices, respond to 442 complaints, and do a good job of vetting brands. If users ultimately 443 end up getting phished because they trust signals in the email 444 client, then it is the email receiver that will suffer the brunt of 445 the complaints and loss of reputation, rather than the MVA. 447 Therefore, an email receiver still needs to track complaints from its 448 users, especially with respect to phishing and impersonation, and 449 then send the feedback back to the MVA. If an MVA still generates 450 too many complaints, this could be indicative of a rogue MVA (one 451 that intentionally signs up malicious accounts), or a 452 A[cents]a'[not]Ae"sloppyA[cents]a'[not]A MVA (one with internal 453 processes that not rigorous enough, or are designed to maximize 454 revenue at the cost of lax security). 456 An email receiver should use multiple MVAs to reduce the risk of 457 becoming too reliant upon a single MVA in case they have to stop 458 using it, and therefore lose many dozens, hundreds, or thousands of 459 images with no replacement and thereby contributing to user 460 dissatisfaction confusion. Furthermore, because MVAs may be revoked, 461 brands may wish to diversify their own risk by getting certified by 462 at least two MVAs. The reason for doing this is that if the MVA they 463 use ever gets revoked by an email receiver because of its bad 464 practices, then their own brand will suffer penalties (not having a 465 logo displayed) despite never having done anything wrong. By 466 researching multiple MVAs, a brand can reduce the chances that losing 467 one by a receiver affects their brand. 469 For this reason, brands are encouraged to get certified at multiple 470 MVAs, and receivers are encouraged to use multiple MVAs. 472 8.1. Resolving disputes 474 From time to time, disputes may arise between brands where one brand 475 says that another is infringing on its logo. 477 A brand owner would want to have all email receivers stop showing 478 logos for the infringing brand because it could damage its own 479 brandA[cents]a'[not]a"[cents]s reputation. However, an email 480 receiver is not necessarily in a good position to determine what 481 constitutes legitimate usage of a logo, nor determine ownership of a 482 logo, nor may want the legal risk associated with making this 483 determination. 485 Therefore, email receivers are strongly encouraged to partner with 486 Dispute Resolution Agencies. These agencies specialize in copyright 487 infringement resolution. An affected party would then contact the 488 Dispute Resolution Agency, rather than the email receiver, who would 489 then make the decision about if use of the logo were legitimate. 490 Then, they would publish the result of the dispute publicly where it 491 could be viewed by anyone. 493 MVAs should respect the decision of the courts and any brand found to 494 be infringing ought to be removed from their list of domains for 495 which they load BIMI logos for. The issuing MVA of the infringing 496 brandA[cents]a'[not]a"[cents]s BIMI Certificate should formally 497 revoke it. However, this is not guaranteed in the case of a rogue 498 MVA or a sloppy MVA. Therefore, email receivers should also pay 499 attention to the Dispute Resolution Agencies, and any results that 500 they say are infringing should be prevented from loading in their 501 email clients. The email receiver should also keep track of how 502 often disputes occur and are found against various MVAs, as an MVA 503 with too many disputes ruled against it could be evidence of a sloppy 504 MVA or a rogue MVA. 506 9. Troubleshooting BIMI 508 There are several factors to consider for email receivers on things 509 that can go wrong, below are a handful of considerations: 511 o Failing to verify BIMI certs when they otherwise should be. This 512 can be caused by: 514 o Not having the key to a corresponding MVA 516 o Not having access to the key when required 518 o The wrong key is associated with the wrong MVA 519 o Failing to load a logo in the email client 521 o Failing to access the logo (e.g., permissions errors) 523 o Connectivity problems to the logo 525 o Failing to display a correct logo in the email client 527 o Having the wrong logo stored for a brand (i.e., uploading it to a 528 local store but associating it with the wrong brand) 530 o Caching a logo for too long after it has updated 532 There are many reasons why a logo may fail to load; having tools to 533 investigate (logs, headers in messages, internal documentation that 534 is clearly written, having the knowledge pushed out to multiple 535 escalation channels) are important for investigation. 537 10. Public documentation 539 10.1. For Brands: 541 It is ideal to publish the criteria that is used by your site to 542 determine when BIMI will be displayed. It is fine to say that you 543 use some internal domain reputation metrics as additional criteria to 544 determine whether or not a logo should be displayed, and it 545 isnA[cents]a'[not]a"[cents]t necessary to give away the exact nature 546 of the algorithm other than to say "You must maintain good sending 547 practices." 549 If you use an explicit whitelist, a site may want to list the minimum 550 requirements, and the method of applying to be whitelisted. 551 Similarly, a provider may wish to state what type of activity will 552 revoke the decision to display logos previously approved. 554 10.2. For users: 556 BIMI is not meant to instill additional trust in messages, and it is 557 important to make this known to your users. All messages, even those 558 with logos, should still be treated with (mild) skepticism, and any 559 action regarding the message should still be individually evaluated. 560 ItA[cents]a'[not]a"[cents]s possible for a site that has a high trust 561 value to become compromised and send fraudulent messages that could 562 compromise a userA[cents]a'[not]a"[cents]s system. Ensure your 563 customers have a place that documents BIMI and demonstrates how to 564 check messages for fraud. 566 11. Appendix 568 11.1. Glossary 570 o MUA - Mail User Agent - The application used to read messages by 571 the end user. This could be a thick client or a web-based 572 application. 574 o MTA - Mail Transfer Agent - Software used to transfer messages 575 between two systems, typically between two sites, using SMTP as 576 the protocol. 578 o SPF - SPF is a framework that designates which systems should be 579 sending for a given domain. This can be a list of IPs, CIDRs, or 580 references to DNS records. As the sender should be controlling 581 their DNS, they should understand which IPs should be sending as 582 their domain. 584 o DKIM - DKIM is a system by which a chosen set of headers, combined 585 with the message contents, are cryptographically signed, and then 586 validated by the receiving system. Using DNS, the receiving 587 system can retrieve a public key, and then validate the signature 588 within the headers of a message. When implemented properly, the 589 systems responsible for sending the messages for a given domain 590 name should be the only ones capable of creating messages that 591 correctly validates. Provided that certain restrictions are met, 592 DKIM is one possible technology a receiver could utilize to 593 authenticate messages in the context of BIMI. 595 o DMARC - DMARC is a message authentication mechanism that works 596 with SPF and DKIM. The BIMI specification requires that a message 597 passes DMARC. In order for a message to pass DMARC, one of SPF or 598 DKIM must successfully validate, and the domain in the From: 599 address must align with the domain that passed SPF or DKIM. 601 o MVA - Mark Verifying Authority - An entity that a receiver uses to 602 certify that the iconography that they intend to use with BIMI is 603 properly/legally licensed for their use. 605 o DRA - Dispute Resolution Authority - This organization will 606 moderate between two entities that believe they are both entitled 607 to use a logo. Receivers should then abide by the decision of the 608 DRA as it pertains to logo usage in the MUA. 610 o Alignment - Alignment refers to the organizational domain, as 611 defined by DMARC, of the domain in the From: address being the 612 same as the organizational domain that passed SPF or DKIM. For 613 example, foo.example.com has an organizational domain of 614 example.com; bar.foo.example.com also has an organizational domain 615 of example.com. It aligns with org.example.com, because both have 616 the same organizational domain. 618 o BIMI Certificates - An Extended Validation Certificate is used in 619 conjunction with BIMI to create a place where information 620 pertaining to iconography for a sending domain can be securely 621 verified. In the case of BIMI, hashes for an MVA-approved set of 622 iconography will be stored in a field within the certificate. 623 This should allow a receiver site to validate the retrieved 624 imagery before putting the BIMI image URI into the message 625 headers. 627 o Terry Zink - Alex BrotmanA[cents]a'[not]a"[cents]s best friend. 629 12. Contributors 631 TBD 633 13. References 635 The full BIMI verification spec can be found at: 636 639 Verified Mark Certificates Usage: 642 14. Normative References 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, 646 DOI 10.17487/RFC2119, March 1997, 647 . 649 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 650 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 651 May 2017, . 653 Authors' Addresses 655 Alex Brotman 656 Comcast, Inc 658 Email: alex_brotman@comcast.com 659 Terry Zink 660 Zink Magical Contraptions 662 Email: tzink@terryzink.com