idnits 2.17.1 draft-blank-ietf-bimi-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1437 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 54 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 181: '... To participate in BIMI, Domain Owners MUST have a strong [DMARC]...' RFC 2119 keyword, line 183: '...message. Quarantine policies MUST NOT...' RFC 2119 keyword, line 448: '... * Indicators SHOULD be verified an...' RFC 2119 keyword, line 458: '...e BIMI mechanism SHOULD make a best-ef...' RFC 2119 keyword, line 461: '...r end users, and MAY use alternate Ind...' (75 more instances...) 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 [KEYWORDS], but that reference does not seem to mention RFC 2119 either. -- The document date (31 July 2020) is 1366 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 1160, but not defined == Unused Reference: 'Authentication-Results' is defined on line 1181, but no explicit reference was found in the text == Unused Reference: 'Logotype' is defined on line 1206, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7601 (ref. 'Authentication-Results') (Obsoleted by RFC 8601) ** Obsolete normative reference: RFC 3709 (ref. 'Logotype') (Obsoleted by RFC 9399) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Blank 3 Internet-Draft P. Goldstein 4 Intended status: Experimental Valimail 5 Expires: 1 February 2021 T. Loder, Ed. 6 Skye Logicworks, LLC 7 T. Zink, Ed. 8 Zink Magical Contraptions 9 M. Bradshaw, Ed. 10 Fastmail 11 31 July 2020 13 Brand Indicators for Message Identification (BIMI) 14 draft-blank-ietf-bimi-01 16 Abstract 18 Brand Indicators for Message Identification (BIMI) permits Domain 19 Owners to coordinate with Mail User Agents (MUAs) to display brand- 20 specific Indicators next to properly authenticated messages. There 21 are two aspects of BIMI coordination: a scalable mechanism for Domain 22 Owners to publish their desired Indicators, and a mechanism for Mail 23 Transfer Agents (MTAs) to verify the authenticity of the Indicator. 24 This document specifies how Domain Owners communicate their desired 25 Indicators through the BIMI Assertion Record in DNS and how that 26 record is to be interpreted by MTAs and MUAs. MUAs and mail- 27 receiving organizations are free to define their own policies for 28 making use of BIMI data and for Indicator display as they see fit. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 1 February 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction 64 2. Overview 65 3. Requirements 66 3.1. High-Level Goals 67 3.2. Security 68 3.3. Out of Scope 69 4. Terminology and Definitions 70 4.1. BIMI Assertion 71 4.2. Indicator 72 4.3. Mark Verifying Authority (MVA) 73 4.4. BIMI Evidence Document 74 4.5. Verified Mark Certificate (VMC) 75 4.6. Protocol Client 76 4.7. Verifying Protocol Client 77 5. BIMI DNS Records 78 5.1. MUA Obligations 79 5.2. Assertion Record 80 5.2.1. Declination to Publish 81 5.2.2. Supported Image Formats for l= tag 82 5.3. Selectors 83 6. BIMI Header Fields 84 6.1. BIMI-Selector Header 85 6.2. BIMI-Location Header 86 6.3. BIMI-Indicator Header 87 6.4. Header Signing 88 7. Domain Owner Actions 89 7.1. Determine and Publish Indicator(s) for Use 90 7.2. Publish Assertion Records 91 7.3. Manage multiple uses of the same Indicator(s) within 92 a trust boundary 93 7.4. Set the headers on outgoing email as appropriate 94 8. Receiver Actions 95 8.1. Authentication Requirements 96 8.2. Assertion Record Discovery 97 8.3. Indicator Discovery. 98 8.4. Indicator Discovery With Evidence. 99 8.5. Indicator Discovery Without Evidence. 100 8.6. Indicator Validation 101 8.7. Affix BIMI Status to Authentication Results Header 102 Field 103 8.8. Handle Existing BIMI-Location and BIMI-Indicator 104 Headers 105 8.9. Construct BIMI-Location URI 106 8.10. Construct BIMI-Indicator header 107 9. Security Considerations 108 9.1. Indirect Mail Flows 109 9.2. Lookalike Domains and Copycat Indicators 110 9.3. Large files and buffer overflows 111 9.4. Slow DNS queries 112 9.5. Unaligned Indicators and asserting domains 113 9.6. Unsigned BIMI-Selector Header 114 9.7. CGI scripts in Indicator payload 115 9.8. Metadata in Indicators 116 10. IANA Considerations 117 10.1. Permanent Header Field Updates 118 10.2. Registry for Supported BIMI Formats 119 10.3. Other IANA needs 120 11. References 121 11.1. Normative References 122 11.2. Informative References 123 Appendix A. Example Selector Discovery (INFORMATIVE) 124 A.1. No BIMI-Selector Header 125 A.2. With BIMI-Selector Header 126 A.3. Without BIMI-Selector Header on a subdomain 127 A.4. With BIMI-Selector Header on a subdomain 128 A.5. Invalid BIMI-Selector Header 129 Appendix B. Example Authentication-Results entry (INFORMATIONAL) 130 B.1. Successful BIMI lookup 131 B.2. No BIMI record 132 B.3. Subdomain has no default record, but organizational 133 domain does 134 B.4. Subdomain has no record for selector, but 135 organization domain has a default 136 Appendix C. Example BIMI Headers Construction (INFORMATIONAL) 137 C.1. MTA Receives an email 138 C.2. MTA does its authentication checks 139 C.3. MTA performs BIMI Assertion 140 C.4. MTA appends to Authentication-Results 141 C.5. MTA Constructs BIMI-Location and BIMI-Indicator 142 headers 143 C.6. The MUA displays the Indicator 144 C.7. Acknowledgements 145 Authors' Addresses 147 1. Introduction 149 This document defines Brand Indicators for Message Identification 150 (BIMI), which enables Domain Owners to coordinate with Mail Box 151 Providers (MBPs), Mail Transfer Agents (MTAs), and Mail User Agents 152 (MUAs) in the display of brand-specific Indicators next to properly 153 authenticated messages. 155 BIMI is designed to be open and to work at Internet scale. BIMI is 156 intended to drive adoption of email authentication best practices by 157 leveraging existing [DMARC] policies, the supporting authentication 158 methods [DKIM] and [SPF], and other associated standards such as 159 [ARC]. 161 The approach taken by BIMI is heavily influenced by the approach 162 taken in [DKIM], in that BIMI: 164 * has no dependency on the deployment of any new Internet protocols 165 or services for Indicator registration or revocation; 167 * makes no attempt to include encryption as part of the mechanism; 169 * is compatible with the existing email infrastructure and 170 transparent to the fullest extent possible; 172 * requires minimal new infrastructure; 174 * can be implemented independently of clients in order to reduce 175 deployment time; 177 * can be deployed incrementally; and 179 * allows delegation of Indicator hosting to third parties. 181 To participate in BIMI, Domain Owners MUST have a strong [DMARC] 182 policy (quarantine or reject) on both the Organizational Domain, and 183 the RFC5322.From Domain of the message. Quarantine policies MUST NOT 184 have a pct less than pct=100. 186 This document defines how Domain Owners specify their desired 187 Indicators through the BIMI Assertion Record in DNS and how that 188 record is to be interpreted by MTAs and MUAs. This document does not 189 cover how domains or Indicators are verified, how MUAs should display 190 the Indicators, or how other protocols (i.e. IMAP, JMAP) can be 191 extended to work with BIMI. Other documents may cover these topics. 192 MUAs and Mail Box Providers (MBPs) are free to define their own 193 policies for making use of BIMI data and for Indicator display as 194 they see fit. 196 2. Overview 198 The Sender Policy Framework ([SPF]), DomainKeys Identified Mail 199 ([DKIM]), Domain-based Message Authentication, Reporting, and 200 Conformance ([DMARC]), and Authenticated Received Chain ([ARC]) 201 provide mechanisms for domain-level authentication of email messages. 202 They enable cooperating email senders and receivers to distinguish 203 messages that are authorized to use the domain name from those that 204 are not. BIMI relies on these authentication protocols, but is not a 205 new authentication protocol itself. 207 MUAs are increasingly incorporating graphical Indicators to indicate 208 the identity of the sender of a message. While a discussion of the 209 merits of doing this is beyond the scope of this document, at present 210 there are no open standards for publishing and aiding discovery of 211 preferred Indicators or for tying display of them to authentic 212 messages only. 214 Because of the desire to have brand-specific Indicators available, 215 some mail-receiving organizations have developed closed systems for 216 obtaining and displaying Brand Indicators for select domains. While 217 this has enabled these mail-receiving organizations to display brand 218 Indicators for a limited subset of messages, this closed approach has 219 a number of downsides: 221 * It puts a significant burden on each mail-receiving organization, 222 because they must identify and manage a large database of Brand 223 Indicators. 225 * Scalability is challenging for closed systems that attempt to 226 capture and maintain complete sets of data across the whole of the 227 Internet. 229 * A lack of uniformity across different mail-receiving organizations 230 - each organization will have its own Indicator set, which may or 231 may not agree with those maintained by other organizations for any 232 given domain. 234 * Domain Owners have limited ability to influence the Brand 235 Indicator for the domain(s) they own, and any ability they do have 236 is likely to be dependent upon direct coordination with each of 237 many mail-receiving organizations. 239 * Many Domain Owners have no ability to participate whatsoever as 240 they do not have the appropriate relationships to coordinate with 241 mail-receiving organizations. 243 * MUAs that are not associated with a particular mail-receiving 244 organization are likely to be disadvantaged, because they are 245 unlikely to receive Indicators in a standardized manner or 246 optimized for their user interfaces. 248 This shows the need for a standardized mechanism by which Domain 249 Owners interested in ensuring that their Indicators are displayed 250 correctly and appropriately can publish and distribute Brand 251 Indicators for use by any participating MUA. 253 BIMI removes the substantial burden of curating and maintaining an 254 Indicator database from MUAs and MBPs, and allows each domain owner 255 to manage their own Indicators. As an additional benefit, mail- 256 originating organizations are incentivized to authenticate their 257 email as doing so will enable them to influence how email and 258 Indicators from the organization are displayed. 260 The structure of BIMI is as follows: 262 * Domain Owners: Publish their preferred Brand Indicators via the 263 [DNS]. 265 * Senders: Ensure mail is properly authenticated, and has a 266 sufficiently strict [DMARC] policy. 268 * MTA: 270 - Confirm authenticity of the message using [DMARC] and whatever 271 other authentication mechanisms they wish to apply. 273 - Check for a corresponding BIMI record, obtaining references to 274 the Indicator media and optional substantiation of Indicator 275 ownership rights 277 - If both the message is authentic and the Indicator is deemed 278 acceptable, the receiver adds a header to the message which can 279 be used by the MUA to obtain the Domain Owner's preferred Brand 280 Indicator. 282 * MUA: retrieves and displays the Brand Indicator as appropriate 283 based on its policy and user interface. 285 The purpose of this structure is to reduce operational complexity at 286 each step. It is also to consolidate validation and Indicator 287 selection operations into the MTA, so that Domain Owners need only 288 publish a few simple records and MUAs only need simple display logic. 290 It is expected that MBPs implementing BIMI will do so in both their 291 MTAs and MUAs. 293 3. Requirements 295 Specification of BIMI in this document is guided by the following 296 high-level goals, security dependencies, detailed requirements, and 297 items that are documented as out of scope. 299 An overview of the security challenges and design decisions is 300 documented at [BIMI-OVERVIEW]. 302 3.1. High-Level Goals 304 BIMI has the following high-level goals: 306 * Allow Domain Owners to suggest appropriate Indicators for display 307 with authenticated messages originating from their domains. 309 * Enable the authors of MUAs to display meaningful Indicators 310 associated with the Domain Owner to recipients of authenticated 311 email. 313 * Provide mechanisms to prevent attempts by malicious Domain Owners 314 to fraudulently represent messages from their domains as 315 originating with other entities. 317 * Work at Internet Scale. 319 * Encourage the adoption of Email Authentication Best Practices. 321 3.2. Security 323 Brand Indicators are a potential vector for abuse. BIMI creates a 324 relationship between sending organization and Mail Receiver so that 325 the receiver can display appropriately designated Indicators if the 326 sending domain is verified and has meaningful reputation with the 327 receiver. Without verification and reputation, there is no way to 328 prevent a bad actor exxample.com from using example.com's Brand 329 Indicators and behaving maliciously. This document does not cover 330 the different verification and reputation mechanisms available, but 331 BIMI relies upon them to be in deployed in order to control abuse. 333 3.3. Out of Scope 335 Several topics and issues are specifically out of scope for the 336 initial version of this work. These include the following: 338 * Publishing policy other than via the DNS. 340 * Specific requirements for Indicator display on MUAs. 342 * The explicit mechanisms used by Verifying Protocol Clients - this 343 will be deferred to a later document. 345 4. Terminology and Definitions 347 This section defines terms used in the rest of the document. 349 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 350 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 351 document are to be interpreted as described in [KEYWORDS]. 353 Readers are encouraged to be familiar with the contents of [EMAIL- 354 ARCH]. In particular, that document defines various roles in the 355 messaging infrastructure that can appear the same or separate in 356 various contexts. For example, a Domain Owner could, via the 357 messaging mechanisms on which BIMI is based, delegate reponsibility 358 for providing preferred Brand Indicators to a third party with 359 another role. This document does not address the distinctions among 360 such roles; the reader is encouraged to become familiar with that 361 material before continuing. 363 Syntax descriptions use Augmented BNF [ABNF]. 365 "Author Domain", "Domain Owner", "Organizational Domain", and "Mail 366 Receiver" are imported from [DMARC] Section 3. 368 4.1. BIMI Assertion 370 The mechanism through which a Protocol Client verifies the BIMI 371 Assertion Record and constructs the URI(s) to the requested 372 Indicator(s) to be placed in the BIMI-Location header. 374 4.2. Indicator 376 The icon, logo, image, mark, or other graphical representation of the 377 brand. The Indicator is defined in a common image format with 378 restrictions detailed in the Assertion Record definition 379 (Section 5.2). 381 4.3. Mark Verifying Authority (MVA) 383 An entity or organization that can provide evidence of verification 384 of Indicators asserted by a Domain Owner to Verifying Protocol 385 Clients. The MVA may choose to uphold and confirm the meeting of 386 certain Indicator standards (ie. size, trademark, content, etc). 388 4.4. BIMI Evidence Document 390 A document published by a Mark Verifying Authority to assert evicence 391 of verification. These are defined in a separate document. 393 4.5. Verified Mark Certificate (VMC) 395 A certificate issued by a Certificate Authority in accordance with 396 the Verified Mark Certificate Guidelines. These guidelines are 397 defined in a separate document. 399 A Verified Mark Certificate is one example of a BIMI Evidence 400 Document. 402 4.6. Protocol Client 404 An entity designed to obtain and correctly interpret the records 405 defined in this specification for the purpose of discovering and 406 fetching published Indicators. 408 4.7. Verifying Protocol Client 410 A Protocol Client that uses optional capabilities to obtain and 411 evaluate evidence concerning the Domain Owner's rights to use the 412 published Indicators. 414 5. BIMI DNS Records 416 Domain owners publish BIMI policies by adding BIMI Assertion Records 417 in the DNS as TXT records. 419 Published policies are interpreted and applied by Protocol Clients. 420 A Domain Owner signals intended BIMI participation for one or more of 421 its domains by publishing an Assertion Record in a subdomain under 422 it. In doing so, Domain Owners make specific requests of MUAs 423 regarding the preferred set of Indicators to be displayed with 424 messages that are confirmed to be authorized to appear from the 425 Domain Owner's domain. 427 The use of BIMI is opt-in. Receivers default to performing no BIMI- 428 specific message handling until they choose to do so, and then only 429 if a BIMI record for the sender's domain is found. 431 BIMI's use of the DNS is driven in part by BIMI's use of domain names 432 as the basis of sender identity and message authentication. Use of 433 the DNS as the policy publication service also has the benefit of 434 reusing an extremely well-established operations, administration, and 435 management infrastructure, rather than creating a new one. 437 BIMI's policy payload is intentionally only published via a DNS 438 record and not via one or more email headers. This serves three 439 purposes: 441 * There is one and only one mechanism for both simple and complex 442 policies to be published. 444 * Operational complexity is reduced. MTAs only need to check a 445 single record in a consistent manner to discover and enforce 446 policy. 448 * Indicators SHOULD be verified and cached in advance, so that 449 malicious headers cannot be used as an attack vector. 451 Per [DNS], a TXT record can comprise several "character-string" 452 objects. BIMI TXT records with multiple strings must be treated in 453 an identical manner to SPF Section 3.3 (https://tools.ietf.org/html/ 454 rfc7208#section-3.3). 456 5.1. MUA Obligations 458 MUAs implementing the BIMI mechanism SHOULD make a best-effort 459 attempt to adhere to the Domain Owner's published BIMI policy. 460 However, MUAs have final control over the user interface published to 461 their end users, and MAY use alternate Indicators than those 462 specified in the BIMI assertion record or no Indicator at all. 464 5.2. Assertion Record 466 All Domain Owner BIMI preferences are expressed in DNS TXT records 467 published in subdomains named "_bimi". Multiple sets of preferences 468 can be associated with a single RFC5322.From domain. To distinguish 469 between these different preferences, BIMI defines and uses selectors. 470 Senders declare which selector to use for a given message by 471 specifying the selector in an optional BIMI-Selector header 472 (Section 6.1). 474 For example, the Domain Owner of "example.com" would post BIMI policy 475 in a TXT record at "default._bimi.example.com". Similarly, a Mail 476 Receiver wishing to query for BIMI policy regarding mail with an 477 RFC5322.From Author Domain of "example.com" and a selector "default" 478 (the default) would query the TXT record located at the subdomain of 479 "default._bimi.example.com". The DNS-based BIMI policy record is 480 referred to as the "BIMI Assertion Record" or "Assertion Record". 482 BIMI Assertion Records follow the extensible "tag-value" syntax for 483 DNS-based key records as defined in [DKIM]. 485 Assertion Records are defined precisely. Mail receivers MUST NOT 486 attempt to fix syntactical or capitalization errors. If a required 487 tag is missing, or its value not well-formed, it is an error. 489 This section creates a registry for known BIMI tags and registers the 490 initial set defined in this document. Only tags defined in this 491 document or in later extensions, and thus added to the registry, are 492 to be processed; unknown tags MUST be ignored. 494 The following tags are introduced as the initial valid BIMI tags: 496 v= Version (plain-text; REQUIRED). Identifies the record retrieved 497 as a BIMI record. It MUST have the value of "BIMI1" for 498 implementations compliant with this version of BIMI. The value of 499 this tag MUST match precisely; if it does not match or it is absent, 500 the entire retrieved record MUST be ignored. It MUST be the first 501 tag in the list. 503 ABNF: 505 bimi-version = %x76 *WSP "=" *WSP %x42.49.4d.49 1DIGIT 507 a= Authority Evidence Location (plain-text; URI; OPTIONAL). If 508 present, this tag MUST have an empty value or its value MUST be a 509 single URI. An empty value for the tag is interpreted to mean the 510 Domain Owner does not wish to publish or does not have authority 511 evidence to disclose. The URI, if present, MUST contain a fully 512 qualified domain name (FQDN) and MUST specify HTTPS as the URI scheme 513 ("https"). The URI SHOULD specify the location of a publicly 514 retrievable BIMI Evidence Document. The format for evidence 515 documents is defined in a separate document. 517 If the a= tag is not present, it is assumed to have an empty value. 519 ABNF: 521 bimi-evidence-location = %x61 *WSP "=" bimi-uri 523 bimi-uri = \[FWS\] URI \[FWS\] 525 ; "URI" is imported from [URI] 526 ; HTTPS only 527 ; commas within a URI (ASCII ; 0x2C) MUST be encoded 529 l= location (URI; REQUIRED). The value of this tag is either empty 530 indicating declination to publish, or a single URI representing the 531 location of a Brand Indicator file. The only supported transport is 532 HTTPS. 534 ABNF: 536 bimi-location = %x6c *WSP "=" bimi-uri 538 Therefore, the formal definition of the BIMI Assertion Record, using 539 [ABNF], is as follows: 541 bimi-sep = *WSP %x3b *WSP 543 bimi-record = bimi-version (bimi-sep bimi-location) (bimi-sep bimi-evidence-location) \[bimi-sep\] 545 ; components other than bimi-version may appear in any order 547 5.2.1. Declination to Publish 549 If both the "l=" and "a=" tags are empty, it is an explicit refusal 550 to participate in BIMI. This is distinct from not publishing a BIMI 551 record. For example, an empty BIMI record enables a Domain Owner to 552 decline BIMI participation for a subdomain when its organizational 553 domain has default Indicators available. Furthermore, messages sent 554 using a selector that has declined to publish will not show an 555 Indicator while messages with other selectors would display normally. 557 An explicit declination to publish looks like: 559 v=BIMI1; l=; a=; 561 5.2.2. Supported Image Formats for l= tag 563 Any format in the BIMI-formats IANA registry are acceptable targets 564 for the l= tag. If an l= tag URI ends with any other image format 565 suffix, or if the document retrievable from the location(s) in the l= 566 tag are of any other format, the evaluation of the record MUST be 567 treated as a permanent error. 569 As of the publishing of this document, only SVG and SVGZ, as defined 570 in RFC6170 section 5.2 (https://tools.ietf.org/html/rfc6170#section- 571 5.2) is acceptable in the l= tag. Further restrictions apply to the 572 SVG; these are documented elsewhere. 574 5.3. Selectors 576 To support publishing and display of more than one distinct Brand 577 Indicator per domain, the brand Indicator namespace is subdivided for 578 publishing of multiple Assertion Records using "selectors". 579 Selectors allow the Domain Owner to choose the brand Indicator, for 580 example, by type of recipient, by message source, or by other 581 considerations like seasonal branding. BIMI selectors are modeled 582 after DKIM selectors (https://tools.ietf.org/html/rfc6376#section- 583 3.1). 585 The selector "default" is the default Assertion Record. Domain 586 Owners can specify which other selector to use on a per-message basis 587 by utilizing the BIMI-Selector Header (Section 6.1). 589 Periods are allowed in selectors and are component separators. When 590 BIMI Assertion Records are retrieved from the DNS, periods in 591 selectors define DNS label boundaries in a manner similar to the 592 conventional use in domain names. In a DNS implementation, this can 593 be used to allow delegation of a portion of the selector namespace. 595 ABNF: 597 selector = sub-domain *( "." sub-domain ) 599 ; from [SMTP] Domain, 601 ; excluding address-literal 603 The number of selectors for each domain is determined by the Domain 604 Owner. Many Domain Owners will be satisfied with just one selector, 605 whereas organizations with more complex branding requirements can 606 choose to manage disparate selectors. BIMI sets no maximum limit on 607 the number of selectors. 609 6. BIMI Header Fields 611 Once BIMI policies are published in DNS via Assertion Records, Domain 612 Owners can provide additional guidance to Mail Receivers, and Mail 613 Receivers to their MUAs through the use of BIMI header fields. 615 BIMI header fields are case insensitive. If a required tag is 616 missing, it is an error. 618 6.1. BIMI-Selector Header 620 BIMI DNS records are placed in ._bimi., and by 621 default they are placed in default._bimi.. That is, for 622 example.com, the default Assertion Record is located in the DNS at 623 default._bimi.example.com. However, a Domain Owner may override the 624 use of the default selector and specify the use of an alternative 625 using the RFC5322-compliant header 'BIMI-Selector'. The BIMI- 626 Selector header consists of key value pairs: 628 v= Version (plain-text; REQUIRED). The version of BIMI. It MUST 629 have the value of "BIMI1" for implementations compliant with this 630 version of BIMI. The value of this tag MUST match precisely; if it 631 does not or it is absent, the entire retrieved record MUST be 632 ignored. It MUST be the first tag in the list. 634 ABNF: 636 bimi-header-version = "v" *WSP "=" *WSP "BIMI" 1DIGIT 638 s= Selector (plain-text; REQUIRED). The location of the BIMI DNS 639 record, when combined with the RFC5322.From domain. 641 ABNF: 643 bimi-selector = "s" *WSP "=" *WSP selector 645 And the formal definition of the BIMI Selector Header, using ABNF, is 646 as follows: 648 bimi-selector-header = bimi-header-version bimi-sep bimi-selector \[bimi-sep\] 650 6.2. BIMI-Location Header 652 BIMI-Location is the header a Mail Receiver inserts that tells the 653 MUA where to get the BIMI Indicator from. 655 The syntax of the header is as follows: 657 v= Version (plain-text; REQUIRED). The version of BIMI. It MUST 658 have the value of "BIMI1" for implementations compliant with this 659 version of BIMI. The value of this tag MUST match precisely; if it 660 does not or it is absent, the entire header MUST be ignored. It MUST 661 be the first tag in the list. 663 The ABNF for bimi-header-version is imported exactly from the [BIMI Selector Header](#bimi-selector). 665 l: location of the BIMI Indicator (URI; OPTIONAL if a bimi-evidence- 666 location-header-uri is specified, otherwise REQUIRED.). Inserted by 667 the MTA after performing the required checks and obtaining the 668 applicable domain's published Assertion Record. The value of this 669 tag is a URI representing the location of the Brand Indicator file. 670 HTTPS is the only supported transport. 672 ABNF: 674 bimi-location-header-uri = "l" *WSP "=" bimi-uri 676 a: location of the BIMI Evidence Document (URI; REQUIRED if the BIMI 677 Evidence Document was verified). Inserted by the MTA after 678 performing the required checks and obtaining the applicable domain's 679 published Assertion Record. The value of this tag is a URI 680 representing the location of the BIMI Evidence Document. HTTPS is 681 the only supported transport. 683 ABNF: 685 bimi-evidenced-location-header-uri = "a" *WSP "=" bimi-uri 687 And the formal definition of the BIMI Location Header, using ABNF, is 688 as follows: 690 bimi-location-header-location-only = bimi-location-header-uri 692 bimi-location-header-evidence-only = bimi-evidence-location-header-uri 694 bimi-location-header-both = bimi-location-header-uri bimi-evidence-location-header-uri 696 bimi-location-options = bimi-location-header-location-only / bimi-location-header-evidence-only / bimi-location-header-both 698 bimi-location-header = bimi-header-version bimi-sep bimi-location-options \[bimi-sep\] 700 6.3. BIMI-Indicator Header 702 BIMI-Indicator is the header a Mail Receiver inserts to pass a 703 verified Indicator to the MUA. 705 The header contains the SVG of the Indicator encoded as base64, and 706 is inserted by the MTA after performing the required checks and 707 obtaining the applicable domain's published Assertion Record. The 708 contents of this tag MUST match the SVG Indicator content retrieved 709 from the URI specified in the BIMI-Location header. If he Indicator 710 was supplied as a gzipped SVGZ file then the MTA MUST uncompress the 711 file before base64 encoding. 713 base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) 714 [ [FWS] "=" [ [FWS] "=" ] ] 716 And the formal definition of the BIMI Indicator Header, using ABNF, 717 is as follows: 719 bimi-indicator-header = bimi-sep base64string \[bimi-sep\] 721 6.4. Header Signing 723 If present, the BIMI-Selector header SHOULD be included in the DMARC- 724 aligned DKIM signature used to confirm authenticity of the message. 725 If it is not included in the DMARC-compliant DKIM signature, the 726 header SHOULD be ignored. 728 Receivers MAY choose to apply additional methods to validate the 729 BIMI-Selector header, for example by evaluating a trusted [ARC] 730 chain. In this case the Receiver MAY choose to treat the message as 731 if the BIMI-Selector header was signed. 733 The BIMI-Location and BIMI-Indicator headers MUST NOT be DKIM signed. 734 This header is untrusted by definition, and is only for use between 735 an MTA and its MUAs, after DKIM has been validated by the MTA. 736 Therefore, signing this header is meaningless, and any messages with 737 it signed are either coming from malicious or misconfigured third 738 parties. 740 7. Domain Owner Actions 742 This section includes a walk through of the actions a Domain Owner 743 takes when setting up Assertion Records and sending email messages. 745 7.1. Determine and Publish Indicator(s) for Use 747 Domain Owners should consider which Indicator file formats to choose 748 when setting up their BIMI Assertion Records. For a Sender, BIMI 749 provides control over which Indicators are eligible and can be chosen 750 for display, but not the ultimate manner in which the MUA will 751 display the Indicator. 753 7.2. Publish Assertion Records 755 For each set of Indicators and domains, publish the appropriate 756 Assertion Record as either "default" or a named selector as a DNS TXT 757 record within the appropriate "_bimi" namespace. 759 7.3. Manage multiple uses of the same Indicator(s) within a trust boundary 761 For Domain Owners with multiple domains that wish to share the same 762 set of Indicators within a trust boundary and only manage those 763 Indicators from a single DNS location, it is RECOMMENDED to use DNS 764 CNAMEs. 766 Using a CNAME here is functionally similar to the SPF redirect 767 modifier. Since BIMI does not require l= tags to be aligned to the 768 Author Domain, CNAMEs present a cleaner solution than extending the 769 protocol. 771 7.4. Set the headers on outgoing email as appropriate 773 Once a default Assertion Record has been published for an Author 774 Domain, all emails from this domain should display the appropriate 775 Indicator in participating MUAs. 777 If a non-default Indicator is desired, the BIMI-Selector header 778 should be set appropriately. If for some reason this selector cannot 779 be accessed by the Protocol Client, the fallback is the default 780 Assertion Record on the Organization domain. 782 The BIMI-Location header MUST NOT be set by email senders, and 783 Protocol Clients MUST ignore it. 785 8. Receiver Actions 787 This section includes a walk through of the actions a Protocol Client 788 takes when evaluating an email message for BIMI Assertion. 790 8.1. Authentication Requirements 792 Before applying BIMI processing for a message, a receiver MUST verify 793 that the message passed the following BIMI authentication 794 requirements: 796 1. If more than 1 RFC5322.From header is present in the message, or 797 any RFC5322.From header contains more than 1 email address then 798 BIMI processing MUST NOT be performed for this message. 800 2. Start with the DNS domain found in the RFC5322.From header in the 801 message. Define this DNS domain as the Author Domain. 803 3. Find the Organizational Domain for the Author Domain. Define 804 this DNS domain as the Author Organizational Domain. If the 805 Author Domain is an Organizational Domain then this will be 806 identical to the Author Domain. 808 4. Evaluate the [DMARC] result for the Author Domain. Define the 809 result as the BIMI DMARC Result. 811 5. If the BIMI DMARC result is not 'pass', then the receiver MAY 812 choose to apply additional authentication methods, for example by 813 evaluating a trusted [ARC] chain, a list of trusted forwarders, 814 or by applying a local policy. In this case the Receiver MAY 815 choose to treat the message as if the BIMI DMARC Result was 816 'pass'. 818 6. If the [DMARC] result for the Author Domain is not 'pass', and 819 the message could not be authenticated by any additional 820 authentication method, then BIMI processing MUST NOT be performed 821 for this message. 823 7. If the [DMARC] policy for the Author Domain or Author 824 Organizational Domain is p=none then BIMI processing MUST NOT be 825 performed for this message. 827 8. IF the [DMARC] record for the Author Domain or Author 828 Organizational Domain includes a subdomain policy, and that 829 subdomain policy is sp=none then BIMI processing MUST NOT be 830 performed for this message. 832 9. If the [DMARC] policy for the Author Domain or Author 833 Organizational Domain is p=quarantine, and the [DMARC] record 834 defines a percentage tag, then that tag MUST be pct=100, 835 otherwise BIMI processing MUST NOT be performed for this message. 837 8.2. Assertion Record Discovery 839 Through the BIMI Assertion Record (Section 5.2), Domain Owners use 840 DNS TXT records to advertise their preferences. Preference discovery 841 is accomplished via a method similar to the method used for [DMARC] 842 records. This method, and the important differences between BIMI and 843 [DMARC] mechanisms, are discussed below. 845 Assertion Record Discovery MUST NOT be attempted if the message 846 authentication fails per Receiver policy. 848 To balance the conflicting requirements of supporting wildcarding, 849 allowing subdomain policy overrides, and limiting DNS query load, 850 Protocol Clients MUST employ the following lookup scheme for the 851 appropriate BIMI record for the message: 853 1. Start with the DNS domain found in the RFC5322.From header in the 854 message. Define this DNS domain as the Author Domain. 856 2. If the message for which the Indicator is being determined 857 specifies a selector value in the BIMI Selector Header 858 (Section 6.1), use this value for the selector. Otherwise the 859 value 'default' MUST be used for the selector. 861 3. Clients MUST query the DNS for a BIMI TXT record at the DNS 862 domain constructed by concatenating the selector, the string 863 '_bimi', and the Author Domain. A possibly empty set of records 864 is returned. 866 4. Records that do not start with a "v=" tag that identifies the 867 current version of BIMI MUST be discarded. 869 5. If the set is now empty, the Client MUST query the DNS for a BIMI 870 TXT record at the DNS domain constructed by concatenating the 871 selector 'default', the string '_bimi', and the Organizational 872 Domain (as defined in [DMARC]) corresponding to the Author 873 Domain. A custom selector that does not exist falls back to 874 default._bimi., and NOT 875 ._bimi.. A possibly empty set of 876 records is returned. 878 6. Records that do not start with a "v=" tag that identifies the 879 current version of BIMI MUST be discarded. 881 7. If the remaining set contains multiple records or no records, 882 Assertion Record Discovery terminates and BIMI processing MUST 883 NOT be performed for this message. 885 8. If the remaining set contains only a single record, this record 886 is used for BIMI Assertion. 888 8.3. Indicator Discovery. 890 1. If the retrieved Assertion Record does not include a valid bimi- 891 location in the l= tag, then Indicator Discovery has failed, and 892 the Indicator MUST NOT be displayed. The bimi-location entry 893 MUST be a URI with a HTTPS transport. 895 2. If the retrieved Assertion Record includes a bimi-evidence- 896 location entry in the a= tag, and the receiver supports BIMI 897 Evidence Document validation, then proceed to the Indicator 898 Discovery With Evidence (Section 8.4) step. 900 3. If the receiver does not support BIMI Evidence Document 901 validation, or the retrieved Assertion Record does not include a 902 bimi-evidence-location entry, then proceed to the Indicator 903 Discovery Without Evidence (Section 8.5) step. 905 8.4. Indicator Discovery With Evidence. 907 Individual types of BIMI Evidence Document MAY specify extra 908 discovery and validation steps. These will be defined in separate 909 documents. 911 8.5. Indicator Discovery Without Evidence. 913 If an Assertion Record is found, and has an empty or missing bimi- 914 evidence-location entry then no evidence has is presented, and the 915 Indicator MUST be retrieved from the URI specified in the bimi- 916 location entry using the following algorithm: 918 1. Retrieve the SVG Indicator from the URI specified in the l= tag. 919 This MUST be a URI with a HTTPS transport. 921 2. If the TLS server identity certificate presented during the TLS 922 session setup does not chain-up to a root certificate the Client 923 trusts then Indicator validation has failed and the Indicator 924 MUST NOT be displayed. 926 3. Proceed to the Indicator Validation (Section 8.6) step. 928 8.6. Indicator Validation 930 1. Check the file size of the retrieved Indicator against 931 recommended maximum sizes as defined in this document, and in the 932 BIMI SVG document. A receiver MAY choose to implement their own 933 file size restrictions. If the Indicator is larger than the 934 maximum size the the receiver MAY choose not to display the 935 Indicator. A receiver MAY choose to implement the size limit as 936 a retrieval limit rather than retrieving the entire document and 937 then checking the size. 939 2. If the SVG Indicator is missing, or is not a valid SVG or SVGZ 940 document then validation has failed and the Indicator MUST NOT be 941 displayed. 943 3. Check the retrieved Indicator against the SVG validation steps 944 specified in this document, and in the BIMI SVG document. (Note 945 to WG, do we want to specify the SVG_1.2_PS profile here or leave 946 that to the other document?) 948 4. If Indicator verification has passed, and the Indicator is from a 949 trusted source, then the Indicator MAY be displayed per receiver 950 policy. 952 (Note to WG, add link to BIMI SVG document) 954 8.7. Affix BIMI Status to Authentication Results Header Field 956 Upon completion of Assertion Record Discovery, Indicator Discovery, 957 and Indicator Validation, an MTA SHOULD affix the result in the 958 Authentication-Results header using the following syntax, with the 959 following key=value pairs: 961 bimi: Result of the bimi lookup (plain-text; REQUIRED). Range of 962 values are 'pass' (BIMI successfully validated), 'none' (no BIMI 963 record present), 'fail' (syntax error in the BIMI record, failure in 964 Discovery or Validation steps, or some other error), 'temperror' (DNS 965 lookup problem), or 'skipped' (BIMI check was not performed, possibly 966 because the message did not comply with the minimum requirements such 967 as passing DMARC, or the MTA does not trust the sending domain). The 968 MTA MAY put comments in parentheses after bimi result, e.g., 969 "bimi=fail (Invalid SVG)", "bimi=skipped (sender not trusted)" or 970 "bimi=skipped (message failed DMARC)". 972 header.d: Domain of the BIMI Assertion Record which was evaluated 973 (plain-text; REQUIRED if bimi=pass). For example, this will be the 974 organizational domain if the BIMI lookup used the fallback record, 975 otherwise it will be the RFC5322.From domain. 977 header.selector: Selector of the BIMI Assertion Record which was 978 evaluated (plain-text; REQUIRED if bimi=pass). For example, if a 979 BIMI-Selector Header was present and used to discover a BIMI 980 Assertion Record then this will be the Selector used, otherwise this 981 will be 'default'. 983 policy.authority: Authority verification status of the Brand 984 Identifier (plain-text; REQUIRED if the BIMI Evidence Document was 985 checked). If the Authority Evidence presented in the BIMI Assertion 986 Record was checked and found to be valid then this MUST be set to 987 pass. If the validation failed then this MUST be set to fail. If no 988 Authority Evidence was presented, or the MTA did not check the 989 Authority Evidence then this SHOULD be set to none. 991 policy.authority-uri: The URI of the BIMI Evidence Document checked, 992 as found in the a= tag of the BIMI Assertion Record (plain-text; 993 OPTIONAL). 995 8.8. Handle Existing BIMI-Location and BIMI-Indicator Headers 997 Regardless of success of the BIMI lookup, if a BIMI-Location or a 998 BIMI-Indicator header is already present in a message it MUST be 999 either removed or renamed. This is because the MTA performing BIMI- 1000 related processing immediately prior to a Mail Delivery Agent (or 1001 within the same administrative realm) is the only entity allowed to 1002 specify the BIMI-Location or BIMI-Indicator headers (e.g. not the 1003 sending MTA, and not an intermediate MTA). Allowing one or more 1004 existing headers through to a MUA is a security risk. 1006 If the original email message had a DKIM signature, it has already 1007 been evaluated. Removing the BIMI-Location header at this point 1008 should not invalidate the signature since it should not be included 1009 within it per this spec. 1011 8.9. Construct BIMI-Location URI 1013 This header MUST NOT be added if Discovery or Validation steps 1014 failed. 1016 The URI used to retrieve the validated SVG Indicator. If the 1017 receiver extracted the Indicator from the BIMI Evidence Document then 1018 this SHOULD be the bimi-evidence-location added with a a= tag, 1019 otherwise it SHOULD be the bimi-location added with a l= tag. If 1020 both a= and l= tags are included then the MTA MUST perform checks to 1021 ensure that the SVG Indicator referenced by the bimi-location is 1022 identical to the SVG Indicator extracted from the BIMI Evidence 1023 Document. 1025 8.10. Construct BIMI-Indicator header 1027 This header MUST NOT be added if Discovery or Validation steps 1028 failed. 1030 Encode the SVG Indicator retrieved and validated during the Indicator 1031 Discovery and Indicator Validation steps as base64 encoded data. If 1032 the Indicator was compressed with gzip when retrieved then the data 1033 SHOULD NOT be uncompressed before being base64 encoded. 1035 The MTA MUST fold the header to be within the line length limits of 1036 [SMTP]. 1038 9. Security Considerations 1040 The consistent use of Brand Indicators is valuable for Domain Owners, 1041 Mail Receivers, and End Users. However, the routine display of brand 1042 Indicators represents an attractive target for abuse, especially for 1043 determined malicious actors. Great care is warranted. The 1044 discussion following as an incomplete list of considerations. 1046 9.1. Indirect Mail Flows 1048 If a mail store ingests a message from another mail store through 1049 some other means, the message may or may not have BIMI headers added 1050 already. If the receiving store trusts the other mail store, it may 1051 simply use existing headers. Or, it may re-evaluate BIMI policy and 1052 requirements, and create or replace the BIMI-Location header. 1054 9.2. Lookalike Domains and Copycat Indicators 1056 Publishing BIMI records is not sufficient for an MTA to signal to the 1057 MUA to load the BIMI Indicator. For example, the Domain Owner may 1058 also need to have a sufficiently strong reputation with the MTA. The 1059 receiver may use a manually maintained list of large brands, it may 1060 import a list from a third party of acceptable domains, or it may 1061 apply its own reputation heuristics before deciding whether or not to 1062 load the BIMI Indicator. BIMI does not specify what MTAs may bring 1063 to bear as additional factors. 1065 9.3. Large files and buffer overflows 1067 The MTA or MUA should perform some basic analysis and avoid loading 1068 Indicators that are too large or too small. The Receiver may choose 1069 to maintain a manual list and do the inspection of its list offline 1070 so it doesn't have to do it at time-of-scan. 1072 9.4. Slow DNS queries 1074 All email Receivers already have to query for DNS records, and all of 1075 them have built-in timeouts when performing DNS queries. 1076 Furthermore, the use of caching when loading Indicators can help cut 1077 down on load time. Virtually all email clients have some sort of 1078 image-downloading built-in and make decisions when to load or not 1079 load Indicators. 1081 9.5. Unaligned Indicators and asserting domains 1083 There is no guarantee that a group responsible for managing Brand 1084 Indicators will have access to put these Indicators directly in any 1085 specific location of a domain, and requiring that Indicators live on 1086 the asserted domain is too high a bar. Additionally, letting a brand 1087 have Indicator locations outside its domain may be desirable so that 1088 someone sending legitimate authenticated email on the Domain Owner's 1089 behalf can manage and set selectors as an authorized third party 1090 without requiring access to the Domain Owner's DNS or web services. 1092 9.6. Unsigned BIMI-Selector Header 1094 If a Domain Owner relies on SPF but not DKIM for email 1095 authentication, then adding a requirement of DKIM may create too high 1096 of a bar for that sender. On the other hand, Receivers doing BIMI 1097 assertion may factor in the lack of DKIM signing when deciding 1098 whether to add a BIMI-Location header. 1100 9.7. CGI scripts in Indicator payload 1102 MTAs and MVAs should aggressively police Indicators to ensure they 1103 are the Indicators they claim to be, are within appropriate size 1104 limits, and pass other sanity checks. Additionally, MTAs might cache 1105 good Indicators and serve them directly to their MUAs, which would in 1106 practice bypass any malicious dynamic payload set to trigger against 1107 an end user but not an MTA. 1109 9.8. Metadata in Indicators 1111 Domain Owners should be careful to strip any metadata out of 1112 published Indicators that they don't want to expose or which might 1113 bloat file size. MTAs and MVAs might wish to inspect and remove such 1114 data from Indicators before exposing them to end users. 1116 10. IANA Considerations 1118 IANA will need to reserve three new entries for the "Permanent 1119 Message Header Field Names" registry and create a registry for 1120 support file formats for BIMI. 1122 10.1. Permanent Header Field Updates 1124 Header field name: BIMI-Selector 1126 Applicable protocol: mail 1128 Status: standard 1130 Author/Change controller: IETF 1132 Specification document: This one 1134 Header field name: BIMI-Location 1136 Applicable protocol: mail 1138 Status: standard 1140 Author/Change controller: IETF 1142 Specification document: This one 1144 Header field name: BIMI-Indicator 1146 Applicable protocol: mail 1148 Status: standard 1150 Author/Change controller: IETF 1152 Specification document: This one 1154 10.2. Registry for Supported BIMI Formats 1156 Names of support file types supported by BIMI must be registered by 1157 IANA. 1159 New entries are assigned only for values that have been documented in 1160 a published RFC that has had IETF Review, per [IANA-CONSIDERATIONS]. 1161 Each method must register a name, the file extension, the 1162 specification that defines it, and a description. 1164 10.3. Other IANA needs 1166 NOTE TO WORKING GROUP: The registry for BIMI tags needs to be 1167 properly set up, as does the registry for validation actions. 1169 11. References 1171 11.1. Normative References 1173 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1174 Specifications: ABNF", January 2008, 1175 . 1177 [ARC] Andersen, K., Long, B., Blank, S., and M. Kucherawy, "The 1178 Authenticated Received Chain (ARC) Protocol", July 2019, 1179 . 1181 [Authentication-Results] 1182 Kucherawy, M., "Message Header Field for Indicating 1183 Message Authentication Status", August 2015, 1184 . 1186 [DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys 1187 Identified Mail (DKIM) Signatures", September 2011, 1188 . 1190 [DMARC] Kucherawy, M. and E. Zwicky, "Domain-based Message 1191 Authentication, Reporting, and Conformance (DMARC)", March 1192 2015, . 1194 [DNS] Mockapetris, P., "Domain names - implementation and 1195 specification", November 1987, 1196 . 1198 [EMAIL-ARCH] 1199 Crocker, D., "Internet Mail Architecture", July 2009, 1200 . 1202 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1203 Requirement Levels", March 1997, 1204 . 1206 [Logotype] Santesson, S., Housley, R., and T. Freemani, "Internet 1207 X.509 Public Key Infrastructure, Logotypes in X.509 1208 Certificates", February 2004, 1209 . 1211 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", October 1212 2008, . 1214 [SPF] Kitterman, S., "Sender Policy Framework (SPF) for 1215 Authorizing Use of Domains in Email, Version 1", April 1216 2014, . 1218 [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1219 Resource Identifier (URI): Generic Syntax", January 2005, 1220 . 1222 11.2. Informative References 1224 [BIMI-OVERVIEW] 1225 Blank, S., Kumaran, N., and J. Levine, "An Overview of the 1226 Design of BIMI", July 2020, 1227 . 1229 Appendix A. Example Selector Discovery (INFORMATIVE) 1231 This section shows several examples of how a receiving MTA should 1232 determine which Assertion Record to use depending on the BIMI- 1233 Selector header. 1235 A.1. No BIMI-Selector Header 1237 The domain example.com does not send with a BIMI-Selector header. 1239 From: sender@example.com 1241 The MTA would lookup default._bimi.example.com for the BIMI DNS 1242 record. 1244 A.2. With BIMI-Selector Header 1246 The domain example.com sends with a BIMI-Selector header: 1248 From: sender@example.com 1249 BIMI-Selector: v=BIMI1; s=selector; 1251 The MTA would lookup selector._bimi.example.com. 1253 A.3. Without BIMI-Selector Header on a subdomain 1255 The domain foo.example.com sends without a BIMI-Selector header: 1257 From: sender@foo.example.com 1259 The MTA would lookup default._bimi.foo.example.com for the BIMI DNS 1260 record. If it did not exist, it would lookup 1261 default._bimi.example.com. 1263 A.4. With BIMI-Selector Header on a subdomain 1265 The domain foo.example.com sends without a BIMI-Selector header: 1267 From: sender@foo.example.com 1268 BIMI-Selector: v=BIMI1; s=selector; 1270 The MTA would lookup selector._bimi.foo.example.com for the BIMI DNS 1271 record. If it did not exist, it would fall back to the lookup 1272 default._bimi.example.com. 1274 A.5. Invalid BIMI-Selector Header 1276 The domain example.com sends with a BIMI-Selector header, but does 1277 not include the required field 'v=': 1279 From: sender@example.com 1280 BIMI-Selector: s=selector; 1282 The MTA would ignore this header, and lookup 1283 default._bimi.example.com. 1285 Appendix B. Example Authentication-Results entry (INFORMATIONAL) 1287 This section shows example Authentication-Results stamps based on 1288 different BIMI lookup statuses. 1290 B.1. Successful BIMI lookup 1292 From: sender@example.com 1293 BIMI-Selector: v=BIMI1; s=selector; 1294 Authentication-Results: bimi=pass header.d=example.com header.selector=selector; 1296 B.2. No BIMI record 1298 From: sender@sub.example.com 1299 Authentication-Results: bimi=none; 1301 In this example, sub.example.com does not have a BIMI record at 1302 default._bimi.sub.example.com, nor does default._bimi.example.com 1304 B.3. Subdomain has no default record, but organizational domain does 1306 From: sender@sub.example.com 1307 Authentication-Results: bimi=pass header.d=example.com header.selector=default; 1309 B.4. Subdomain has no record for selector, but organization domain has a 1310 default 1312 From: sender@sub.example.com 1313 BIMI-Selector: v=BIMI1; s=selector; 1314 Authentication-Results: bimi=pass header.d=example.com header.selector=default; 1316 In this example, the sender specified a DNS record at 1317 selector._bimi.sub.example.com but it did not exist. The fallback is 1318 to use default._bimi.example.com, not selector._bimi.example.com even 1319 if that record exists. 1321 Appendix C. Example BIMI Headers Construction (INFORMATIONAL) 1323 This section shows how an example MTA might evaluate an incoming 1324 email for BIMI participation, and how it could share that 1325 determination with its MUA(s). 1327 C.1. MTA Receives an email 1329 The MTA receives the following DKIM signed message: 1331 DKIM-Signature: v=1; s=myExample; d=example.com; h=From;BIMI-Selector;Date;bh=...;b=... 1332 From: sender@example.com 1333 BIMI-Selector: v=BIMI1; s=brand; 1334 BIMI-Location: image.example.com/bimi/logo/example-bimi.svg 1335 Subject: Hi, this is a message from the good folks at Example Learning 1337 C.2. MTA does its authentication checks 1339 The receiving MTA receives the message and performs an SPF 1340 verification (which fails), a DKIM verification (which passes), and a 1341 DMARC verification (which passes). The domain is verified and has 1342 good reputation. The Receiver proceeds to perform a BIMI lookup. 1344 C.3. MTA performs BIMI Assertion 1346 The MTA sees that the message has a BIMI-Selector header, and it is 1347 covered by the DKIM-Signature, and the DKIM-Signature that passed 1348 DKIM is the one that covers the BIMI-Selector header. The MTA sees 1349 the header validates and contains 'v=BIMI1', and 's=brand'. It 1350 performs a DNS query for brand._bimi.example.com and retrieves: 1352 brand._bimi.example.com IN TXT "v=BIMI1; l=https://image.example.com/bimi/logo/" 1354 The MTA verifies the syntax of the BIMI DNS record, and it, too 1355 passes. 1357 The MTA knows it has previously retrieved the Indicator referenced by 1358 the BIMI DNS record, and had already successfully checked this 1359 Indicator against the published SVG profile. The MTA retrieves the 1360 Indicator from the cache. 1362 C.4. MTA appends to Authentication-Results 1364 The MTA computes and affixes the results of the BIMI to the 1365 Authentication-Results header: 1367 Authentication-Results: spf=fail smtp.mailfrom=example.com; 1368 dkim=pass (signature was verified) header.d=example.com; 1369 dmarc=pass header.from=example.com; 1370 bimi=pass header.d=example.com header.selector=brand; 1372 C.5. MTA Constructs BIMI-Location and BIMI-Indicator headers 1374 The MTA base64 encodes the retrieved Indicator and constructs a new 1375 BIMI-Indicator header. 1377 The MTA constructs a BIMI-Location header with a version tag, and an 1378 l tag indicating the URL from which the Indicator was retrieved. 1380 Finally, the MTA removes any existing BIMI-Location and BIMI- 1381 Indicator headers, and stamps the new ones: 1383 BIMI-Location: v=BIMI1; l=https://image.example.com/bimi/logo/ 1385 BIMI-Indicator: PD94bW...8L3N2Zz4K 1387 That the original sender signed a BIMI-Location header against this 1388 spec is irrelevant. It was used for DKIM validation and then thrown 1389 out by the MTA. 1391 C.6. The MUA displays the Indicator 1393 The mail is opened from the mail store in an MUA. The MUA performs 1394 locally defined checks to make sure that it can trust the BIMI- 1395 Indicator header. Finally, the MUA extracts the Indicator from the 1396 BIMI-Indicator header and displays it to the user. 1398 C.7. Acknowledgements 1400 Many people have contributed to the development of BIMI. Along with 1401 thanks to members of the current AuthIndicators Working Group, the 1402 editors wish to acknowledge the efforts of Sri Somanchi, Don 1403 Cardinal, Steve Jones, and John Levine. 1405 Authors' Addresses 1407 Seth Blank 1408 Valimail 1410 Email: seth@valimail.com 1412 Peter Goldstein 1413 Valimail 1415 Email: peter@valimail.com 1417 Thede Loder 1418 Skyelogic Works LLC 1420 Email: thede@skyelogicworks.com 1422 Terry Zink 1423 Zink Magical Contraptions 1425 Email: tzink@terryzink.com 1427 Marc Bradshaw 1428 Fastmail 1430 Email: marc@fastmailteam.com