idnits 2.17.1 draft-blank-ietf-bimi-02.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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 54 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an Assertion Record is found, and it has empty bimi-location and bimi-evidence-location then this is a Declination to Publish record. BIMI processing MUST not occur on this message and the MTA SHOULD reflect this in the Authentication-Results header by adding a bimi=declined entry. -- The document date (8 March 2021) is 1143 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DMARC' is mentioned on line 187, but not defined == Missing Reference: 'URI' is mentioned on line 554, but not defined == Missing Reference: 'SMTP' is mentioned on line 628, but not defined == Missing Reference: 'ARC' is mentioned on line 758, but not defined == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 1194, but not defined ** Downref: Normative reference to an Informational RFC: RFC 5598 ** Downref: Normative reference to an Informational RFC: RFC 7489 ** Downref: Normative reference to an Experimental RFC: RFC 8617 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network S. Blank 3 Internet-Draft P. Goldstein 4 Intended status: Standards Track Valimail 5 Expires: 9 September 2021 T. Loder (ed) 6 Skye Logicworks LLC 7 T. Zink (ed) 9 M. Bradshaw (ed) 10 Fastmail 11 8 March 2021 13 Brand Indicators for Message Identification (BIMI) 14 draft-blank-ietf-bimi-02 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 5 August 2021. 47 Copyright Notice 49 Copyright (c) 2021 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . 7 66 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.3. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 8 68 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 8 69 3.1. BIMI Assertion . . . . . . . . . . . . . . . . . . . . . 9 70 3.2. Indicator . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.3. Mark Verifying Authority (MVA) . . . . . . . . . . . . . 9 72 3.4. BIMI Evidence Document . . . . . . . . . . . . . . . . . 9 73 3.5. Verified Mark Certificate (VMC) . . . . . . . . . . . . . 9 74 3.6. Protocol Client . . . . . . . . . . . . . . . . . . . . . 10 75 3.7. Verifying Protocol Client . . . . . . . . . . . . . . . . 10 76 4. BIMI DNS Records . . . . . . . . . . . . . . . . . . . . . . 10 77 4.1. MUA Obligations . . . . . . . . . . . . . . . . . . . . . 11 78 4.2. Assertion Record Definition . . . . . . . . . . . . . . . 11 79 4.2.1. Declination to Publish . . . . . . . . . . . . . . . 13 80 4.2.2. Supported Image Formats for l= tag . . . . . . . . . 13 81 4.3. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5. BIMI Header Fields . . . . . . . . . . . . . . . . . . . . . 14 83 5.1. BIMI-Selector Header . . . . . . . . . . . . . . . . . . 14 84 5.2. BIMI-Location Header . . . . . . . . . . . . . . . . . . 15 85 5.3. BIMI-Indicator Header . . . . . . . . . . . . . . . . . . 16 86 5.4. Header Signing . . . . . . . . . . . . . . . . . . . . . 16 87 6. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . 17 88 6.1. Determine and Publish Indicator(s) for Use . . . . . . . 17 89 6.2. Publish Assertion Records . . . . . . . . . . . . . . . . 17 90 6.3. Manage multiple uses of the same Indicator(s) within a 91 trust boundary . . . . . . . . . . . . . . . . . . . . . 17 92 6.4. Set the headers on outgoing email as appropriate . . . . 17 93 7. Receiver Actions . . . . . . . . . . . . . . . . . . . . . . 18 94 7.1. Authentication Requirements . . . . . . . . . . . . . . . 18 95 7.2. Assertion Record Discovery . . . . . . . . . . . . . . . 19 96 7.3. Indicator Discovery. . . . . . . . . . . . . . . . . . . 20 97 7.4. Indicator Discovery With Evidence. . . . . . . . . . . . 20 98 7.5. Indicator Discovery Without Evidence. . . . . . . . . . . 21 99 7.6. Indicator Validation . . . . . . . . . . . . . . . . . . 21 100 7.7. Affix BIMI Status to Authentication Results Header 101 Field . . . . . . . . . . . . . . . . . . . . . . . . . 22 102 7.8. Handle Existing BIMI-Location and BIMI-Indicator 103 Headers . . . . . . . . . . . . . . . . . . . . . . . . 23 104 7.9. Construct BIMI-Location URI . . . . . . . . . . . . . . . 23 105 7.10. Construct BIMI-Indicator header . . . . . . . . . . . . . 23 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 107 8.1. Indirect Mail Flows . . . . . . . . . . . . . . . . . . . 24 108 8.2. Lookalike Domains and Copycat Indicators . . . . . . . . 24 109 8.3. Large files and buffer overflows . . . . . . . . . . . . 24 110 8.4. Slow DNS queries . . . . . . . . . . . . . . . . . . . . 24 111 8.5. Unaligned Indicators and asserting domains . . . . . . . 25 112 8.6. Unsigned BIMI-Selector Header . . . . . . . . . . . . . . 25 113 8.7. CGI scripts in Indicator payload . . . . . . . . . . . . 25 114 8.8. Metadata in Indicators . . . . . . . . . . . . . . . . . 25 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 116 9.1. Permanent Header Field Updates . . . . . . . . . . . . . 25 117 9.2. Registry for Supported BIMI Formats . . . . . . . . . . . 26 118 9.3. Other IANA needs . . . . . . . . . . . . . . . . . . . . 26 119 10. Normative References . . . . . . . . . . . . . . . . . . . . 26 120 11. Informative References . . . . . . . . . . . . . . . . . . . 27 121 Appendix A. Example Selector Discovery (INFORMATIVE) . . . . . . 28 122 A.1. No BIMI-Selector Header . . . . . . . . . . . . . . . . . 28 123 A.2. With BIMI-Selector Header . . . . . . . . . . . . . . . . 28 124 A.3. Without BIMI-Selector Header on a subdomain . . . . . . . 28 125 A.4. With BIMI-Selector Header on a subdomain . . . . . . . . 28 126 A.5. Invalid BIMI-Selector Header . . . . . . . . . . . . . . 29 127 Appendix B. Example Authentication-Results entry 128 (INFORMATIONAL) . . . . . . . . . . . . . . . . . . . . . 29 129 B.1. Successful BIMI lookup . . . . . . . . . . . . . . . . . 29 130 B.2. No BIMI record . . . . . . . . . . . . . . . . . . . . . 29 131 B.3. Declination to Publish . . . . . . . . . . . . . . . . . 29 132 B.4. Subdomain has no default record, but organizational domain 133 does . . . . . . . . . . . . . . . . . . . . . . . . . . 29 134 B.5. Subdomain and orgznizational domain have no record for 135 selector, but organization . . . . . . . . . . . . . . . 30 136 B.6. Subdomain has no record for selector, but organization 137 domain does . . . . . . . . . . . . . . . . . . . . . . . 30 138 Appendix C. Example BIMI Headers Construction (INFORMATIONAL) . 30 139 C.1. MTA Receives an email . . . . . . . . . . . . . . . . . . 30 140 C.2. MTA does its authentication checks . . . . . . . . . . . 30 141 C.3. MTA performs BIMI Assertion . . . . . . . . . . . . . . . 31 142 C.4. MTA appends to Authentication-Results . . . . . . . . . . 31 143 C.5. MTA Constructs BIMI-Location and BIMI-Indicator 144 headers . . . . . . . . . . . . . . . . . . . . . . . . . 31 145 C.6. The MUA displays the Indicator . . . . . . . . . . . . . 32 146 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 32 147 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 149 1. Introduction 151 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 152 The source for this draft is maintained in GitHub at: 153 https://github.com/BLAHBLAHBLAH (https://github.com/BLAHBLAHBLAH) 155 This document defines Brand Indicators for Message Identification 156 (BIMI), which enables Domain Owners to coordinate with Mail Box 157 Providers (MBPs), Mail Transfer Agents (MTAs), and Mail User Agents 158 (MUAs) in the display of brand-specific Indicators next to properly 159 authenticated messages. 161 BIMI is designed to be open and to work at Internet scale. BIMI is 162 intended to drive adoption of email authentication best practices by 163 leveraging existing DMARC [RFC7489] policies, the supporting 164 authentication methods DKIM [RFC6376] and SPF [RFC7208], and other 165 associated standards such as ARC [RFC8617]. 167 The approach taken by BIMI is heavily influenced by the approach 168 taken in DKIM [RFC6376], in that BIMI: 170 * has no dependency on the deployment of any new Internet protocols 171 or services for indicator registration or revocation; 173 * makes no attempt to include encryption as part of the mechanism; 175 * is compatible with the existing email infrastructure and 176 transparent to the fullest extent possible; 178 * requires minimal new infrastructure; 180 * can be implemented independently of clients in order to reduce 181 deployment time; 183 * can be deployed incrementally; and 185 * allows delegation of indicator hosting to third parties. 187 To participate in BIMI, Domain Owners MUST have a strong [DMARC] 188 policy (quarantine or reject) on both the Organizational Domain, and 189 the RFC5322.From Domain of the message. Quarantine policies MUST NOT 190 have a pct less than pct=100. 192 This document defines how Domain Owners specify their desired 193 indicators through the BIMI Assertion Record in DNS and how that 194 record is to be interpreted by MTAs and MUAs. This document does not 195 cover how domains or indicators are verified, how MUAs should display 196 the indicators, or how other protocols (i.e. IMAP, JMAP) can be 197 extended to work with BIMI. Other documents may cover these topics. 198 MUAs and Mail Box Providers (MBPs) are free to define their own 199 policies for making use of BIMI data and for indicator display as 200 they see fit. 202 2. Overview 204 The Sender Policy Framework (SPF [RFC7208]), DomainKeys Identified 205 Mail (DKIM [RFC6376]), "Domain-based Message Authentication, 206 Reporting, and Conformance" (DMARC [RFC7489]), and Authenticated 207 Received Chain (ARC [RFC8617]) provide mechanisms for domain-level 208 authentication of email messages. They enable cooperating email 209 senders and receivers to distinguish messages that are authorized to 210 use the domain name from those that are not. BIMI relies on these 211 authentication protocols, but is not a new authentication protocol 212 itself. 214 MUAs are increasingly incorporating graphical Indicators to indicate 215 the identity of the sender of a message. While a discussion of the 216 merits of doing this is beyond the scope of this document, at present 217 there are no open standards for publishing and aiding discovery of 218 preferred Indicators or for tying display of them to authentic 219 messages only. 221 Because of the desire to have brand-specific Indicators available, 222 some mail-receiving organizations have developed closed systems for 223 obtaining and displaying Brand Indicators for select domains. While 224 this has enabled these mail-receiving organizations to display brand 225 Indicators for a limited subset of messages, this closed approach has 226 a number of downsides: 228 1. It puts a significant burden on each mail-receiving organization, 229 because they must identify and manage a large database of Brand 230 Indicators. 232 2. Scalability is challenging for closed systems that attempt to 233 capture and maintain complete sets of data across the whole of 234 the Internet. 236 3. A lack of uniformity across different mail-receiving 237 organizations - each organization will have its own Indicator 238 set, which may or may not agree with those maintained by other 239 organizations for any given domain. 241 4. Domain Owners have limited ability to influence the Brand 242 Indicator for the domain(s) they own, and any ability they do 243 have is likely to be dependent upon direct coordination with each 244 of many mail-receiving organizations. 246 5. Many Domain Owners have no ability to participate whatsoever as 247 they do not have the appropriate relationships to coordinate with 248 mail-receiving organizations. 250 6. MUAs that are not associated with a particular mail-receiving 251 organization are likely to be disadvantaged, because they are 252 unlikely to receive Indicators in a standardized manner or 253 optimized for their user interfaces. 255 This shows the need for a standardized mechanism by which Domain 256 Owners interested in ensuring that their Indicators are displayed 257 correctly and appropriately can publish and distribute Brand 258 Indicators for use by any participating MUA. 260 BIMI removes the substantial burden of curating and maintaining an 261 Indicator database from MUAs and MBPs, and allows each domain owner 262 to manage their own Indicators. As an additional benefit, mail- 263 originating organizations are incentivized to authenticate their 264 email as doing so will enable them to influence how email and 265 Indicators from the organization are displayed. 267 The structure of BIMI is as follows: 269 1. Domain Owners: 271 * Fully implement the DMARC [RFC7489] mechanism, to include: 273 - Creating and publishing in DNS [RFC1035] a DMARC [RFC7489] 274 policy record that meets the following criteria: 276 o The policy record MUST express either a Requested Mail 277 Receiver policy of "quarantine" with an effective 278 percentage of 100%, or a Requested Mail Receiver policy 279 of "reject" (with any percentage value). 281 o Is a subdomain policy is published it MUST NOT be "none" 283 o Be published for the Organizational Domain, and any 284 subdomains thereof 286 - Deploying authentication technologies to ensure Identifier 287 Alignment 289 * Publish their preferred Brand Indicators via the DNS 290 [RFC1035]. 292 2. Senders: Ensure mail is properly authenticated, and has a 293 sufficiently strict DMARC [RFC7489] policy. 295 3. MTAs and MBPs: 297 * Confirm authenticity of the message using DMARC [RFC7489] and 298 whatever other authentication mechanisms they wish to apply. 300 * Check for a corresponding BIMI record, obtaining references to 301 the indicator media and optional substantiation of indicator 302 ownership rights 304 * If both the message is authentic and the logo is deemed 305 acceptable, the receiver adds a header to the message which 306 can be used by the MUA to obtain the Domain Owner's preferred 307 brand indicator. 309 4. MUA: retrieves and displays the brand indicator as appropriate 310 based on its policy and user interface. 312 The purpose of this structure is to reduce operational complexity at 313 each step. It is also to consolidate validation and Indicator 314 selection operations into the MTA, so that Domain Owners need only 315 publish a few simple records and MUAs only need simple display logic. 317 It is expected that MBPs implementing BIMI will do so in both their 318 MTAs and MUAs. 320 #Requirements {#requirements} 322 Specification of BIMI in this document is guided by the following 323 high-level goals, security dependencies, detailed requirements, and 324 items that are documented as out of scope. 326 An overview of the security challenges and design decisions is 327 documented at [BIMI-OVERVIEW]. 329 2.1. High-Level Goals 331 BIMI has the following high-level goals: 333 * Allow Domain Owners to suggest appropriate Indicators for display 334 with authenticated messages originating from their domains. 336 * Enable the authors of MUAs to display meaningful Indicators 337 associated with the Domain Owner to recipients of authenticated 338 email. 340 * Provide mechanisms to prevent attempts by malicious Domain Owners 341 to fraudulently represent messages from their domains as 342 originating with other entities. 344 * Work at Internet Scale. 346 * Encourage the adoption of Email Authentication Best Practices. 348 2.2. Security 350 Brand Indicators are a potential vector for abuse. BIMI creates a 351 relationship between sending organization and Mail Receiver so that 352 the receiver can display appropriately designated Indicators if the 353 sending domain is verified and has meaningful reputation with the 354 receiver. Without verification and reputation, there is no way to 355 prevent a bad actor exxample.com from using example.com's Brand 356 Indicators and behaving maliciously. This document does not cover 357 the different verification and reputation mechanisms available, but 358 BIMI relies upon them to be in deployed in order to control abuse. 360 2.3. Out of Scope 362 Several topics and issues are specifically out of scope for the 363 initial version of this work. These include the following: 365 * Publishing policy other than via the DNS. 367 * Specific requirements for Indicator display on MUAs. 369 * The explicit mechanisms used by Verifying Protocol Clients - this 370 will be deferred to a later document. 372 3. Terminology and Definitions 374 This section defines terms used in the rest of the document. 376 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 377 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 378 document are to be interpreted as described in BCP 14 379 (https://tools.ietf.org/html/bcp14) [RFC2119] [RFC8174] when, and 380 only when, they appear in all capitals, as shown here. 382 Readers are encouraged to be familiar with the contents of [RFC5598]. 383 In particular, that document defines various roles in the messaging 384 infrastructure that can appear the same or separate in various 385 contexts. For example, a Domain Owner could, via the messaging 386 mechanisms on which BIMI is based, delegate reponsibility for 387 providing preferred brand indicators to a third party with another 388 role. This document does not address the distinctions among such 389 roles; the reader is encouraged to become familiar with that material 390 before continuing. 392 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 394 "Author Domain", "Domain Owner", "Organizational Domain", and "Mail 395 Receiver" are imported from DMARC [RFC7489] Section 3. 397 3.1. BIMI Assertion 399 The mechanism through which a Protocol Client verifies the BIMI 400 Assertion Record and constructs the URI(s) to the requested 401 Indicator(s) to be placed in the BIMI-Location header. 403 3.2. Indicator 405 The icon, logo, image, mark, or other graphical representation of the 406 brand. The Indicator is defined in a common image format with 407 restrictions detailed in the Assertion Record Definition (#assertion- 408 record-definition). 410 3.3. Mark Verifying Authority (MVA) 412 An entity or organization that can provide evidence of verification 413 of Indicators asserted by a Domain Owner to Verifying Protocol 414 Clients. The MVA may choose to uphold and confirm the meeting of 415 certain Indicator standards (ie. size, trademark, content, etc). 417 3.4. BIMI Evidence Document 419 A document published by a Mark Verifying Authority to assert evicence 420 of verification. These are defined in a separate document. 422 3.5. Verified Mark Certificate (VMC) 424 A certificate issued by a Certificate Authority in accordance with 425 the Verified Mark Certificate Guidelines. These guidelines are 426 defined in a separate document. 428 A Verified Mark Certificate is one example of a BIMI Evidence 429 Document. 431 3.6. Protocol Client 433 An entity designed to obtain and correctly interpret the records 434 defined in this specification for the purpose of discovering and 435 fetching published Indicators. 437 3.7. Verifying Protocol Client 439 A Protocol Client that uses optional capabilities to obtain and 440 evaluate evidence concerning the Domain Owner's rights to use the 441 published Indicators. 443 4. BIMI DNS Records 445 Domain owners publish BIMI policies by adding BIMI Assertion Records 446 in the DNS as TXT records. 448 Published policies are interpreted and applied by Protocol Clients. 449 A Domain Owner signals intended BIMI participation for one or more of 450 its domains by publishing an Assertion Record in a subdomain under 451 it. In doing so, Domain Owners make specific requests of MUAs 452 regarding the preferred set of Indicators to be displayed with 453 messages that are confirmed to be authorized to appear from the 454 Domain Owner's domain. 456 The use of BIMI is opt-in. Receivers default to performing no BIMI- 457 specific message handling until they choose to do so, and then only 458 if a BIMI record for the sender's domain is found. 460 BIMI's use of the DNS is driven in part by BIMI's use of domain names 461 as the basis of sender identity and message authentication. Use of 462 the DNS as the policy publication service also has the benefit of 463 reusing an extremely well-established operations, administration, and 464 management infrastructure, rather than creating a new one. 466 BIMI's policy payload is intentionally only published via a DNS 467 record and not via one or more email headers. This serves three 468 purposes: 470 1. There is one and only one mechanism for both simple and complex 471 policies to be published. 473 2. Operational complexity is reduced. MTAs only need to check a 474 single record in a consistent manner to discover and enforce 475 policy. 477 3. Indicators SHOULD be verified and cached in advance, so that 478 malicious headers cannot be used as an attack vector. 480 Per DNS [RFC1035], a TXT record can comprise several "character- 481 string" objects. BIMI TXT records with multiple strings must be 482 treated in an identical manner to SPF Section 3.3 483 (https://tools.ietf.org/html/rfc7208#section-3.3). 485 4.1. MUA Obligations 487 MUAs implementing the BIMI mechanism SHOULD make a best-effort 488 attempt to adhere to the Domain Owner's published BIMI policy. 489 However, MUAs have final control over the user interface published to 490 their end users, and MAY use alternate Indicators than those 491 specified in the BIMI assertion record or no Indicator at all. 493 4.2. Assertion Record Definition 495 All Domain Owner BIMI preferences are expressed in DNS TXT records 496 published in subdomains named "_bimi". Multiple sets of preferences 497 can be associated with a single RFC5322.From domain. To distinguish 498 between these different preferences, BIMI defines and uses 499 [selectors]{#selectors}. Senders declare which selector to use for a 500 given message by specifying the selector in an optional BIMI-Selector 501 header (#bimi-selector). 503 For example, the Domain Owner of "example.com" would post BIMI policy 504 in a TXT record at "default._bimi.example.com". Similarly, a Mail 505 Receiver wishing to query for BIMI policy regarding mail with an 506 RFC5322.From Author Domain of "example.com" and a selector "default" 507 (the default) would query the TXT record located at the subdomain of 508 "default._bimi.example.com". The DNS-based BIMI policy record is 509 referred to as the "BIMI Assertion Record" or "Assertion Record". 511 BIMI Assertion Records follow the extensible "tag-value" syntax for 512 DNS-based key records as defined in DKIM [RFC6376]. 514 Assertion Records are defined precisely. Mail receivers MUST NOT 515 attempt to fix syntactical or capitalization errors. If a required 516 tag is missing, or its value not well-formed, it is an error. 518 This section creates a registry for known BIMI tags and registers the 519 initial set defined in this document. Only tags defined in this 520 document or in later extensions, and thus added to the registry, are 521 to be processed; unknown tags MUST be ignored. 523 The following tags are introduced as the initial valid BIMI tags: 525 v= Version (plain-text; REQUIRED). Identifies the record retrieved 526 as a BIMI record. It MUST have the value of "BIMI1" for 527 implementations compliant with this version of BIMI. The value of 528 this tag MUST match precisely; if it does not match or it is absent, 529 the entire retrieved record MUST be ignored. It MUST be the first 530 tag in the list. 532 ABNF: 534 bimi-version = %x76 *WSP "=" *WSP %x42.49.4d.49 1DIGIT 536 a= Authority Evidence Location (plain-text; URI; OPTIONAL). If 537 present, this tag MUST have an empty value or its value MUST be a 538 single URI. An empty value for the tag is interpreted to mean the 539 Domain Owner does not wish to publish or does not have authority 540 evidence to disclose. The URI, if present, MUST contain a fully 541 qualified domain name (FQDN) and MUST specify HTTPS as the URI scheme 542 ("https"). The URI SHOULD specify the location of a publicly 543 retrievable BIMI Evidence Document. The format for evidence 544 documents is defined in a separate document. 546 If the a= tag is not present, it is assumed to have an empty value. 548 ABNF: 550 bimi-evidence-location = %x61 *WSP "=" bimi-uri 552 bimi-uri = \[FWS\] URI \[FWS\] 554 ; "URI" is imported from [URI] 555 ; HTTPS only 556 ; commas within a URI (ASCII ; 0x2C) MUST be encoded 558 l= location (URI; REQUIRED). The value of this tag is either empty 559 indicating declination to publish, or a single URI representing the 560 location of a Brand Indicator file. The only supported transport is 561 HTTPS. 563 ABNF: 565 bimi-location = %x6c *WSP "=" bimi-uri 567 Therefore, the formal definition of the BIMI Assertion Record, using 568 ABNF [RFC5234], is as follows: 570 bimi-sep = *WSP %x3b *WSP 572 bimi-record = bimi-version (bimi-sep bimi-location) (bimi-sep bimi-evidence-location) \[bimi-sep\] 574 ; components other than bimi-version may appear in any order 576 4.2.1. Declination to Publish 578 If both the "l=" and "a=" tags are empty, it is an explicit refusal 579 to participate in BIMI. This is distinct from not publishing a BIMI 580 record. For example, an empty BIMI record enables a Domain Owner to 581 decline BIMI participation for a subdomain when its organizational 582 domain has default Indicators available. Furthermore, messages sent 583 using a selector that has declined to publish will not show an 584 Indicator while messages with other selectors would display normally. 586 An explicit declination to publish looks like: 588 v=BIMI1; l=; a=; 590 4.2.2. Supported Image Formats for l= tag 592 Any format in the BIMI-formats IANA registry are acceptable targets 593 for the l= tag. If an l= tag URI ends with any other image format 594 suffix, or if the document retrievable from the location(s) in the l= 595 tag are of any other format, the evaluation of the record MUST be 596 treated as a permanent error. 598 As of the publishing of this document, only SVG and SVGZ, as defined 599 in RFC6170 section 5.2 (https://tools.ietf.org/html/rfc6170#section- 600 5.2) is acceptable in the l= tag. Further restrictions apply to the 601 SVG; these are documented elsewhere. 603 4.3. Selectors 605 To support publishing and display of more than one distinct Brand 606 Indicator per domain, the brand Indicator namespace is subdivided for 607 publishing of multiple Assertion Records using "selectors". 608 Selectors allow the Domain Owner to choose the brand Indicator, for 609 example, by type of recipient, by message source, or by other 610 considerations like seasonal branding. BIMI selectors are modeled 611 after DKIM selectors (https://tools.ietf.org/html/rfc6376#section- 612 3.1). 614 The selector "default" is the default Assertion Record. Domain 615 Owners can specify which other selector to use on a per-message basis 616 by utilizing the BIMI-Selector Header (#bimi-selector). 618 Periods are allowed in selectors and are component separators. When 619 BIMI Assertion Records are retrieved from the DNS, periods in 620 selectors define DNS label boundaries in a manner similar to the 621 conventional use in domain names. In a DNS implementation, this can 622 be used to allow delegation of a portion of the selector namespace. 624 ABNF: 626 selector = sub-domain *( "." sub-domain ) 628 ; from [SMTP] Domain, 630 ; excluding address-literal 632 The number of selectors for each domain is determined by the Domain 633 Owner. Many Domain Owners will be satisfied with just one selector, 634 whereas organizations with more complex branding requirements can 635 choose to manage disparate selectors. BIMI sets no maximum limit on 636 the number of selectors. 638 5. BIMI Header Fields 640 Once BIMI policies are published in DNS via Assertion Records, Domain 641 Owners can provide additional guidance to Mail Receivers, and Mail 642 Receivers to their MUAs through the use of BIMI header fields. 644 BIMI header fields are case insensitive. If a required tag is 645 missing, it is an error. 647 5.1. BIMI-Selector Header 649 BIMI DNS records are placed in ._bimi., and by 650 default they are placed in default._bimi.. That is, for 651 example.com, the default Assertion Record is located in the DNS at 652 default._bimi.example.com. However, a Domain Owner may override the 653 use of the default selector and specify the use of an alternative 654 using the RFC5322-compliant header 'BIMI-Selector'. The BIMI- 655 Selector header consists of key value pairs: 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 retrieved record MUST be 661 ignored. It MUST be the first tag in the list. 663 ABNF: 665 bimi-header-version = "v" *WSP "=" *WSP "BIMI" 1DIGIT 667 s= Selector (plain-text; REQUIRED). The location of the BIMI DNS 668 record, when combined with the RFC5322.From domain. 670 ABNF: 672 bimi-selector = "s" *WSP "=" *WSP selector 674 And the formal definition of the BIMI Selector Header, using ABNF, is 675 as follows: 677 bimi-selector-header = bimi-header-version bimi-sep bimi-selector \[bimi-sep\] 679 5.2. BIMI-Location Header 681 BIMI-Location is the header a Mail Receiver inserts that tells the 682 MUA where to get the BIMI Indicator from. 684 The syntax of the header is as follows: 686 v= Version (plain-text; REQUIRED). The version of BIMI. It MUST 687 have the value of "BIMI1" for implementations compliant with this 688 version of BIMI. The value of this tag MUST match precisely; if it 689 does not or it is absent, he entire header MUST be ignored. It MUST 690 be the first tag in the list. 692 The ABNF for bimi-header-version is imported exactly from the 693 [BIMI Selector Header](#bimi-selector). 695 l: location of the BIMI Indicator (URI; OPTIONAL if a bimi-evidence- 696 location-header-uri is specified, otherwise REQUIRED.). Inserted by 697 the MTA after performing the required checks and obtaining the 698 applicable domain's published Assertion Record. The value of this 699 tag is a URI representing the location of the Brand Indicator file. 700 HTTPS is the only supported transport. 702 ABNF: 704 bimi-location-header-uri = "l" *WSP "=" bimi-uri 706 a: location of the BIMI Evidence Document (URI; REQUIRED if the BIMI 707 Evidence Document was verified). Inserted by the MTA after 708 performing the required checks and obtaining the applicable domain's 709 published Assertion Record. The value of this tag is a URI 710 representing the location of the BIMI Evidence Document. HTTPS is 711 the only supported transport. 713 ABNF: 715 bimi-evidenced-location-header-uri = "a" *WSP "=" bimi-uri 716 And the formal definition of the BIMI Location Header, using ABNF, is 717 as follows: 719 bimi-location-header-location-only = bimi-location-header-uri 721 bimi-location-header-evidence-only = bimi-evidence-location-header-uri 723 bimi-location-header-both = bimi-location-header-uri bimi-evidence-location-header-uri 725 bimi-location-options = bimi-location-header-location-only / bimi-location-header-evidence-only / bimi-location-header-both 727 bimi-location-header = bimi-header-version bimi-sep bimi-location-options \[bimi-sep\] 729 5.3. BIMI-Indicator Header 731 BIMI-Indicator is the header a Mail Receiver inserts to pass a 732 verified Indicator to the MUA. 734 The header contains the SVG of the Indicator encoded as base64, and 735 is inserted by the MTA after performing the required checks and 736 obtaining the applicable domain's published Assertion Record. The 737 contents of this tag MUST match the SVG Indicator content retrieved 738 from the URI specified in the BIMI-Location header. If he Indicator 739 was supplied as a gzipped SVGZ file then the MTA MUST uncompress the 740 file before base64 encoding. 742 base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) 743 [ [FWS] "=" [ [FWS] "=" ] ] 745 And the formal definition of the BIMI Indicator Header, using ABNF, 746 is as follows: 748 bimi-indicator-header = bimi-sep base64string \[bimi-sep\] 750 5.4. Header Signing 752 If present, the BIMI-Selector header SHOULD be included in the DMARC- 753 aligned DKIM signature used to confirm authenticity of the message. 754 If it is not included in the DMARC-compliant DKIM signature, the 755 header SHOULD be ignored. 757 Receivers MAY choose to apply additional methods to validate the 758 BIMI-Selector header, for example by evaluating a trusted [ARC] 759 chain. In this case the Receiver MAY choose to treat the message as 760 if the BIMI-Selector header was signed. 762 The BIMI-Location and BIMI-Indicator headers MUST NOT be DKIM signed. 763 This header is untrusted by definition, and is only for use between 764 an MTA and its MUAs, after DKIM has been validated by the MTA. 765 Therefore, signing this header is meaningless, and any messages with 766 it signed are either coming from malicious or misconfigured third 767 parties. 769 6. Domain Owner Actions 771 This section includes a walk through of the actions a Domain Owner 772 takes when setting up Assertion Records and sending email messages. 774 6.1. Determine and Publish Indicator(s) for Use 776 Domain Owners should consider which Indicator file formats to choose 777 when setting up their BIMI Assertion Records. For a Sender, BIMI 778 provides control over which Indicators are eligible and can be chosen 779 for display, but not the ultimate manner in which the MUA will 780 display the Indicator. 782 6.2. Publish Assertion Records 784 For each set of Indicators and domains, publish the appropriate 785 Assertion Record as either "default" or a named selector as a DNS TXT 786 record within the appropriate "_bimi" namespace. 788 6.3. Manage multiple uses of the same Indicator(s) within a trust 789 boundary 791 For Domain Owners with multiple domains that wish to share the same 792 set of Indicators within a trust boundary and only manage those 793 Indicators from a single DNS location, it is RECOMMENDED to use DNS 794 CNAMEs. 796 Using a CNAME here is functionally similar to the SPF redirect 797 modifier. Since BIMI does not require l= tags to be aligned to the 798 Author Domain, CNAMEs present a cleaner solution than extending the 799 protocol. 801 6.4. Set the headers on outgoing email as appropriate 803 Once a default Assertion Record has been published for an Author 804 Domain, all emails from this domain should display the appropriate 805 Indicator in participating MUAs. 807 If a non-default Indicator is desired, the BIMI-Selector header 808 should be set appropriately. If for some reason this selector cannot 809 be accessed by the Protocol Client, the fallback is the default 810 Assertion Record on the Organization domain. 812 The BIMI-Location header MUST NOT be set by email senders, and 813 Protocol Clients MUST ignore it. 815 7. Receiver Actions 817 This section includes a walk through of the actions a Protocol Client 818 takes when evaluating an email message for BIMI Assertion. 820 7.1. Authentication Requirements 822 Before applying BIMI processing for a message, a receiver MUST verify 823 that the message passed the following BIMI authentication 824 requirements: 826 1. If more than 1 RFC5322.From header is present in the message, or 827 any RFC5322.From header contains more than 1 email address then 828 BIMI processing MUST NOT be performed for this message. 830 2. Start with the DNS domain found in the RFC5322.From header in the 831 message. Define this DNS domain as the Author Domain. 833 3. Find the Organizational Domain for the Author Domain. Define 834 this DNS domain as the Author Organizational Domain. If the 835 Author Domain is an Organizational Domain then this will be 836 identical to the Author Domain. 838 4. Evaluate the DMARC [RFC7489] result for the Author Domain. 839 Define the result as the BIMI DMARC Result. 841 5. If the BIMI DMARC result is not 'pass', then the receiver MAY 842 choose to apply additional authentication methods, for example by 843 evaluating a trusted ARC [RFC8617] chain, a list of trusted 844 forwarders, or by applying a local policy. In this case the 845 Receiver MAY choose to treat the message as if the BIMI DMARC 846 Result was 'pass'. 848 6. If the DMARC [RFC7489] result for the Author Domain is not 849 'pass', and the message could not be authenticated by any 850 additional authentication method, then BIMI processing MUST NOT 851 be performed for this message. 853 7. If the DMARC [RFC7489] policy for the Author Domain or Author 854 Organizational Domain is p=none then BIMI processing MUST NOT be 855 performed for this message. 857 8. If the DMARC [RFC7489] record for the Author Domain or Author 858 Organizational Domain includes a subdomain policy, and that 859 subdomain policy is sp=none then BIMI processing MUST NOT be 860 performed for this message. 862 9. If the DMARC [RFC7489] policy for the Author Domain or Author 863 Organizational Domain is p=quarantine, and the DMARC [RFC7489] 864 record defines a percentage tag, then that tag MUST be pct=100, 865 otherwise BIMI processing MUST NOT be performed for this message. 867 7.2. Assertion Record Discovery 869 Through the BIMI Assertion Record (#assertion-record-definition), 870 Domain Owners use DNS TXT records to advertise their preferences. 871 Preference discovery is accomplished via a method similar to the 872 method used for DMARC [RFC7489] records. This method, and the 873 important differences between BIMI and DMARC [RFC7489] mechanisms, 874 are discussed below. 876 Assertion Record Discovery MUST NOT be attempted if the message 877 authentication fails per Receiver policy. 879 To balance the conflicting requirements of supporting wildcarding, 880 allowing subdomain policy overrides, and limiting DNS query load, 881 Protocol Clients MUST employ the following lookup scheme for the 882 appropriate BIMI record for the message: 884 1. Start with the DNS domain found in the RFC5322.From header in the 885 message. Define this DNS domain as the Author Domain. 887 2. If the message for which the Indicator is being determined 888 specifies a selector value in the BIMI Selector Header (#bimi- 889 selector), use this value for the selector. Otherwise the value 890 'default' MUST be used for the selector. 892 3. Clients MUST query the DNS for a BIMI TXT record at the DNS 893 domain constructed by concatenating the selector, the string 894 '_bimi', and the Author Domain. A possibly empty set of records 895 is returned. 897 4. Records that do not start with a "v=" tag that identifies the 898 current version of BIMI MUST be discarded. 900 5. If the set is now empty, the Client MUST query the DNS for a BIMI 901 TXT record at the DNS domain constructed by concatenating the 902 selector, the string '_bimi', and the Organizational Domain (as 903 defined in DMARC [RFC7489]) corresponding to the Author Domain. 904 A custom selector that does not exist falls back to 905 ._bimi.. A possibly empty set of 906 records is returned. 908 6. Records that do not start with a "v=" tag that identifies the 909 current version of BIMI MUST be discarded. 911 7. If the remaining set contains multiple records or no records, 912 Assertion Record Discovery terminates and BIMI processing MUST 913 NOT be performed for this message. 915 8. If the remaining set contains only a single record, this record 916 is used for BIMI Assertion. 918 7.3. Indicator Discovery. 920 1. If the retrieved Assertion Record does not include a valid bimi- 921 location in the l= tag, then Indicator Discovery has failed, and 922 the Indicator MUST NOT be displayed. The bimi-location entry 923 MUST be a URI with a HTTPS transport. 925 2. If the retrieved Assertion Record includes a bimi-evidence- 926 location entry in the a= tag, and the receiver supports BIMI 927 Evidence Document validation, then proceed to the Indicator 928 Discovery With Evidence (#indicator-discovery-with-evidence) 929 step. 931 3. If the receiver does not support BIMI Evidence Document 932 validation, or the retrieved Assertion Record does not include a 933 bimi-evidence-location entry, then proceed to the Indicator 934 Discovery Without Evidence (#indicator-discovery-without- 935 evidence) step. 937 7.4. Indicator Discovery With Evidence. 939 Individual types of BIMI Evidence Document MAY specify extra 940 discovery and validation steps. These will be defined in separate 941 documents. 943 7.5. Indicator Discovery Without Evidence. 945 If an Assertion Record is found, and it has empty bimi-location and 946 bimi-evidence-location then this is a Declination to Publish record. 947 BIMI processing MUST not occur on this message and the MTA SHOULD 948 reflect this in the Authentication-Results header by adding a 949 bimi=declined entry. 951 If an Assertion Record is found, and has an empty or missing bimi- 952 evidence-location entry then no evidence has is presented, and the 953 Indicator MUST be retrieved from the URI specified in the bimi- 954 location entry using the following algorithm: 956 1. Retrieve the SVG Indicator from the URI specified in the l= tag. 957 This MUST be a URI with a HTTPS transport. 959 2. If the TLS server identity certificate presented during the TLS 960 session setup does not chain-up to a root certificate the Client 961 trusts then Indicator validation has failed and the Indicator 962 MUST NOT be displayed. 964 3. Proceed to the Indicator Validation (#indicator-validation) step. 966 7.6. Indicator Validation 968 1. Check the file size of the retrieved Indicator against 969 recommended maximum sizes as defined in this document, and in the 970 BIMI SVG document. A receiver MAY choose to implement their own 971 file size restrictions. If the Indicator is larger than the 972 maximum size the the receiver MAY choose not to display the 973 Indicator. A receiver MAY choose to implement the size limit as 974 a retrieval limit rather than retrieving the entire document and 975 then checking the size. 977 2. If the SVG Indicator is missing, or is not a valid SVG or SVGZ 978 document then validation has failed and the Indicator MUST NOT be 979 displayed. 981 3. Check the retrieved Indicator against the SVG validation steps 982 specified in this document, and in the BIMI SVG document. 984 4. If Indicator verification has passed, and the Indicator is from a 985 trusted source, then the Indicator MAY be displayed per receiver 986 policy. 988 7.7. Affix BIMI Status to Authentication Results Header Field 990 Upon completion of Assertion Record Discovery, Indicator Discovery, 991 and Indicator Validation, an MTA SHOULD affix the result in the 992 Authentication-Results header using the following syntax, with the 993 following key=value pairs: 995 bimi: Result of the bimi lookup (plain-text; REQUIRED). Range of 996 values are 'pass' (BIMI successfully validated), 'none' (no BIMI 997 record present), 'fail' (syntax error in the BIMI record, failure in 998 Discovery or Validation steps, or some other error), 'temperror' (DNS 999 lookup problem), 'declined' (The domain owner published an explicit 1000 declination record), or 'skipped' (BIMI check was not performed, 1001 possibly because the message did not comply with the minimum 1002 requirements such as passing DMARC, or the MTA does not trust the 1003 sending domain). The MTA MAY put comments in parentheses after bimi 1004 result, e.g., "bimi=fail (Invalid SVG)", "bimi=skipped (sender not 1005 trusted)" or "bimi=skipped (message failed DMARC)". 1007 header.d: Domain of the BIMI Assertion Record which was evaluated 1008 (plain-text; REQUIRED if bimi=pass). For example, this will be the 1009 organizational domain if the BIMI lookup used the fallback record, 1010 otherwise it will be the RFC5322.From domain. 1012 header.selector: Selector of the BIMI Assertion Record which was 1013 evaluated (plain-text; REQUIRED if bimi=pass). For example, if a 1014 BIMI-Selector Header was present and used to discover a BIMI 1015 Assertion Record then this will be the Selector used, otherwise this 1016 will be 'default'. 1018 policy.authority: Authority verification status of the Brand 1019 Identifier (plain-text; REQUIRED if the BIMI Evidence Document was 1020 checked). If the Authority Evidence presented in the BIMI Assertion 1021 Record was checked and found to be valid then this MUST be set to 1022 pass. If the validation failed then this MUST be set to fail. If no 1023 Authority Evidence was presented, or the MTA did not check the 1024 Authority Evidence then this SHOULD be set to none. 1026 policy.authority-uri: The URI of the BIMI Evidence Document checked, 1027 as found in the a= tag of the BIMI Assertion Record (plain-text; 1028 OPTIONAL). 1030 7.8. Handle Existing BIMI-Location and BIMI-Indicator Headers 1032 Regardless of success of the BIMI lookup, if a BIMI-Location or a 1033 BIMI-Indicator header is already present in a message it MUST be 1034 either removed or renamed. This is because the MTA performing BIMI- 1035 related processing immediately prior to a Mail Delivery Agent (or 1036 within the same administrative realm) is the only entity allowed to 1037 specify the BIMI-Location or BIMI-Indicator headers (e.g. not the 1038 sending MTA, and not an intermediate MTA). Allowing one or more 1039 existing headers through to a MUA is a security risk. 1041 If the original email message had a DKIM signature, it has already 1042 been evaluated. Removing the BIMI-Location header at this point 1043 should not invalidate the signature since it should not be included 1044 within it per this spec. 1046 7.9. Construct BIMI-Location URI 1048 This header MUST NOT be added if Discovery or Validation steps 1049 failed. 1051 The URI used to retrieve the validated SVG Indicator. If the 1052 receiver extracted the Indicator from the BIMI Evidence Document then 1053 this SHOULD be the bimi-evidence-location added with a a= tag, 1054 otherwise it SHOULD be the bimi-location added with a l= tag. If 1055 both a= and l= tags are included then the MTA MUST perform checks to 1056 ensure that the SVG Indicator referenced by the bimi-location is 1057 identical to the SVG Indicator extracted from the BIMI Evidence 1058 Document. 1060 7.10. Construct BIMI-Indicator header 1062 This header MUST NOT be added if Discovery or Validation steps 1063 failed. 1065 Encode the SVG Indicator retrieved and validated during the Indicator 1066 Discovery and Indicator Validation steps as base64 encoded data. If 1067 the Indicator was compressed with gzip when retrieved then the data 1068 MUST be uncompressed before being base64 encoded. 1070 The MTA MUST fold the header to be within the line length limits of 1071 SMTP [RFC5321]. 1073 8. Security Considerations 1075 The consistent use of Brand Indicators is valuable for Domain Owners, 1076 Mail Receivers, and End Users. However, the routine display of brand 1077 Indicators represents an attractive target for abuse, especially for 1078 determined malicious actors. Great care is warranted. The 1079 discussion following as an incomplete list of considerations. 1081 8.1. Indirect Mail Flows 1083 If a mail store ingests a message from another mail store through 1084 some other means, the message may or may not have BIMI headers added 1085 already. If the receiving store trusts the other mail store, it may 1086 simply use existing headers. Or, it may re-evaluate BIMI policy and 1087 requirements, and create or replace the BIMI-Location header. 1089 8.2. Lookalike Domains and Copycat Indicators 1091 Publishing BIMI records is not sufficient for an MTA to signal to the 1092 MUA to load the BIMI Indicator. For example, the Domain Owner may 1093 also need to have a sufficiently strong reputation with the MTA. The 1094 receiver may use a manually maintained list of large brands, it may 1095 import a list from a third party of acceptable domains, or it may 1096 apply its own reputation heuristics before deciding whether or not to 1097 load the BIMI Indicator. BIMI does not specify what MTAs may bring 1098 to bear as additional factors. 1100 8.3. Large files and buffer overflows 1102 The MTA or MUA should perform some basic analysis and avoid loading 1103 Indicators that are too large or too small. The Receiver may choose 1104 to maintain a manual list and do the inspection of its list offline 1105 so it doesn't have to do it at time-of-scan. 1107 8.4. Slow DNS queries 1109 All email Receivers already have to query for DNS records, and all of 1110 them have built-in timeouts when performing DNS queries. 1111 Furthermore, the use of caching when loading Indicators can help cut 1112 down on load time. Virtually all email clients have some sort of 1113 image-downloading built-in and make decisions when to load or not 1114 load Indicators. 1116 8.5. Unaligned Indicators and asserting domains 1118 There is no guarantee that a group responsible for managing Brand 1119 Indicators will have access to put these Indicators directly in any 1120 specific location of a domain, and requiring that Indicators live on 1121 the asserted domain is too high a bar. Additionally, letting a brand 1122 have Indicator locations outside its domain may be desirable so that 1123 someone sending legitimate authenticated email on the Domain Owner's 1124 behalf can manage and set selectors as an authorized third party 1125 without requiring access to the Domain Owner's DNS or web services. 1127 8.6. Unsigned BIMI-Selector Header 1129 If a Domain Owner relies on SPF but not DKIM for email 1130 authentication, then adding a requirement of DKIM may create too high 1131 of a bar for that sender. On the other hand, Receivers doing BIMI 1132 assertion may factor in the lack of DKIM signing when deciding 1133 whether to add a BIMI-Location header. 1135 8.7. CGI scripts in Indicator payload 1137 MTAs and MVAs should aggressively police Indicators to ensure they 1138 are the Indicators they claim to be, are within appropriate size 1139 limits, and pass other sanity checks. Additionally, MTAs might cache 1140 good Indicators and serve them directly to their MUAs, which would in 1141 practice bypass any malicious dynamic payload set to trigger against 1142 an end user but not an MTA. 1144 8.8. Metadata in Indicators 1146 Domain Owners should be careful to strip any metadata out of 1147 published Indicators that they don't want to expose or which might 1148 bloat file size. MTAs and MVAs might wish to inspect and remove such 1149 data from Indicators before exposing them to end users. 1151 9. IANA Considerations 1153 IANA will need to reserve three new entries for the "Permanent 1154 Message Header Field Names" registry and create a registry for 1155 support file formats for BIMI. 1157 9.1. Permanent Header Field Updates 1159 Header field name: BIMI-Selector 1161 Applicable protocol: mail 1163 Status: standard 1164 Author/Change controller: IETF 1166 Specification document: This one 1168 Header field name: BIMI-Location 1170 Applicable protocol: mail 1172 Status: standard 1174 Author/Change controller: IETF 1176 Specification document: This one 1178 Header field name: BIMI-Indicator 1180 Applicable protocol: mail 1182 Status: standard 1184 Author/Change controller: IETF 1186 Specification document: This one 1188 9.2. Registry for Supported BIMI Formats 1190 Names of support file types supported by BIMI must be registered by 1191 IANA. 1193 New entries are assigned only for values that have been documented in 1194 a published RFC that has had IETF Review, per [IANA-CONSIDERATIONS]. 1195 Each method must register a name, the file extension, the 1196 specification that defines it, and a description. 1198 9.3. Other IANA needs 1200 10. Normative References 1202 [RFC1035] Mockapetris, P., "Domain names - implementation and 1203 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1204 November 1987, . 1206 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1207 Requirement Levels", BCP 14, RFC 2119, 1208 DOI 10.17487/RFC2119, March 1997, 1209 . 1211 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1212 Specifications: ABNF", STD 68, RFC 5234, 1213 DOI 10.17487/RFC5234, January 2008, 1214 . 1216 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1217 DOI 10.17487/RFC5321, October 2008, 1218 . 1220 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1221 DOI 10.17487/RFC5598, July 2009, 1222 . 1224 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1225 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1226 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1227 . 1229 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1230 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1231 DOI 10.17487/RFC7208, April 2014, 1232 . 1234 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1235 Message Authentication, Reporting, and Conformance 1236 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1237 . 1239 [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. 1240 Kucherawy, Ed., "The Authenticated Received Chain (ARC) 1241 Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, 1242 . 1244 11. Informative References 1246 [BIMI-OVERVIEW] 1247 "An Overview of the Design of BIMI", 1248 . 1251 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1252 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1253 May 2017, . 1255 Appendix A. Example Selector Discovery (INFORMATIVE) 1257 This section shows several examples of how a receiving MTA should 1258 determine which Assertion Record to use depending on the BIMI- 1259 Selector header. 1261 A.1. No BIMI-Selector Header 1263 The domain example.com does not send with a BIMI-Selector header. 1265 From: sender@example.com 1267 The MTA would lookup default._bimi.example.com for the BIMI DNS 1268 record. 1270 A.2. With BIMI-Selector Header 1272 The domain example.com sends with a BIMI-Selector header: 1274 From: sender@example.com 1275 BIMI-Selector: v=BIMI1; s=selector; 1277 The MTA would lookup selector._bimi.example.com. 1279 A.3. Without BIMI-Selector Header on a subdomain 1281 The domain foo.example.com sends without a BIMI-Selector header: 1283 From: sender@foo.example.com 1285 The MTA would lookup default._bimi.foo.example.com for the BIMI DNS 1286 record. If it did not exist, it would lookup 1287 default._bimi.example.com. 1289 A.4. With BIMI-Selector Header on a subdomain 1291 The domain foo.example.com sends without a BIMI-Selector header: 1293 From: sender@foo.example.com 1294 BIMI-Selector: v=BIMI1; s=myselector; 1296 The MTA would lookup myselector._bimi.foo.example.com for the BIMI 1297 DNS record. If it did not exist, it would fall back to the lookup 1298 myselector._bimi.example.com. 1300 A.5. Invalid BIMI-Selector Header 1302 The domain example.com sends with a BIMI-Selector header, but does 1303 not include the required field 'v=': 1305 From: sender@example.com 1306 BIMI-Selector: s=myselector; 1308 The MTA would ignore this header, and lookup 1309 default._bimi.example.com. 1311 Appendix B. Example Authentication-Results entry (INFORMATIONAL) 1313 This section shows example Authentication-Results stamps based on 1314 different BIMI lookup statuses. 1316 B.1. Successful BIMI lookup 1318 From: sender@example.com 1319 BIMI-Selector: v=BIMI1; s=myselector; 1320 Authentication-Results: bimi=pass header.d=example.com header.selector=myselector; 1322 B.2. No BIMI record 1324 From: sender@sub.example.com 1325 Authentication-Results: bimi=none; 1327 In this example, sub.example.com does not have a BIMI record at 1328 default._bimi.sub.example.com, nor does default._bimi.example.com 1330 B.3. Declination to Publish 1332 From: sender@example.com 1333 Authentication-Results: bimi=declined; 1335 In this example the record found at default._bimi.example.com was 1336 "v=BIMI1; l=; a=;", indicating a Declination to Publish a BIMI 1337 Assertion Record, and so indicating that BIMI processing should not 1338 occur on this message. 1340 B.4. Subdomain has no default record, but organizational domain does 1342 From: sender@sub.example.com 1343 Authentication-Results: bimi=pass header.d=example.com header.selector=default; 1345 B.5. Subdomain and orgznizational domain have no record for selector, 1346 but organization 1348 domain has a default 1350 From: sender@sub.example.com 1351 BIMI-Selector: v=BIMI1; s=myselector; 1352 Authentication-Results: bimi=none; 1354 In this example, the sender specified a DNS record at 1355 myselector._bimi.sub.example.com but it did not exist. The fallback 1356 is to use myselector._bimi.example.com, which also does not exist. 1357 The assertion record does exist for the default selector at the 1358 organizational domain default._bimi.example.com, however this is not 1359 used as the sender specified a selector of myselector. 1361 B.6. Subdomain has no record for selector, but organization domain does 1363 From: sender@sub.example.com 1364 BIMI-Selector: v=BIMI1; s=myselector; 1365 Authentication-Results: bimi=pass header.d=example.com header.selector=myselector; 1367 In this example, the sender specified a DNS record at 1368 myselector._bimi.sub.example.com but it did not exist. The fallback 1369 is to use myselector._bimi.example.com. 1371 Appendix C. Example BIMI Headers Construction (INFORMATIONAL) 1373 This section shows how an example MTA might evaluate an incoming 1374 email for BIMI participation, and how it could share that 1375 determination with its MUA(s). 1377 C.1. MTA Receives an email 1379 The MTA receives the following DKIM signed message: 1381 DKIM-Signature: v=1; s=myExample; d=example.com; h=From;BIMI-Selector;Date;bh=...;b=... 1382 From: sender@example.com 1383 BIMI-Selector: v=BIMI1; s=brand; 1384 BIMI-Location: image.example.com/bimi/logo/example-bimi.svg 1385 Subject: Hi, this is a message from the good folks at Example Learning 1387 C.2. MTA does its authentication checks 1389 The receiving MTA receives the message and performs an SPF 1390 verification (which fails), a DKIM verification (which passes), and a 1391 DMARC verification (which passes). The domain is verified and has 1392 good reputation. The Receiver proceeds to perform a BIMI lookup. 1394 C.3. MTA performs BIMI Assertion 1396 The MTA sees that the message has a BIMI-Selector header, and it is 1397 covered by the DKIM-Signature, and the DKIM-Signature that passed 1398 DKIM is the one that covers the BIMI-Selector header. The MTA sees 1399 the header validates and contains 'v=BIMI1', and 's=brand'. It 1400 performs a DNS query for brand._bimi.example.com and retrieves: 1402 brand._bimi.example.com IN TXT "v=BIMI1; l=https://image.example.com/bimi/logo/" 1404 The MTA verifies the syntax of the BIMI DNS record, and it, too 1405 passes. 1407 The MTA knows it has previously retrieved the Indicator referenced by 1408 the BIMI DNS record, and had already successfully checked this 1409 Indicator against the published SVG profile. The MTA retrieves the 1410 Indicator from the cache. 1412 C.4. MTA appends to Authentication-Results 1414 The MTA computes and affixes the results of the BIMI to the 1415 Authentication-Results header: 1417 Authentication-Results: spf=fail smtp.mailfrom=example.com; 1418 dkim=pass (signature was verified) header.d=example.com; 1419 dmarc=pass header.from=example.com; 1420 bimi=pass header.d=example.com header.selector=brand; 1422 C.5. MTA Constructs BIMI-Location and BIMI-Indicator headers 1424 The MTA base64 encodes the retrieved Indicator and constructs a new 1425 BIMI-Indicator header. 1427 The MTA constructs a BIMI-Location header with a version tag, and an 1428 l tag indicating the URL from which the Indicator was retrieved. 1430 Finally, the MTA removes any existing BIMI-Location and BIMI- 1431 Indicator headers, and stamps the new ones: 1433 BIMI-Location: v=BIMI1; l=https://image.example.com/bimi/logo/ 1435 BIMI-Indicator: PD94bW...8L3N2Zz4K 1437 That the original sender signed a BIMI-Location header against this 1438 spec is irrelevant. It was used for DKIM validation and then thrown 1439 out by the MTA. 1441 C.6. The MUA displays the Indicator 1443 The mail is opened from the mail store in an MUA. The MUA performs 1444 locally defined checks to make sure that it can trust the BIMI- 1445 Indicator header. Finally, the MUA extracts the Indicator from the 1446 BIMI-Indicator header and displays it to the user. 1448 Appendix D. Acknowledgements 1450 Many people have contributed to the development of BIMI. Along with 1451 thanks to members of the current AuthIndicators Working Group, the 1452 editors wish to acknowledge the efforts of Sri Somanchi, Don 1453 Cardinal, Steve Jones, and John Levine. 1455 Authors' Addresses 1457 Seth Blank 1458 Valimail 1460 Email: seth@valimail.com 1462 Peter Goldstein 1463 Valimail 1465 Email: peter@valimail.com 1467 Thede Loder 1468 Skye Logicworks LLC 1470 Email: thede@skyelogicworks.com 1472 Terry Zink 1474 Email: tzink@terryzink.com 1476 Marc Bradshaw 1477 Fastmail 1479 Email: marc@fastmailteam.com