idnits 2.17.00 (12 Aug 2021) /tmp/idnits53471/draft-brand-indicators-for-message-identification-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 10 instances of too long lines in the document, the longest one being 51 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 (11 October 2021) is 222 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 189, but not defined == Missing Reference: 'URI' is mentioned on line 556, but not defined == Missing Reference: 'SMTP' is mentioned on line 629, but not defined == Missing Reference: 'ARC' is mentioned on line 759, but not defined == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 1195, 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: 14 April 2022 T. Loder (ed) 6 Skye Logicworks LLC 7 T. Zink (ed) 9 M. Bradshaw (ed) 10 Fastmail 11 A. Brotman (ed) 12 Comcast 13 11 October 2021 15 Brand Indicators for Message Identification (BIMI) 16 draft-brand-indicators-for-message-identification-00 18 Abstract 20 Brand Indicators for Message Identification (BIMI) permits Domain 21 Owners to coordinate with Mail User Agents (MUAs) to display brand- 22 specific Indicators next to properly authenticated messages. There 23 are two aspects of BIMI coordination: a scalable mechanism for Domain 24 Owners to publish their desired Indicators, and a mechanism for Mail 25 Transfer Agents (MTAs) to verify the authenticity of the Indicator. 26 This document specifies how Domain Owners communicate their desired 27 Indicators through the BIMI Assertion Record in DNS and how that 28 record is to be interpreted by MTAs and MUAs. MUAs and mail- 29 receiving organizations are free to define their own policies for 30 making use of BIMI data and for Indicator display as they see fit. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 14 April 2022. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . 7 68 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 8 69 2.3. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 8 70 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 8 71 3.1. BIMI Assertion . . . . . . . . . . . . . . . . . . . . . 9 72 3.2. Indicator . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.3. Mark Verifying Authority (MVA) . . . . . . . . . . . . . 9 74 3.4. BIMI Evidence Document . . . . . . . . . . . . . . . . . 9 75 3.5. Verified Mark Certificate (VMC) . . . . . . . . . . . . . 9 76 3.6. Protocol Client . . . . . . . . . . . . . . . . . . . . . 10 77 3.7. Verifying Protocol Client . . . . . . . . . . . . . . . . 10 78 4. BIMI DNS Records . . . . . . . . . . . . . . . . . . . . . . 10 79 4.1. MUA Obligations . . . . . . . . . . . . . . . . . . . . . 11 80 4.2. Assertion Record Definition . . . . . . . . . . . . . . . 11 81 4.2.1. Declination to Publish . . . . . . . . . . . . . . . 13 82 4.2.2. Supported Image Formats for l= tag . . . . . . . . . 13 83 4.3. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 13 84 5. BIMI Header Fields . . . . . . . . . . . . . . . . . . . . . 14 85 5.1. BIMI-Selector Header . . . . . . . . . . . . . . . . . . 14 86 5.2. BIMI-Location Header . . . . . . . . . . . . . . . . . . 15 87 5.3. BIMI-Indicator Header . . . . . . . . . . . . . . . . . . 16 88 5.4. Header Signing . . . . . . . . . . . . . . . . . . . . . 16 89 6. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . 17 90 6.1. Determine and Publish Indicator(s) for Use . . . . . . . 17 91 6.2. Publish Assertion Records . . . . . . . . . . . . . . . . 17 92 6.3. Manage multiple uses of the same Indicator(s) within a 93 trust boundary . . . . . . . . . . . . . . . . . . . . . 17 94 6.4. Set the headers on outgoing email as appropriate . . . . 17 95 7. Receiver Actions . . . . . . . . . . . . . . . . . . . . . . 18 96 7.1. Authentication Requirements . . . . . . . . . . . . . . . 18 97 7.2. Assertion Record Discovery . . . . . . . . . . . . . . . 19 98 7.3. Indicator Discovery. . . . . . . . . . . . . . . . . . . 20 99 7.4. Indicator Discovery With Evidence. . . . . . . . . . . . 20 100 7.5. Indicator Discovery Without Evidence. . . . . . . . . . . 21 101 7.6. Indicator Validation . . . . . . . . . . . . . . . . . . 21 102 7.7. Affix BIMI Status to Authentication Results Header 103 Field . . . . . . . . . . . . . . . . . . . . . . . . . 22 104 7.8. Handle Existing BIMI-Location and BIMI-Indicator 105 Headers . . . . . . . . . . . . . . . . . . . . . . . . 23 106 7.9. Construct BIMI-Location URI . . . . . . . . . . . . . . . 23 107 7.10. Construct BIMI-Indicator header . . . . . . . . . . . . . 23 108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 109 8.1. Indirect Mail Flows . . . . . . . . . . . . . . . . . . . 24 110 8.2. Lookalike Domains and Copycat Indicators . . . . . . . . 24 111 8.3. Large files and buffer overflows . . . . . . . . . . . . 24 112 8.4. Slow DNS queries . . . . . . . . . . . . . . . . . . . . 24 113 8.5. Unaligned Indicators and asserting domains . . . . . . . 25 114 8.6. Unsigned BIMI-Selector Header . . . . . . . . . . . . . . 25 115 8.7. CGI scripts in Indicator payload . . . . . . . . . . . . 25 116 8.8. Metadata in Indicators . . . . . . . . . . . . . . . . . 25 117 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 118 9.1. Permanent Header Field Updates . . . . . . . . . . . . . 25 119 9.2. Registry for Supported BIMI Formats . . . . . . . . . . . 26 120 9.3. Other IANA needs . . . . . . . . . . . . . . . . . . . . 26 121 10. Normative References . . . . . . . . . . . . . . . . . . . . 26 122 11. Informative References . . . . . . . . . . . . . . . . . . . 27 123 Appendix A. Example Selector Discovery (INFORMATIVE) . . . . . . 28 124 A.1. No BIMI-Selector Header . . . . . . . . . . . . . . . . . 28 125 A.2. With BIMI-Selector Header . . . . . . . . . . . . . . . . 28 126 A.3. Without BIMI-Selector Header on a subdomain . . . . . . . 28 127 A.4. With BIMI-Selector Header on a subdomain . . . . . . . . 28 128 A.5. Invalid BIMI-Selector Header . . . . . . . . . . . . . . 29 129 Appendix B. Example Authentication-Results entry 130 (INFORMATIONAL) . . . . . . . . . . . . . . . . . . . . . 29 131 B.1. Successful BIMI lookup . . . . . . . . . . . . . . . . . 29 132 B.2. No BIMI record . . . . . . . . . . . . . . . . . . . . . 29 133 B.3. Declination to Publish . . . . . . . . . . . . . . . . . 29 134 B.4. Subdomain has no default record, but organizational domain 135 does . . . . . . . . . . . . . . . . . . . . . . . . . . 29 136 B.5. Subdomain and orgznizational domain have no record for 137 selector, but organization . . . . . . . . . . . . . . . 30 138 B.6. Subdomain has no record for selector, but organization 139 domain does . . . . . . . . . . . . . . . . . . . . . . . 30 140 Appendix C. Example BIMI Headers Construction (INFORMATIONAL) . 30 141 C.1. MTA Receives an email . . . . . . . . . . . . . . . . . . 30 142 C.2. MTA does its authentication checks . . . . . . . . . . . 30 143 C.3. MTA performs BIMI Assertion . . . . . . . . . . . . . . . 31 144 C.4. MTA appends to Authentication-Results . . . . . . . . . . 31 145 C.5. MTA Constructs BIMI-Location and BIMI-Indicator 146 headers . . . . . . . . . . . . . . . . . . . . . . . . . 31 147 C.6. The MUA displays the Indicator . . . . . . . . . . . . . 32 148 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 32 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 151 1. Introduction 153 RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING: 154 The source for this draft is maintained in GitHub at: 155 https://github.com/BLAHBLAHBLAH (https://github.com/BLAHBLAHBLAH) 157 This document defines Brand Indicators for Message Identification 158 (BIMI), which enables Domain Owners to coordinate with Mail Box 159 Providers (MBPs), Mail Transfer Agents (MTAs), and Mail User Agents 160 (MUAs) in the display of brand-specific Indicators next to properly 161 authenticated messages. 163 BIMI is designed to be open and to work at Internet scale. BIMI is 164 intended to drive adoption of email authentication best practices by 165 leveraging existing DMARC [RFC7489] policies, the supporting 166 authentication methods DKIM [RFC6376] and SPF [RFC7208], and other 167 associated standards such as ARC [RFC8617]. 169 The approach taken by BIMI is heavily influenced by the approach 170 taken in DKIM [RFC6376], in that BIMI: 172 * has no dependency on the deployment of any new Internet protocols 173 or services for indicator registration or revocation; 175 * makes no attempt to include encryption as part of the mechanism; 177 * is compatible with the existing email infrastructure and 178 transparent to the fullest extent possible; 180 * requires minimal new infrastructure; 182 * can be implemented independently of clients in order to reduce 183 deployment time; 185 * can be deployed incrementally; and 187 * allows delegation of indicator hosting to third parties. 189 To participate in BIMI, Domain Owners MUST have a strong [DMARC] 190 policy (quarantine or reject) on both the Organizational Domain, and 191 the RFC5322.From Domain of the message. Quarantine policies MUST NOT 192 have a pct less than pct=100. 194 This document defines how Domain Owners specify their desired 195 indicators through the BIMI Assertion Record in DNS and how that 196 record is to be interpreted by MTAs and MUAs. This document does not 197 cover how domains or indicators are verified, how MUAs should display 198 the indicators, or how other protocols (i.e. IMAP, JMAP) can be 199 extended to work with BIMI. Other documents may cover these topics. 200 MUAs and Mail Box Providers (MBPs) are free to define their own 201 policies for making use of BIMI data and for indicator display as 202 they see fit. 204 2. Overview 206 The Sender Policy Framework (SPF [RFC7208]), DomainKeys Identified 207 Mail (DKIM [RFC6376]), "Domain-based Message Authentication, 208 Reporting, and Conformance" (DMARC [RFC7489]), and Authenticated 209 Received Chain (ARC [RFC8617]) provide mechanisms for domain-level 210 authentication of email messages. They enable cooperating email 211 senders and receivers to distinguish messages that are authorized to 212 use the domain name from those that are not. BIMI relies on these 213 authentication protocols, but is not a new authentication protocol 214 itself. 216 MUAs are increasingly incorporating graphical Indicators to indicate 217 the identity of the sender of a message. While a discussion of the 218 merits of doing this is beyond the scope of this document, at present 219 there are no open standards for publishing and aiding discovery of 220 preferred Indicators or for tying display of them to authentic 221 messages only. 223 Because of the desire to have brand-specific Indicators available, 224 some mail-receiving organizations have developed closed systems for 225 obtaining and displaying Brand Indicators for select domains. While 226 this has enabled these mail-receiving organizations to display brand 227 Indicators for a limited subset of messages, this closed approach has 228 a number of downsides: 230 1. It puts a significant burden on each mail-receiving organization, 231 because they must identify and manage a large database of Brand 232 Indicators. 234 2. Scalability is challenging for closed systems that attempt to 235 capture and maintain complete sets of data across the whole of 236 the Internet. 238 3. A lack of uniformity across different mail-receiving 239 organizations - each organization will have its own Indicator 240 set, which may or may not agree with those maintained by other 241 organizations for any given domain. 243 4. Domain Owners have limited ability to influence the Brand 244 Indicator for the domain(s) they own, and any ability they do 245 have is likely to be dependent upon direct coordination with each 246 of many mail-receiving organizations. 248 5. Many Domain Owners have no ability to participate whatsoever as 249 they do not have the appropriate relationships to coordinate with 250 mail-receiving organizations. 252 6. MUAs that are not associated with a particular mail-receiving 253 organization are likely to be disadvantaged, because they are 254 unlikely to receive Indicators in a standardized manner or 255 optimized for their user interfaces. 257 This shows the need for a standardized mechanism by which Domain 258 Owners interested in ensuring that their Indicators are displayed 259 correctly and appropriately can publish and distribute Brand 260 Indicators for use by any participating MUA. 262 BIMI removes the substantial burden of curating and maintaining an 263 Indicator database from MUAs and MBPs, and allows each domain owner 264 to manage their own Indicators. As an additional benefit, mail- 265 originating organizations are incentivized to authenticate their 266 email as doing so will enable them to influence how email and 267 Indicators from the organization are displayed. 269 The structure of BIMI is as follows: 271 1. Domain Owners: 273 * Fully implement the DMARC [RFC7489] mechanism, to include: 275 - Creating and publishing in DNS [RFC1035] a DMARC [RFC7489] 276 policy record that meets the following criteria: 278 o The policy record MUST express either a Requested Mail 279 Receiver policy of "quarantine" with an effective 280 percentage of 100%, or a Requested Mail Receiver policy 281 of "reject" (with any percentage value). 283 o If a subdomain policy is published it MUST NOT be "none" 285 o Be published for the Organizational Domain, and any 286 subdomains thereof 288 - Deploying authentication technologies to ensure Identifier 289 Alignment 291 * Publish their preferred Brand Indicators via the DNS 292 [RFC1035]. 294 2. Senders: Ensure mail is properly authenticated, and has a 295 sufficiently strict DMARC [RFC7489] policy. 297 3. MTAs and MBPs: 299 * Confirm authenticity of the message using DMARC [RFC7489] and 300 whatever other authentication mechanisms they wish to apply. 302 * Check for a corresponding BIMI record, obtaining references to 303 the indicator media and optional substantiation of indicator 304 ownership rights 306 * If both the message is authentic and the logo is deemed 307 acceptable, the receiver adds a header to the message which 308 can be used by the MUA to obtain the Domain Owner's preferred 309 brand indicator. 311 4. MUA: retrieves and displays the brand indicator as appropriate 312 based on its policy and user interface. 314 The purpose of this structure is to reduce operational complexity at 315 each step. It is also to consolidate validation and Indicator 316 selection operations into the MTA, so that Domain Owners need only 317 publish a few simple records and MUAs only need simple display logic. 319 It is expected that MBPs implementing BIMI will do so in both their 320 MTAs and MUAs. 322 #Requirements {#requirements} 324 Specification of BIMI in this document is guided by the following 325 high-level goals, security dependencies, detailed requirements, and 326 items that are documented as out of scope. 328 An overview of the security challenges and design decisions is 329 documented at [BIMI-OVERVIEW]. 331 2.1. High-Level Goals 333 BIMI has the following high-level goals: 335 * Allow Domain Owners to suggest appropriate Indicators for display 336 with authenticated messages originating from their domains. 338 * Enable the authors of MUAs to display meaningful Indicators 339 associated with the Domain Owner to recipients of authenticated 340 email. 342 * Provide mechanisms to prevent attempts by malicious Domain Owners 343 to fraudulently represent messages from their domains as 344 originating with other entities. 346 * Work at Internet Scale. 348 * Encourage the adoption of Email Authentication Best Practices. 350 2.2. Security 352 Brand Indicators are a potential vector for abuse. BIMI creates a 353 relationship between sending organization and Mail Receiver so that 354 the receiver can display appropriately designated Indicators if the 355 sending domain is verified and has meaningful reputation with the 356 receiver. Without verification and reputation, there is no way to 357 prevent a bad actor exxample.com from using example.com's Brand 358 Indicators and behaving maliciously. This document does not cover 359 the different verification and reputation mechanisms available, but 360 BIMI relies upon them to be in deployed in order to control abuse. 362 2.3. Out of Scope 364 Several topics and issues are specifically out of scope for the 365 initial version of this work. These include the following: 367 * Publishing policy other than via the DNS. 369 * Specific requirements for Indicator display on MUAs. 371 * The explicit mechanisms used by Verifying Protocol Clients - this 372 will be deferred to a later document. 374 3. Terminology and Definitions 376 This section defines terms used in the rest of the document. 378 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 379 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 380 document are to be interpreted as described in BCP 14 381 (https://tools.ietf.org/html/bcp14) [RFC2119] [RFC8174] when, and 382 only when, they appear in all capitals, as shown here. 384 Readers are encouraged to be familiar with the contents of [RFC5598]. 385 In particular, that document defines various roles in the messaging 386 infrastructure that can appear the same or separate in various 387 contexts. For example, a Domain Owner could, via the messaging 388 mechanisms on which BIMI is based, delegate reponsibility for 389 providing preferred brand indicators to a third party with another 390 role. This document does not address the distinctions among such 391 roles; the reader is encouraged to become familiar with that material 392 before continuing. 394 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 396 "Author Domain", "Domain Owner", "Organizational Domain", and "Mail 397 Receiver" are imported from DMARC [RFC7489] Section 3. 399 3.1. BIMI Assertion 401 The mechanism through which a Protocol Client verifies the BIMI 402 Assertion Record and constructs the URI(s) to the requested 403 Indicator(s) to be placed in the BIMI-Location header. 405 3.2. Indicator 407 The icon, logo, image, mark, or other graphical representation of the 408 brand. The Indicator is defined in a common image format with 409 restrictions detailed in the Assertion Record Definition (#assertion- 410 record-definition). 412 3.3. Mark Verifying Authority (MVA) 414 An entity or organization that can provide evidence of verification 415 of Indicators asserted by a Domain Owner to Verifying Protocol 416 Clients. The MVA may choose to uphold and confirm the meeting of 417 certain Indicator standards (ie. size, trademark, content, etc). 419 3.4. BIMI Evidence Document 421 A document published by a Mark Verifying Authority to assert evicence 422 of verification. These are defined in a separate document. 424 3.5. Verified Mark Certificate (VMC) 426 A certificate issued by a Certificate Authority in accordance with 427 the Verified Mark Certificate Guidelines. These guidelines are 428 defined in a separate document. 430 A Verified Mark Certificate is one example of a BIMI Evidence 431 Document. 433 3.6. Protocol Client 435 An entity designed to obtain and correctly interpret the records 436 defined in this specification for the purpose of discovering and 437 fetching published Indicators. 439 3.7. Verifying Protocol Client 441 A Protocol Client that uses optional capabilities to obtain and 442 evaluate evidence concerning the Domain Owner's rights to use the 443 published Indicators. 445 4. BIMI DNS Records 447 Domain owners publish BIMI policies by adding BIMI Assertion Records 448 in the DNS as TXT records. 450 Published policies are interpreted and applied by Protocol Clients. 451 A Domain Owner signals intended BIMI participation for one or more of 452 its domains by publishing an Assertion Record in a subdomain under 453 it. In doing so, Domain Owners make specific requests of MUAs 454 regarding the preferred set of Indicators to be displayed with 455 messages that are confirmed to be authorized to appear from the 456 Domain Owner's domain. 458 The use of BIMI is opt-in. Receivers default to performing no BIMI- 459 specific message handling until they choose to do so, and then only 460 if a BIMI record for the sender's domain is found. 462 BIMI's use of the DNS is driven in part by BIMI's use of domain names 463 as the basis of sender identity and message authentication. Use of 464 the DNS as the policy publication service also has the benefit of 465 reusing an extremely well-established operations, administration, and 466 management infrastructure, rather than creating a new one. 468 BIMI's policy payload is intentionally only published via a DNS 469 record and not via one or more email headers. This serves three 470 purposes: 472 1. There is one and only one mechanism for both simple and complex 473 policies to be published. 475 2. Operational complexity is reduced. MTAs only need to check a 476 single record in a consistent manner to discover and enforce 477 policy. 479 3. Indicators SHOULD be verified and cached in advance, so that 480 malicious headers cannot be used as an attack vector. 482 Per DNS [RFC1035], a TXT record can comprise several "character- 483 string" objects. BIMI TXT records with multiple strings must be 484 treated in an identical manner to SPF Section 3.3 485 (https://tools.ietf.org/html/rfc7208#section-3.3). 487 4.1. MUA Obligations 489 MUAs implementing the BIMI mechanism SHOULD make a best-effort 490 attempt to adhere to the Domain Owner's published BIMI policy. 491 However, MUAs have final control over the user interface published to 492 their end users, and MAY use alternate Indicators than those 493 specified in the BIMI assertion record or no Indicator at all. 495 4.2. Assertion Record Definition 497 All Domain Owner BIMI preferences are expressed in DNS TXT records 498 published in subdomains named "_bimi". Multiple sets of preferences 499 can be associated with a single RFC5322.From domain. To distinguish 500 between these different preferences, BIMI defines and uses 501 [selectors]{#selectors}. Senders declare which selector to use for a 502 given message by specifying the selector in an optional BIMI-Selector 503 header (#bimi-selector). 505 For example, the Domain Owner of "example.com" would post BIMI policy 506 in a TXT record at "default._bimi.example.com". Similarly, a Mail 507 Receiver wishing to query for BIMI policy regarding mail with an 508 RFC5322.From Author Domain of "example.com" and a selector "default" 509 (the default) would query the TXT record located at the subdomain of 510 "default._bimi.example.com". The DNS-based BIMI policy record is 511 referred to as the "BIMI Assertion Record" or "Assertion Record". 513 BIMI Assertion Records follow the extensible "tag-value" syntax for 514 DNS-based key records as defined in DKIM [RFC6376]. 516 Assertion Records are defined precisely. Mail receivers MUST NOT 517 attempt to fix syntactical or capitalization errors. If a required 518 tag is missing, or its value not well-formed, it is an error. 520 This section creates a registry for known BIMI tags and registers the 521 initial set defined in this document. Only tags defined in this 522 document or in later extensions, and thus added to the registry, are 523 to be processed; unknown tags MUST be ignored. 525 The following tags are introduced as the initial valid BIMI tags: 527 v= Version (plain-text; REQUIRED). Identifies the record retrieved 528 as a BIMI record. It MUST have the value of "BIMI1" for 529 implementations compliant with this version of BIMI. The value of 530 this tag MUST match precisely; if it does not match or it is absent, 531 the entire retrieved record MUST be ignored. It MUST be the first 532 tag in the list. 534 ABNF: 536 bimi-version = %x76 *WSP "=" *WSP %x42.49.4d.49 1DIGIT 538 a= Authority Evidence Location (plain-text; URI; OPTIONAL). If 539 present, this tag MUST have an empty value or its value MUST be a 540 single URI. An empty value for the tag is interpreted to mean the 541 Domain Owner does not wish to publish or does not have authority 542 evidence to disclose. The URI, if present, MUST contain a fully 543 qualified domain name (FQDN) and MUST specify HTTPS as the URI scheme 544 ("https"). The URI SHOULD specify the location of a publicly 545 retrievable BIMI Evidence Document. The format for evidence 546 documents is defined in a separate document. 548 If the a= tag is not present, it is assumed to have an empty value. 550 ABNF: 552 bimi-evidence-location = %x61 *WSP "=" bimi-uri 554 bimi-uri = \[FWS\] URI \[FWS\] 556 ; "URI" is imported from [URI] 557 ; HTTPS only 558 ; commas within a URI (ASCII ; 0x2C) MUST be encoded 560 l= location (URI; REQUIRED). The value of this tag is either empty 561 indicating declination to publish, or a single URI representing the 562 location of a Brand Indicator file. The only supported transport is 563 HTTPS. 565 ABNF: 567 bimi-location = %x6c *WSP "=" bimi-uri 569 Therefore, the formal definition of the BIMI Assertion Record, using 570 ABNF [RFC5234], is as follows: 572 bimi-sep = *WSP %x3b *WSP 574 bimi-record = bimi-version (bimi-sep bimi-location) (bimi-sep bimi-evidence-location) \[bimi-sep\] 576 ; components other than bimi-version may appear in any order 577 4.2.1. Declination to Publish 579 If both the "l=" and "a=" tags are empty, it is an explicit refusal 580 to participate in BIMI. This is distinct from not publishing a BIMI 581 record. For example, an empty BIMI record enables a Domain Owner to 582 decline BIMI participation for a subdomain when its organizational 583 domain has default Indicators available. Furthermore, messages sent 584 using a selector that has declined to publish will not show an 585 Indicator while messages with other selectors would display normally. 587 An explicit declination to publish looks like: 589 v=BIMI1; l=; a=; 591 4.2.2. Supported Image Formats for l= tag 593 Any format in the BIMI-formats IANA registry are acceptable targets 594 for the l= tag. If an l= tag URI ends with any other image format 595 suffix, or if the document retrievable from the location(s) in the l= 596 tag are of any other format, the evaluation of the record MUST be 597 treated as a permanent error. 599 As of the publishing of this document, only SVG and SVGZ, as defined 600 in RFC6170 section 5.2 (https://tools.ietf.org/html/rfc6170#section- 601 5.2) is acceptable in the l= tag. Further restrictions apply to the 602 SVG; these are documented elsewhere. 604 4.3. Selectors 606 To support publishing and display of more than one distinct Brand 607 Indicator per domain, the brand Indicator namespace is subdivided for 608 publishing of multiple Assertion Records using "selectors". 609 Selectors allow the Domain Owner to choose the brand Indicator, for 610 example, by type of recipient, by message source, or by other 611 considerations like seasonal branding. BIMI selectors are modeled 612 after DKIM selectors (https://tools.ietf.org/html/rfc6376#section- 613 3.1). 615 The selector "default" is the default Assertion Record. Domain 616 Owners can specify which other selector to use on a per-message basis 617 by utilizing the BIMI-Selector Header (#bimi-selector). 619 Periods are allowed in selectors and are component separators. When 620 BIMI Assertion Records are retrieved from the DNS, periods in 621 selectors define DNS label boundaries in a manner similar to the 622 conventional use in domain names. In a DNS implementation, this can 623 be used to allow delegation of a portion of the selector namespace. 625 ABNF: 627 selector = sub-domain *( "." sub-domain ) 629 ; from [SMTP] Domain, 631 ; excluding address-literal 633 The number of selectors for each domain is determined by the Domain 634 Owner. Many Domain Owners will be satisfied with just one selector, 635 whereas organizations with more complex branding requirements can 636 choose to manage disparate selectors. BIMI sets no maximum limit on 637 the number of selectors. 639 5. BIMI Header Fields 641 Once BIMI policies are published in DNS via Assertion Records, Domain 642 Owners can provide additional guidance to Mail Receivers, and Mail 643 Receivers to their MUAs through the use of BIMI header fields. 645 BIMI header fields are case insensitive. If a required tag is 646 missing, it is an error. 648 5.1. BIMI-Selector Header 650 BIMI DNS records are placed in ._bimi., and by 651 default they are placed in default._bimi.. That is, for 652 example.com, the default Assertion Record is located in the DNS at 653 default._bimi.example.com. However, a Domain Owner may override the 654 use of the default selector and specify the use of an alternative 655 using the RFC5322-compliant header 'BIMI-Selector'. The BIMI- 656 Selector header consists of key value pairs: 658 v= Version (plain-text; REQUIRED). The version of BIMI. It MUST 659 have the value of "BIMI1" for implementations compliant with this 660 version of BIMI. The value of this tag MUST match precisely; if it 661 does not or it is absent, the entire retrieved record MUST be 662 ignored. It MUST be the first tag in the list. 664 ABNF: 666 bimi-header-version = "v" *WSP "=" *WSP "BIMI" 1DIGIT 668 s= Selector (plain-text; REQUIRED). The location of the BIMI DNS 669 record, when combined with the RFC5322.From domain. 671 ABNF: 673 bimi-selector = "s" *WSP "=" *WSP selector 675 And the formal definition of the BIMI Selector Header, using ABNF, is 676 as follows: 678 bimi-selector-header = bimi-header-version bimi-sep bimi-selector \[bimi-sep\] 680 5.2. BIMI-Location Header 682 BIMI-Location is the header a Mail Receiver inserts that tells the 683 MUA where to get the BIMI Indicator from. 685 The syntax of the header is as follows: 687 v= Version (plain-text; REQUIRED). The version of BIMI. It MUST 688 have the value of "BIMI1" for implementations compliant with this 689 version of BIMI. The value of this tag MUST match precisely; if it 690 does not or it is absent, he entire header MUST be ignored. It MUST 691 be the first tag in the list. 693 The ABNF for bimi-header-version is imported exactly from the 694 [BIMI Selector Header](#bimi-selector). 696 l: location of the BIMI Indicator (URI; OPTIONAL if a bimi-evidence- 697 location-header-uri is specified, otherwise REQUIRED.). Inserted by 698 the MTA after performing the required checks and obtaining the 699 applicable domain's published Assertion Record. The value of this 700 tag is a URI representing the location of the Brand Indicator file. 701 HTTPS is the only supported transport. 703 ABNF: 705 bimi-location-header-uri = "l" *WSP "=" bimi-uri 707 a: location of the BIMI Evidence Document (URI; REQUIRED if the BIMI 708 Evidence Document was verified). Inserted by the MTA after 709 performing the required checks and obtaining the applicable domain's 710 published Assertion Record. The value of this tag is a URI 711 representing the location of the BIMI Evidence Document. HTTPS is 712 the only supported transport. 714 ABNF: 716 bimi-evidenced-location-header-uri = "a" *WSP "=" bimi-uri 717 And the formal definition of the BIMI Location Header, using ABNF, is 718 as follows: 720 bimi-location-header-location-only = bimi-location-header-uri 722 bimi-location-header-evidence-only = bimi-evidence-location-header-uri 724 bimi-location-header-both = bimi-location-header-uri bimi-evidence-location-header-uri 726 bimi-location-options = bimi-location-header-location-only / bimi-location-header-evidence-only / bimi-location-header-both 728 bimi-location-header = bimi-header-version bimi-sep bimi-location-options \[bimi-sep\] 730 5.3. BIMI-Indicator Header 732 BIMI-Indicator is the header a Mail Receiver inserts to pass a 733 verified Indicator to the MUA. 735 The header contains the SVG of the Indicator encoded as base64, and 736 is inserted by the MTA after performing the required checks and 737 obtaining the applicable domain's published Assertion Record. The 738 contents of this tag MUST match the SVG Indicator content retrieved 739 from the URI specified in the BIMI-Location header. If he Indicator 740 was supplied as a gzipped SVGZ file then the MTA MUST uncompress the 741 file before base64 encoding. 743 base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) 744 [ [FWS] "=" [ [FWS] "=" ] ] 746 And the formal definition of the BIMI Indicator Header, using ABNF, 747 is as follows: 749 bimi-indicator-header = bimi-sep base64string \[bimi-sep\] 751 5.4. Header Signing 753 If present, the BIMI-Selector header SHOULD be included in the DMARC- 754 aligned DKIM signature used to confirm authenticity of the message. 755 If it is not included in the DMARC-compliant DKIM signature, the 756 header SHOULD be ignored. 758 Receivers MAY choose to apply additional methods to validate the 759 BIMI-Selector header, for example by evaluating a trusted [ARC] 760 chain. In this case the Receiver MAY choose to treat the message as 761 if the BIMI-Selector header was signed. 763 The BIMI-Location and BIMI-Indicator headers MUST NOT be DKIM signed. 764 This header is untrusted by definition, and is only for use between 765 an MTA and its MUAs, after DKIM has been validated by the MTA. 766 Therefore, signing this header is meaningless, and any messages with 767 it signed are either coming from malicious or misconfigured third 768 parties. 770 6. Domain Owner Actions 772 This section includes a walk through of the actions a Domain Owner 773 takes when setting up Assertion Records and sending email messages. 775 6.1. Determine and Publish Indicator(s) for Use 777 Domain Owners should consider which Indicator file formats to choose 778 when setting up their BIMI Assertion Records. For a Sender, BIMI 779 provides control over which Indicators are eligible and can be chosen 780 for display, but not the ultimate manner in which the MUA will 781 display the Indicator. 783 6.2. Publish Assertion Records 785 For each set of Indicators and domains, publish the appropriate 786 Assertion Record as either "default" or a named selector as a DNS TXT 787 record within the appropriate "_bimi" namespace. 789 6.3. Manage multiple uses of the same Indicator(s) within a trust 790 boundary 792 For Domain Owners with multiple domains that wish to share the same 793 set of Indicators within a trust boundary and only manage those 794 Indicators from a single DNS location, it is RECOMMENDED to use DNS 795 CNAMEs. 797 Using a CNAME here is functionally similar to the SPF redirect 798 modifier. Since BIMI does not require l= tags to be aligned to the 799 Author Domain, CNAMEs present a cleaner solution than extending the 800 protocol. 802 6.4. Set the headers on outgoing email as appropriate 804 Once a default Assertion Record has been published for an Author 805 Domain, all emails from this domain should display the appropriate 806 Indicator in participating MUAs. 808 If a non-default Indicator is desired, the BIMI-Selector header 809 should be set appropriately. If for some reason this selector cannot 810 be accessed by the Protocol Client, the fallback is the default 811 Assertion Record on the Organization domain. 813 The BIMI-Location header MUST NOT be set by email senders, and 814 Protocol Clients MUST ignore it. 816 7. Receiver Actions 818 This section includes a walk through of the actions a Protocol Client 819 takes when evaluating an email message for BIMI Assertion. 821 7.1. Authentication Requirements 823 Before applying BIMI processing for a message, a receiver MUST verify 824 that the message passed the following BIMI authentication 825 requirements: 827 1. If more than 1 RFC5322.From header is present in the message, or 828 any RFC5322.From header contains more than 1 email address then 829 BIMI processing MUST NOT be performed for this message. 831 2. Start with the DNS domain found in the RFC5322.From header in the 832 message. Define this DNS domain as the Author Domain. 834 3. Find the Organizational Domain for the Author Domain. Define 835 this DNS domain as the Author Organizational Domain. If the 836 Author Domain is an Organizational Domain then this will be 837 identical to the Author Domain. 839 4. Evaluate the DMARC [RFC7489] result for the Author Domain. 840 Define the result as the BIMI DMARC Result. 842 5. If the BIMI DMARC result is not 'pass', then the receiver MAY 843 choose to apply additional authentication methods, for example by 844 evaluating a trusted ARC [RFC8617] chain, a list of trusted 845 forwarders, or by applying a local policy. In this case the 846 Receiver MAY choose to treat the message as if the BIMI DMARC 847 Result was 'pass'. 849 6. If the DMARC [RFC7489] result for the Author Domain is not 850 'pass', and the message could not be authenticated by any 851 additional authentication method, then BIMI processing MUST NOT 852 be performed for this message. 854 7. If the DMARC [RFC7489] policy for the Author Domain or Author 855 Organizational Domain is p=none then BIMI processing MUST NOT be 856 performed for this message. 858 8. If the DMARC [RFC7489] record for the Author Domain or Author 859 Organizational Domain includes a subdomain policy, and that 860 subdomain policy is sp=none then BIMI processing MUST NOT be 861 performed for this message. 863 9. If the DMARC [RFC7489] policy for the Author Domain or Author 864 Organizational Domain is p=quarantine, and the DMARC [RFC7489] 865 record defines a percentage tag, then that tag MUST be pct=100, 866 otherwise BIMI processing MUST NOT be performed for this message. 868 7.2. Assertion Record Discovery 870 Through the BIMI Assertion Record (#assertion-record-definition), 871 Domain Owners use DNS TXT records to advertise their preferences. 872 Preference discovery is accomplished via a method similar to the 873 method used for DMARC [RFC7489] records. This method, and the 874 important differences between BIMI and DMARC [RFC7489] mechanisms, 875 are discussed below. 877 Assertion Record Discovery MUST NOT be attempted if the message 878 authentication fails per Receiver policy. 880 To balance the conflicting requirements of supporting wildcarding, 881 allowing subdomain policy overrides, and limiting DNS query load, 882 Protocol Clients MUST employ the following lookup scheme for the 883 appropriate BIMI record for the message: 885 1. Start with the DNS domain found in the RFC5322.From header in the 886 message. Define this DNS domain as the Author Domain. 888 2. If the message for which the Indicator is being determined 889 specifies a selector value in the BIMI Selector Header (#bimi- 890 selector), use this value for the selector. Otherwise the value 891 'default' MUST be used for the selector. 893 3. Clients MUST query the DNS for a BIMI TXT record at the DNS 894 domain constructed by concatenating the selector, the string 895 '_bimi', and the Author Domain. A possibly empty set of records 896 is returned. 898 4. Records that do not start with a "v=" tag that identifies the 899 current version of BIMI MUST be discarded. 901 5. If the set is now empty, the Client MUST query the DNS for a BIMI 902 TXT record at the DNS domain constructed by concatenating the 903 selector, the string '_bimi', and the Organizational Domain (as 904 defined in DMARC [RFC7489]) corresponding to the Author Domain. 905 A custom selector that does not exist falls back to 906 ._bimi.. A possibly empty set of 907 records is returned. 909 6. Records that do not start with a "v=" tag that identifies the 910 current version of BIMI MUST be discarded. 912 7. If the remaining set contains multiple records or no records, 913 Assertion Record Discovery terminates and BIMI processing MUST 914 NOT be performed for this message. 916 8. If the remaining set contains only a single record, this record 917 is used for BIMI Assertion. 919 7.3. Indicator Discovery. 921 1. If the retrieved Assertion Record does not include a valid bimi- 922 location in the l= tag, then Indicator Discovery has failed, and 923 the Indicator MUST NOT be displayed. The bimi-location entry 924 MUST be a URI with a HTTPS transport. 926 2. If the retrieved Assertion Record includes a bimi-evidence- 927 location entry in the a= tag, and the receiver supports BIMI 928 Evidence Document validation, then proceed to the Indicator 929 Discovery With Evidence (#indicator-discovery-with-evidence) 930 step. 932 3. If the receiver does not support BIMI Evidence Document 933 validation, or the retrieved Assertion Record does not include a 934 bimi-evidence-location entry, then proceed to the Indicator 935 Discovery Without Evidence (#indicator-discovery-without- 936 evidence) step. 938 7.4. Indicator Discovery With Evidence. 940 Individual types of BIMI Evidence Document MAY specify extra 941 discovery and validation steps. These will be defined in separate 942 documents. 944 7.5. Indicator Discovery Without Evidence. 946 If an Assertion Record is found, and it has empty bimi-location and 947 bimi-evidence-location then this is a Declination to Publish record. 948 BIMI processing MUST not occur on this message and the MTA SHOULD 949 reflect this in the Authentication-Results header by adding a 950 bimi=declined entry. 952 If an Assertion Record is found, and has an empty or missing bimi- 953 evidence-location entry then no evidence has is presented, and the 954 Indicator MUST be retrieved from the URI specified in the bimi- 955 location entry using the following algorithm: 957 1. Retrieve the SVG Indicator from the URI specified in the l= tag. 958 This MUST be a URI with a HTTPS transport. 960 2. If the TLS server identity certificate presented during the TLS 961 session setup does not chain-up to a root certificate the Client 962 trusts then Indicator validation has failed and the Indicator 963 MUST NOT be displayed. 965 3. Proceed to the Indicator Validation (#indicator-validation) step. 967 7.6. Indicator Validation 969 1. Check the file size of the retrieved Indicator against 970 recommended maximum sizes as defined in this document, and in the 971 BIMI SVG document. A receiver MAY choose to implement their own 972 file size restrictions. If the Indicator is larger than the 973 maximum size the the receiver MAY choose not to display the 974 Indicator. A receiver MAY choose to implement the size limit as 975 a retrieval limit rather than retrieving the entire document and 976 then checking the size. 978 2. If the SVG Indicator is missing, or is not a valid SVG or SVGZ 979 document then validation has failed and the Indicator MUST NOT be 980 displayed. 982 3. Check the retrieved Indicator against the SVG validation steps 983 specified in this document, and in the BIMI SVG document. 985 4. If Indicator verification has passed, and the Indicator is from a 986 trusted source, then the Indicator MAY be displayed per receiver 987 policy. 989 7.7. Affix BIMI Status to Authentication Results Header Field 991 Upon completion of Assertion Record Discovery, Indicator Discovery, 992 and Indicator Validation, an MTA SHOULD affix the result in the 993 Authentication-Results header using the following syntax, with the 994 following key=value pairs: 996 bimi: Result of the bimi lookup (plain-text; REQUIRED). Range of 997 values are 'pass' (BIMI successfully validated), 'none' (no BIMI 998 record present), 'fail' (syntax error in the BIMI record, failure in 999 Discovery or Validation steps, or some other error), 'temperror' (DNS 1000 lookup problem), 'declined' (The domain owner published an explicit 1001 declination record), or 'skipped' (BIMI check was not performed, 1002 possibly because the message did not comply with the minimum 1003 requirements such as passing DMARC, or the MTA does not trust the 1004 sending domain). The MTA MAY put comments in parentheses after bimi 1005 result, e.g., "bimi=fail (Invalid SVG)", "bimi=skipped (sender not 1006 trusted)" or "bimi=skipped (message failed DMARC)". 1008 header.d: Domain of the BIMI Assertion Record which was evaluated 1009 (plain-text; REQUIRED if bimi=pass). For example, this will be the 1010 organizational domain if the BIMI lookup used the fallback record, 1011 otherwise it will be the RFC5322.From domain. 1013 header.selector: Selector of the BIMI Assertion Record which was 1014 evaluated (plain-text; REQUIRED if bimi=pass). For example, if a 1015 BIMI-Selector Header was present and used to discover a BIMI 1016 Assertion Record then this will be the Selector used, otherwise this 1017 will be 'default'. 1019 policy.authority: Authority verification status of the Brand 1020 Identifier (plain-text; REQUIRED if the BIMI Evidence Document was 1021 checked). If the Authority Evidence presented in the BIMI Assertion 1022 Record was checked and found to be valid then this MUST be set to 1023 pass. If the validation failed then this MUST be set to fail. If no 1024 Authority Evidence was presented, or the MTA did not check the 1025 Authority Evidence then this SHOULD be set to none. 1027 policy.authority-uri: The URI of the BIMI Evidence Document checked, 1028 as found in the a= tag of the BIMI Assertion Record (plain-text; 1029 OPTIONAL). 1031 7.8. Handle Existing BIMI-Location and BIMI-Indicator Headers 1033 Regardless of success of the BIMI lookup, if a BIMI-Location or a 1034 BIMI-Indicator header is already present in a message it MUST be 1035 either removed or renamed. This is because the MTA performing BIMI- 1036 related processing immediately prior to a Mail Delivery Agent (or 1037 within the same administrative realm) is the only entity allowed to 1038 specify the BIMI-Location or BIMI-Indicator headers (e.g. not the 1039 sending MTA, and not an intermediate MTA). Allowing one or more 1040 existing headers through to a MUA is a security risk. 1042 If the original email message had a DKIM signature, it has already 1043 been evaluated. Removing the BIMI-Location header at this point 1044 should not invalidate the signature since it should not be included 1045 within it per this spec. 1047 7.9. Construct BIMI-Location URI 1049 This header MUST NOT be added if Discovery or Validation steps 1050 failed. 1052 The URI used to retrieve the validated SVG Indicator. If the 1053 receiver extracted the Indicator from the BIMI Evidence Document then 1054 this SHOULD be the bimi-evidence-location added with a a= tag, 1055 otherwise it SHOULD be the bimi-location added with a l= tag. If 1056 both a= and l= tags are included then the MTA MUST perform checks to 1057 ensure that the SVG Indicator referenced by the bimi-location is 1058 identical to the SVG Indicator extracted from the BIMI Evidence 1059 Document. 1061 7.10. Construct BIMI-Indicator header 1063 This header MUST NOT be added if Discovery or Validation steps 1064 failed. 1066 Encode the SVG Indicator retrieved and validated during the Indicator 1067 Discovery and Indicator Validation steps as base64 encoded data. If 1068 the Indicator was compressed with gzip when retrieved then the data 1069 MUST be uncompressed before being base64 encoded. 1071 The MTA MUST fold the header to be within the line length limits of 1072 SMTP [RFC5321]. 1074 8. Security Considerations 1076 The consistent use of Brand Indicators is valuable for Domain Owners, 1077 Mail Receivers, and End Users. However, the routine display of brand 1078 Indicators represents an attractive target for abuse, especially for 1079 determined malicious actors. Great care is warranted. The 1080 discussion following as an incomplete list of considerations. 1082 8.1. Indirect Mail Flows 1084 If a mail store ingests a message from another mail store through 1085 some other means, the message may or may not have BIMI headers added 1086 already. If the receiving store trusts the other mail store, it may 1087 simply use existing headers. Or, it may re-evaluate BIMI policy and 1088 requirements, and create or replace the BIMI-Location header. 1090 8.2. Lookalike Domains and Copycat Indicators 1092 Publishing BIMI records is not sufficient for an MTA to signal to the 1093 MUA to load the BIMI Indicator. For example, the Domain Owner may 1094 also need to have a sufficiently strong reputation with the MTA. The 1095 receiver may use a manually maintained list of large brands, it may 1096 import a list from a third party of acceptable domains, or it may 1097 apply its own reputation heuristics before deciding whether or not to 1098 load the BIMI Indicator. BIMI does not specify what MTAs may bring 1099 to bear as additional factors. 1101 8.3. Large files and buffer overflows 1103 The MTA or MUA should perform some basic analysis and avoid loading 1104 Indicators that are too large or too small. The Receiver may choose 1105 to maintain a manual list and do the inspection of its list offline 1106 so it doesn't have to do it at time-of-scan. 1108 8.4. Slow DNS queries 1110 All email Receivers already have to query for DNS records, and all of 1111 them have built-in timeouts when performing DNS queries. 1112 Furthermore, the use of caching when loading Indicators can help cut 1113 down on load time. Virtually all email clients have some sort of 1114 image-downloading built-in and make decisions when to load or not 1115 load Indicators. 1117 8.5. Unaligned Indicators and asserting domains 1119 There is no guarantee that a group responsible for managing Brand 1120 Indicators will have access to put these Indicators directly in any 1121 specific location of a domain, and requiring that Indicators live on 1122 the asserted domain is too high a bar. Additionally, letting a brand 1123 have Indicator locations outside its domain may be desirable so that 1124 someone sending legitimate authenticated email on the Domain Owner's 1125 behalf can manage and set selectors as an authorized third party 1126 without requiring access to the Domain Owner's DNS or web services. 1128 8.6. Unsigned BIMI-Selector Header 1130 If a Domain Owner relies on SPF but not DKIM for email 1131 authentication, then adding a requirement of DKIM may create too high 1132 of a bar for that sender. On the other hand, Receivers doing BIMI 1133 assertion may factor in the lack of DKIM signing when deciding 1134 whether to add a BIMI-Location header. 1136 8.7. CGI scripts in Indicator payload 1138 MTAs and MVAs should aggressively police Indicators to ensure they 1139 are the Indicators they claim to be, are within appropriate size 1140 limits, and pass other sanity checks. Additionally, MTAs might cache 1141 good Indicators and serve them directly to their MUAs, which would in 1142 practice bypass any malicious dynamic payload set to trigger against 1143 an end user but not an MTA. 1145 8.8. Metadata in Indicators 1147 Domain Owners should be careful to strip any metadata out of 1148 published Indicators that they don't want to expose or which might 1149 bloat file size. MTAs and MVAs might wish to inspect and remove such 1150 data from Indicators before exposing them to end users. 1152 9. IANA Considerations 1154 IANA will need to reserve three new entries for the "Permanent 1155 Message Header Field Names" registry and create a registry for 1156 support file formats for BIMI. 1158 9.1. Permanent Header Field Updates 1160 Header field name: BIMI-Selector 1162 Applicable protocol: mail 1164 Status: standard 1165 Author/Change controller: IETF 1167 Specification document: This one 1169 Header field name: BIMI-Location 1171 Applicable protocol: mail 1173 Status: standard 1175 Author/Change controller: IETF 1177 Specification document: This one 1179 Header field name: BIMI-Indicator 1181 Applicable protocol: mail 1183 Status: standard 1185 Author/Change controller: IETF 1187 Specification document: This one 1189 9.2. Registry for Supported BIMI Formats 1191 Names of support file types supported by BIMI must be registered by 1192 IANA. 1194 New entries are assigned only for values that have been documented in 1195 a published RFC that has had IETF Review, per [IANA-CONSIDERATIONS]. 1196 Each method must register a name, the file extension, the 1197 specification that defines it, and a description. 1199 9.3. Other IANA needs 1201 10. Normative References 1203 [RFC1035] Mockapetris, P., "Domain names - implementation and 1204 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 1205 November 1987, . 1207 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1208 Requirement Levels", BCP 14, RFC 2119, 1209 DOI 10.17487/RFC2119, March 1997, 1210 . 1212 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1213 Specifications: ABNF", STD 68, RFC 5234, 1214 DOI 10.17487/RFC5234, January 2008, 1215 . 1217 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 1218 DOI 10.17487/RFC5321, October 2008, 1219 . 1221 [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598, 1222 DOI 10.17487/RFC5598, July 2009, 1223 . 1225 [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 1226 "DomainKeys Identified Mail (DKIM) Signatures", STD 76, 1227 RFC 6376, DOI 10.17487/RFC6376, September 2011, 1228 . 1230 [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for 1231 Authorizing Use of Domains in Email, Version 1", RFC 7208, 1232 DOI 10.17487/RFC7208, April 2014, 1233 . 1235 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 1236 Message Authentication, Reporting, and Conformance 1237 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 1238 . 1240 [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M. 1241 Kucherawy, Ed., "The Authenticated Received Chain (ARC) 1242 Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019, 1243 . 1245 11. Informative References 1247 [BIMI-OVERVIEW] 1248 "An Overview of the Design of BIMI", 1249 . 1252 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1253 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1254 May 2017, . 1256 Appendix A. Example Selector Discovery (INFORMATIVE) 1258 This section shows several examples of how a receiving MTA should 1259 determine which Assertion Record to use depending on the BIMI- 1260 Selector header. 1262 A.1. No BIMI-Selector Header 1264 The domain example.com does not send with a BIMI-Selector header. 1266 From: sender@example.com 1268 The MTA would lookup default._bimi.example.com for the BIMI DNS 1269 record. 1271 A.2. With BIMI-Selector Header 1273 The domain example.com sends with a BIMI-Selector header: 1275 From: sender@example.com 1276 BIMI-Selector: v=BIMI1; s=selector; 1278 The MTA would lookup selector._bimi.example.com. 1280 A.3. Without BIMI-Selector Header on a subdomain 1282 The domain foo.example.com sends without a BIMI-Selector header: 1284 From: sender@foo.example.com 1286 The MTA would lookup default._bimi.foo.example.com for the BIMI DNS 1287 record. If it did not exist, it would lookup 1288 default._bimi.example.com. 1290 A.4. With BIMI-Selector Header on a subdomain 1292 The domain foo.example.com sends without a BIMI-Selector header: 1294 From: sender@foo.example.com 1295 BIMI-Selector: v=BIMI1; s=myselector; 1297 The MTA would lookup myselector._bimi.foo.example.com for the BIMI 1298 DNS record. If it did not exist, it would fall back to the lookup 1299 myselector._bimi.example.com. 1301 A.5. Invalid BIMI-Selector Header 1303 The domain example.com sends with a BIMI-Selector header, but does 1304 not include the required field 'v=': 1306 From: sender@example.com 1307 BIMI-Selector: s=myselector; 1309 The MTA would ignore this header, and lookup 1310 default._bimi.example.com. 1312 Appendix B. Example Authentication-Results entry (INFORMATIONAL) 1314 This section shows example Authentication-Results stamps based on 1315 different BIMI lookup statuses. 1317 B.1. Successful BIMI lookup 1319 From: sender@example.com 1320 BIMI-Selector: v=BIMI1; s=myselector; 1321 Authentication-Results: bimi=pass header.d=example.com header.selector=myselector; 1323 B.2. No BIMI record 1325 From: sender@sub.example.com 1326 Authentication-Results: bimi=none; 1328 In this example, sub.example.com does not have a BIMI record at 1329 default._bimi.sub.example.com, nor does default._bimi.example.com 1331 B.3. Declination to Publish 1333 From: sender@example.com 1334 Authentication-Results: bimi=declined; 1336 In this example the record found at default._bimi.example.com was 1337 "v=BIMI1; l=; a=;", indicating a Declination to Publish a BIMI 1338 Assertion Record, and so indicating that BIMI processing should not 1339 occur on this message. 1341 B.4. Subdomain has no default record, but organizational domain does 1343 From: sender@sub.example.com 1344 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 1481 Alex Brotman (ed) 1482 Comcast 1483 Email: alex_brotman@comcast.com