idnits 2.17.1 draft-blank-ietf-bimi-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 11 instances of too long lines in the document, the longest one being 399 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 384: '...e BIMI mechanism SHOULD make a best-ef...' RFC 2119 keyword, line 387: '...r end users, and MAY use alternate ind...' RFC 2119 keyword, line 433: '...ned precisely, mail receivers MUST NOT...' RFC 2119 keyword, line 443: '...ocessed; unknown tags MUST be ignored....' RFC 2119 keyword, line 448: '...BIMI record. It MUST have the value o...' (42 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year ** The document contains RFC2119-like boilerplate, but doesn't seem to mention RFC 2119. The boilerplate contains a reference [KEYWORDS], but that reference does not seem to mention RFC 2119 either. -- The document date (February 06, 2019) is 1906 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1003 -- Looks like a reference, but probably isn't: '2' on line 1005 -- Looks like a reference, but probably isn't: '3' on line 1007 == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 947, but not defined == Unused Reference: 'Authentication-Results' is defined on line 964, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7601 (ref. 'Authentication-Results') (Obsoleted by RFC 8601) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Blank 3 Internet-Draft P. Goldstein 4 Intended status: Experimental Valimail 5 Expires: August 10, 2019 T. Loder, Ed. 6 Skye Logicworks 7 T. Zink, Ed. 8 February 06, 2019 10 Brand Indicators for Message Identification (BIMI) 11 draft-blank-ietf-bimi-00 13 Abstract 15 Brand Indicators for Message Identification (BIMI) permits Domain 16 Owners to coordinate with Mail User Agents (MUAs) to display brand- 17 specific Indicators next to properly authenticated messages. There 18 are two aspects of BIMI coordination: a scalable mechanism for Domain 19 Owners to publish their desired indicators, and a mechanism for Mail 20 Transfer Agents (MTAs) to verify the authenticity of the indicator. 21 This document specifies how Domain Owners communicate their desired 22 indicators through the BIMI assertion record in DNS and how that 23 record is to be handled by MTAs and MUAs. The domain verification 24 mechanism and extensions for other mail protocols (IMAP, etc.) are 25 specified in separate documents. MUAs and mail-receiving 26 organizations are free to define their own policies for indicator 27 display that makes use or not of BIMI data as they see fit. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 10, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 7 68 3.3. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Terminology and Definitions . . . . . . . . . . . . . . . . . 7 70 4.1. BIMI Assertion . . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Indicator . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3. Mark Verifying Authority (MVA) . . . . . . . . . . . . . 8 73 4.4. Mark Verified Certificate (MVC) . . . . . . . . . . . . . 8 74 4.5. Protocol Client . . . . . . . . . . . . . . . . . . . . . 8 75 4.6. Verifying Protocol Client . . . . . . . . . . . . . . . . 8 76 5. BIMI DNS Records . . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. Assertion Record . . . . . . . . . . . . . . . . . . . . 9 78 5.1.1. Declination to publish . . . . . . . . . . . . . . . 11 79 5.1.2. Supported Image Formats for l= tag . . . . . . . . . 11 80 5.2. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6. BIMI Header Fields . . . . . . . . . . . . . . . . . . . . . 12 82 6.1. BIMI-Selector . . . . . . . . . . . . . . . . . . . . . . 12 83 6.2. BIMI-Location . . . . . . . . . . . . . . . . . . . . . . 13 84 6.3. Header Signing . . . . . . . . . . . . . . . . . . . . . 14 85 7. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . 14 86 7.1. Determine and publish Indicator(s) for use . . . . . . . 14 87 7.2. Specify Domain Owner Preference . . . . . . . . . . . . . 14 88 7.3. Publish Assertion Records . . . . . . . . . . . . . . . . 14 89 7.4. Manage multiple uses of the same Indicator(s) within a 90 trust boundary . . . . . . . . . . . . . . . . . . . . . 15 91 7.5. Set the headers on outgoing email as appropriate . . . . 15 92 8. Receiver Actions . . . . . . . . . . . . . . . . . . . . . . 15 93 8.1. Indicator Discovery . . . . . . . . . . . . . . . . . . . 15 94 8.2. Indicator Validation . . . . . . . . . . . . . . . . . . 16 95 8.3. Affix BIMI status to Authentication Results header field 17 96 8.4. Handle Existing BIMI-Location Headers . . . . . . . . . . 17 97 8.5. Construct BIMI-Location URI(s) . . . . . . . . . . . . . 18 98 8.6. Set appropriate flags on the mail store . . . . . . . . . 18 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 9.1. Lookalike Domains and Copycat Indicators . . . . . . . . 18 101 9.2. Large files and buffer overflows . . . . . . . . . . . . 19 102 9.3. Slow DNS queries . . . . . . . . . . . . . . . . . . . . 19 103 9.4. Unaligned indicators and asserting domains . . . . . . . 19 104 9.5. Unsigned BIMI-Selector Header . . . . . . . . . . . . . . 19 105 9.6. CGI scripts in Indicator payload . . . . . . . . . . . . 19 106 9.7. Metadata in Indicators . . . . . . . . . . . . . . . . . 20 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 108 10.1. Permanent Header Field Updates . . . . . . . . . . . . . 20 109 10.2. Registry for Support BIMI Formats . . . . . . . . . . . 20 110 10.3. Other IANA needs . . . . . . . . . . . . . . . . . . . . 21 111 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 112 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 113 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22 114 Appendix A. Example Selector Discovery (INFORMATIVE) . . . . . . 22 115 A.1. No BIMI-Selector Header . . . . . . . . . . . . . . . . . 22 116 A.2. With BIMI-Selector Header . . . . . . . . . . . . . . . . 22 117 A.3. Without BIMI-Selector Header on a subdomain . . . . . . . 22 118 A.4. With BIMI-Selector Header on a subdomain . . . . . . . . 23 119 A.5. Invalid BIMI-Selector Header . . . . . . . . . . . . . . 23 120 Appendix B. Example Authentication-Results entry (INFORMATIONAL) 23 121 B.1. Successful BIMI lookup . . . . . . . . . . . . . . . . . 23 122 B.2. No BIMI record . . . . . . . . . . . . . . . . . . . . . 23 123 B.3. Subdomain has no default record, but organizational 124 domain does . . . . . . . . . . . . . . . . . . . . . . . 23 125 B.4. Subdomain has no record for selector, but organization 126 domain has a default . . . . . . . . . . . . . . . . . . 24 127 Appendix C. Example BIMI-Location Construction (INFORMATIONAL) . 24 128 C.1. MTA Receives an email . . . . . . . . . . . . . . . . . . 24 129 C.2. MTA does its authentication checks . . . . . . . . . . . 24 130 C.3. MTA performs BIMI Assertion . . . . . . . . . . . . . . . 24 131 C.4. MTA appends to Authentication-Results . . . . . . . . . . 25 132 C.5. MTA Constructs BIMI-Location header . . . . . . . . . . . 25 133 C.6. The MUA displays the indicator . . . . . . . . . . . . . 25 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 136 1. Introduction 138 This document defines Brand Indicators for Message Identification 139 (BIMI), which permits Domain Owners to coordinate with Mail User 140 Agents (MUAs) to display brand-specific Indicators next to properly 141 authenticated messages. 143 BIMI is an open system that works at internet scale, so that Domain 144 Owners can coordinate with MUAs to display appropriate Indicators. 145 BIMI has the added benefit of incentivizing Domain Owners to 146 authenticate their email. 148 The approach taken by BIMI is heavily influenced by the approach 149 taken in DKIM [1], in that BIMI: 151 o has no dependency on the deployment of any new Internet protocols 152 or services for indicator registration or revocation; 154 o makes no attempt to include encryption as part of the mechanism; 156 o is compatible with the existing email infrastructure and 157 transparent to the fullest extent possible; 159 o requires minimal new infrastructure; 161 o can be implemented independently of clients in order to reduce 162 deployment time; 164 o can be deployed incrementally; and 166 o allows delegation of indicator hosting to third parties. 168 This document covers the BIMI mechanism for Domain Owners to publish 169 their desired indicators and how Mail Transfer Agents (MTAs) and MUAs 170 should handle this communication. This document does not cover how 171 domains or indicators are verified, how MUAs should display the 172 indicators, or how other protocols (i.e. IMAP, JMAP) should be 173 extended to work with BIMI. Other documents will cover these topics. 175 2. Overview 177 The Sender Policy Framework ([SPF]), DomainKeys Identified Mail 178 ([DKIM]), and Domain-based Message Authentication, Reporting, and 179 Conformance ([DMARC]) provide mechanisms for domain-level 180 authentication for email messages. They enable cooperating email 181 senders and receivers to distinguish messages that are authorized to 182 use the domain name from those that are not. BIMI relies on these 183 authentication protocols, but is not a new authentication protocol 184 itself. 186 MUAs are increasingly incorporating graphical logos to indicate the 187 identity of the sender of a message. While a discussion of the 188 merits of doing this are beyond the scope of this document, at 189 present there are no open standards for publishing and discovery of 190 preferred logos or of tying these usages only to properly 191 authenticated messages. 193 Because of this need for brand specific indicators, some mail- 194 receiving organizations have developed closed systems for obtaining 195 and displaying brand indicators for some select domains. While this 196 enabled these mail-receiving organizations to display brand 197 indicators for a limited subset of messages, this closed approach has 198 significant downsides: 200 1. It puts a significant burden on each mail-receiving organization, 201 because they must identify and manage a large database of brand 202 indicators. 204 2. Scalability is challenging for closed systems that attempt to 205 capture and maintain complete sets of data across the whole of 206 the Internet. 208 3. A lack of uniformity across different mail-receiving 209 organizations - each organization will have its own indicator 210 set, which may or may not agree with those maintained by other 211 organizations for any given domain. 213 4. Domain Owners have limited ability to influence the brand 214 indicator for the domain(s) they own, and such ability they do 215 have is likely to require coordination with many mail-receiving 216 organizations. 218 5. Many Domain Owners have no ability to participate whatsoever as 219 they do not have the appropriate relationships to coordinate with 220 mail-receiving organizations. 222 6. MUAs that are not associated with a particular mail-receiving 223 organization are likely to be disadvantaged, because they are 224 unlikely to receive indicators in a manner optimized for their 225 user interfaces. 227 This all speaks to the need for a standardized mechanism by which 228 Domain Owners interested in ensuring that their indicators are 229 displayed correctly and appropriately can publish and distribute 230 brand indicators for use by any participating MUA. 232 BIMI removes the substantial burden of curating and maintaining an 233 indicator database from the MUAs, and allows each domain to manage 234 its own indicators. As an additional benefit, mail-originating 235 organizations are more likely to invest the time and effort to 236 authenticate their email, should that come with the ability to 237 influence how email from the organization is displayed. 239 The basic structure of BIMI is as follows: 241 1. Domain Owners publish brand indicator assertions for domains via 242 the [DNS]. 244 2. Then, for any message received by a Mail Receiver: 246 a. Receivers authenticate the messages using [DMARC] and 247 whatever other authentication mechanisms they wish to apply. 249 b. The receiver queries the DNS for a corresponding BIMI record 250 and proof of indicator validation. 252 c. If both the email and the logo authenticate, then the 253 receiver adds a header to the message, which can be used by the 254 MUA to determine the Domain Owner's preferred brand indicator. 256 3. The MUA retrieves and displays the brand indicator as appropriate 257 based on its policy and user interface. 259 The purpose of this structure is to reduce operational complexity at 260 each step and to consolidate validation and indicator selection into 261 the MTA, so that Domain Owners only need to publish simple rules and 262 MUAs only need simple display logic. 264 3. Requirements 266 Specification of BIMI in this document is guided by the following 267 high-level goals, security dependencies, detailed requirements, and 268 items that are documented as out of scope. 270 3.1. High-Level Goals 272 BIMI has the following high-level goals: 274 o Allow Domain Owners to suggest appropriate indicators for display 275 with authenticated messages originating from their domains. 277 o Enable the authors of MUAs to display meaningful indicators 278 associated with the Domain Owner to recipients of authenticated 279 email. 281 o Provide mechanisms to prevent attempts by malicious Domain Owners 282 to fraudulently represent messages from their domains as 283 originating with other entities. 285 o Work at Internet Scale. 287 3.2. Security 289 Brand indicators are a potential vector for abuse. BIMI creates a 290 relationship between sending organization and Mail Receiver so that 291 the receiver can display appropriately designated indicators if the 292 sending domain is verified and has meaningful reputation with the 293 receiver. Without verification and reputation, there is no way to 294 prevent a bad actor exxample.com from using example.com's brand 295 indicators and behaving maliciously. This document does not cover 296 these verification and reputation mechanisms, but BIMI requires them 297 to control abuse. 299 3.3. Out of Scope 301 Several topics and issues are specifically out of scope for the 302 initial version of this work. These include the following: 304 o Publishing policy other than via the DNS. 306 o Specific requirements for indicator display on MUAs. 308 o The explicit mechanisms used by Verifying Protocol Clients - this 309 will be deferred to a later document. 311 4. Terminology and Definitions 313 This section defines terms used in the rest of the document. 315 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 316 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 317 document are to be interpreted as described in [KEYWORDS]. 319 Readers are encouraged to be familiar with the contents of 320 [EMAIL-ARCH]. In particular, that document defines various roles in 321 the messaging infrastructure that can appear the same or separate in 322 various contexts. For example, a Domain Owner could, via the 323 messaging mechanisms on which BIMI is based, delegate control over 324 defining preferred brand indicators as the Domain Owner to a third 325 party with another role. This document does not address the 326 distinctions among such roles; the reader is encouraged to become 327 familiar with that material before continuing. 329 Syntax descriptions use Augmented BNF [ABNF]. 331 "Author Domain", "Domain Owner", "Organizational Domain", and "Mail 332 Receiver" are imported from [DMARC] Section 3. 334 4.1. BIMI Assertion 336 The mechanism through which a Protocol Client verifies the BIMI 337 Assertion Record and constructs the URI(s) to the requested 338 indicator(s) to be placed in the BIMI-Location header. 340 4.2. Indicator 342 The icon, image, mark, or other graphical representation of the 343 brand. The Indicator is in a common image format with restrictions 344 detailed in the Assertion Record definition (Section 5.1). 346 4.3. Mark Verifying Authority (MVA) 348 An entity of organization that can provide evidence of verification 349 of indicators asserted by a Domain Owner to Verifying Protocol 350 Clients. The MVA may choose to uphold and confirm the meeting of 351 certain indicator standards (ie. size, trademark, content, etc). 353 4.4. Mark Verified Certificate (MVC) 355 A certificate issued by a CA which has validated the attested logo in 356 accordance with Validated Mark Certificate Guidelines, which are 357 defined in a separate document. 359 4.5. Protocol Client 361 An entity that uses the BIMI protocol to discover and fetch published 362 indicators. 364 4.6. Verifying Protocol Client 366 A Protocol Client that uses the optional verification capability to 367 inquire about the verification status of published indicators. 369 5. BIMI DNS Records 371 BIMI policies are published by Domain Owners and applied by Protocol 372 Clients. 374 A Domain Owner advertises BIMI participation of one or more of its 375 domains by adding a DNS TXT record to those domains. In doing so, 376 Domain Owners make specific requests of MUAs regarding the preferred 377 set of indicators to be displayed with messages purporting to be from 378 one of the Domain Owner's domains. 380 A Domain Owner may choose not to participate in BIMI. In this case, 381 the Domain Owner simply declines to advertise participation by not 382 publishing any BIMI assertion record. 384 An MUA implementing the BIMI mechanism SHOULD make a best-effort 385 attempt to adhere to the Domain Owner's published BIMI policy. 386 However, MUAs have final control over the user interface published to 387 their end users, and MAY use alternate indicators than those 388 specified in the BIMI assertion record or no indicator at all. 390 BIMI's use of the DNS is driven by BIMI's use of domain names and the 391 nature of the query it performs. Use of the DNS as the query service 392 has the benefit of reusing an extremely well-established operations, 393 administration, and management infrastructure, rather than creating a 394 new one. 396 BIMI's policy payload is intentionally only published via a DNS 397 record and not an email header. This serves four purposes: 399 1. There is one and only one mechanism for both simple and complex 400 policies to be published. 402 2. Operational complexity is reduced, and MTAs only need to check a 403 single record in a consistent manner to enforce policy. 405 3. MTAs that understand their MUAs have more control over which 406 Indicators they choose for those MUAs. 408 4. Indicators can be verified and/or cached in advance, so that 409 malicious headers cannot be used as an attack vector. 411 Per [DNS], a TXT record can comprise several "character-string" 412 objects. BIMI TXT records with multiple strings must be treated in 413 an identical manner to SPF Section 3.3 [2]. 415 5.1. Assertion Record 417 All Domain Owner BIMI preferences are stored as DNS TXT records in 418 subdomains named "_bimi". BIMI allows the definition of multiple 419 preferences associated with a single RFC5322.From domain. To 420 distinguish between these different preferences, BIMI uses 421 Section 5.2. Senders advertise which selector to use by specifying 422 it in a BIMI-Selector header (Section 6.1). 424 For example, the Domain Owner of "example.com" would post BIMI 425 preferences in a TXT record at "default._bimi.example.com". 426 Similarly, a Mail Receiver wishing to query for BIMI preferences 427 regarding mail with an RFC5322.From Author Domain of "example.com" 428 and a selector "default" would issue a TXT query to the DNS for the 429 subdomain of "default._bimi.example.com". The DNS-located BIMI 430 preference data will hereafter be called the "BIMI Assertion Record" 431 or "Assertion Record". 433 Assertion Records are defined precisely, mail receivers MUST NOT 434 attempt to fix syntactical or capitalization errors. If a required 435 tag is missing, it is an error. 437 BIMI Assertion Records follow the extensible "tag-value" syntax for 438 DNS-based key records defined in [DKIM]. 440 This section creates a registry for known BIMI tags and registers the 441 initial set defined in this document. Only tags defined in this 442 document or in later extensions, and thus added to that registry, are 443 to be processed; unknown tags MUST be ignored. 445 The following tags are introduced as the initial valid BIMI tags: 447 v= Version (plain-text; REQUIRED). Identifies the record retrieved 448 as a BIMI record. It MUST have the value of "BIMI1" for 449 implementations compliant with this version of BIMI. The value of 450 this tag MUST match precisely; if it does not or it is absent, the 451 entire retrieved record MUST be ignored. It MUST be the first tag in 452 the list. 454 ABNF: 456 bimi-version = %x76 *WSP "=" *WSP %x42.49.4d.49 1DIGIT 458 a= Trust Authorities (plain-text; URI; OPTIONAL). A reserved value. 460 ABNF: 462 bimi-authorities = %x61 *WSP "=" \[bimi-location-uri\] 464 NOTE TO WORKING GROUP: This a= tag needs to be extended, to provide validation options. Current expectations are: "self", "cert", and "mva". Where "self" means there is no validation option (perhaps this is best done by simply not supplying an a= tag?), "cert" provides an HTTPS URL to a Mark Verified Certificate that can be used to validate the indicator at the l= tag, and "mva" specifies an HTTPS URL to an API endpoint that can be queried for validation information. 466 l= locations (URI; REQUIRED). The value of this tag is a comma 467 separated list of base URLs representing the location of the brand 468 indicator files. All clients MUST support use of at least 2 location 469 URIs, used in order. Clients MAY support more locations. The 470 supported transport is HTTPS only. 472 ABNF: 474 bimi-location-uri = \[FWS\] URI \[FWS\] 476 ; "URI" is imported from [URI] 477 ; HTTPS only 478 ; commas (ASCII ; 0x2C) MUST be encoded 480 bimi-locations = %x6c *WSP "=" bimi-location-uri *("," bimi-location-uri) \[","\] 482 Therefore, the formal definition of the BIMI Assertion Record, using 483 [ABNF], is as follows: 485 bimi-sep = *WSP %x3b *WSP 487 bimi-record = bimi-version (bimi-sep bimi-locations) (bimi-sep bimi-authorities) \[bimi-sep\] 489 ; components other than bimi-version may appear in any order 491 5.1.1. Declination to publish 493 If both the "l" and "a" tags are empty, it is an explicit refusal to 494 participate in BIMI. This is critically different than not 495 publishing a BIMI record in the first place. For example, this 496 allows a subdomain to decline participation when its organizational 497 domain has default Indicators available. Furthermore, messages sent 498 using a selector that has declined to publish will not show an 499 Indicator while messages with other selectors would display normally. 501 An explicit declination to publish looks like: 503 v=BIMI1; l=; a=; 505 5.1.2. Supported Image Formats for l= tag 507 Any format in the BIMI-formats IANA registry are acceptable targets 508 for the l= tag. If an l= tag ends with any other image format, the 509 record MUST be treated as if it has a permanent error. 511 As of the publishing of this document, only SVG as defined in 512 (RFC6170 section 5.2)[https://tools.ietf.org/html/rfc6170#section- 513 5.2] is acceptable for publishing in the l= tag. 515 5.2. Selectors 517 To support multiple brand indicators per domain, the brand indicator 518 namespace is subdivided for the publishing of multiple Assertion 519 Records using "selectors". Selectors allow the Domain Owner to 520 better target the brand indicator by type of recipient, message 521 source, or other considerations like seasonal branding. BIMI 522 selectors are modeled after DKIM selectors [3]. 524 The selector "default" is the default Assertion Record. Domain 525 Owners can specify which other selector to use on a per-message basis 526 by utilizing the BIMI-Selector Header (Section 6.1). 528 Periods are allowed in selectors and are component separators. When 529 BIMI Assertion Records are retrieved from the DNS, periods in 530 selectors define DNS label boundaries in a manner similar to the 531 conventional use in domain names. In a DNS implementation, this can 532 be used to allow delegation of a portion of the selector namespace. 534 ABNF: 536 selector = sub-domain *( "." sub-domain ) 538 ; from [SMTP] Domain, 540 ; excluding address-literal 542 The number of selectors for each domain is determined by the Domain 543 Owner. Many Domain Owners will be satisfied with just one selector, 544 whereas organizations with more complex branding requirements can 545 choose to manage disparate selectors. BIMI sets no maximum limit on 546 the number of selectors. 548 6. BIMI Header Fields 550 Once BIMI policies are published in DNS via Assertion Records, 551 additional guidance can be provided from Domain Owners to Mail 552 Receivers, and Mail Receivers to their MUAs through the use of 553 additional BIMI header fields. 555 BIMI header fields are case insensitive. If a required tag is 556 missing, it is an error. 558 6.1. BIMI-Selector 560 BIMI DNS records are placed in ._bimi., and by 561 default they are placed in default._bimi.. That is, for 562 example.com, the default location for all BIMI lookups is 563 default._bimi.example.com. However, a Domain Owner may specify the 564 selector using the RFC 5322 header 'BIMI-Selector'. The BIMI- 565 Selector header consists of key value pairs: 567 v= Version (plain-text; REQUIRED). The version of BIMI. It MUST 568 have the value of "BIMI1" for implementations compliant with this 569 version of BIMI. The value of this tag MUST match precisely; if it 570 does not or it is absent, the entire retrieved record MUST be 571 ignored. It MUST be the first tag in the list. 573 ABNF: 575 bimi-header-version = "v" *WSP "=" *WSP "BIMI" 1DIGIT 577 s= Selector (plain-text; REQUIRED). The location of the BIMI DNS 578 record, when combined with the RFC5322.From domain. 580 ABNF: 582 bimi-selector = "s" *WSP "=" *WSP selector 584 And the formal definition of the BIMI Selector Header, using ABNF, is 585 as follows: 587 bimi-selector-header = bimi-header-version bimi-sep bimi-selector \[bimi-sep\] 589 6.2. BIMI-Location 591 BIMI-Location is the header a Mail Receiver inserts that tells the 592 MUA where to get the BIMI indicator from. 594 The syntax of the header is as following: 596 v= Version (plain-text; REQUIRED). The version of BIMI. It MUST 597 have the value of "BIMI1" for implementations compliant with this 598 version of BIMI. The value of this tag MUST match precisely; if it 599 does not or it is absent, the entire retrieved record MUST be 600 ignored. It MUST be the first tag in the list. 602 The ABNF for bimi-header-version is imported exactly from the [BIMI Selector Header](#bimi-selector). 604 l: location of the BIMI indicator (URI; REQUIRED). Inserted by the 605 MTA after parsing through the BIMI DNS record and performing the 606 required checks. The value of this tag is a comma separated list of 607 URLs representing the location of the brand indicator files. All 608 clients MUST support use of at least 2 location URIs, used in order. 609 Clients MAY support more locations. Initially the supported 610 transport supported is HTTPS only. 612 ABNF: 614 bimi-header-locations = "l" *WSP "=" bimi-location-uri *("," bimi-location-uri) \[","\] 615 And the formal definition of the BIMI Location Header, using ABNF, is 616 as follows: 618 bimi-location-header = bimi-header-version bimi-sep bimi-header-locations \[bimi-sep\] 620 6.3. Header Signing 622 The BIMI-Selector SHOULD be signed by DKIM. 624 The BIMI-Location header MUST NOT be DKIM signed. This header is 625 untrusted by definition, and is only for use between an MTA and its 626 MUAs, after DKIM has been validated by the MTA. Therefore, signing 627 this header is meaningless, and any messages with it signed are 628 either coming from malicious or misconfigured third parties. 630 7. Domain Owner Actions 632 This section includes a walk through of the actions a Domain Owner 633 takes when setting up Assertion Records and sending email messages. 635 7.1. Determine and publish Indicator(s) for use 637 Domain Owners should consider which Indicator file formats to choose 638 when setting up their BIMI Assertion Records. As a Sender, BIMI 639 provides control over which Indicators are chosen for display, but 640 not the ultimate manner in which the MUA will display the image. 642 BIMI allows multiple comma separated l= values in the Assertion 643 Record, so that a Domain Owner may publish the same Indicators in 644 multiple world readable locations. This is so Indicators may still 645 be available if there are service or DNS issues for a particular l= 646 value. 648 7.2. Specify Domain Owner Preference 650 The ordering of the l= tag is significant, the first location 651 specified should have priority over the second, etc. 653 This does not guarantee that the first tags specified will be 654 selected as there may be DNS errors, or some clients may not support 655 all formats. However, on average, the first tags specified SHOULD be 656 used to construct the indicator passed to the MUA. 658 7.3. Publish Assertion Records 660 For each set of Indicators and domains, publish the appropriate 661 Assertion Record as either "default" or a named selector as a DNS TXT 662 record within the appropriate "_bimi" namespace. 664 7.4. Manage multiple uses of the same Indicator(s) within a trust 665 boundary 667 For Domain Owners with multiple domains that wish to share the same 668 set of Indicators within a trust boundary and only manage those 669 Indicators from a single DNS location, it is RECOMMENDED to use DNS 670 CNAMEs. 672 Using a CNAME here is functionally similar to the SPF redirect 673 modifier. Since BIMI does not require l= tags to be aligned to the 674 Author Domain, CNAMEs present a cleaner solution than extending the 675 protocol. 677 7.5. Set the headers on outgoing email as appropriate 679 Once a default Assertion Record has been published for an Author 680 Domain, all emails from this domain should display the appropriate 681 Indicator in participating MUAs. 683 If a non-default Indicator is desired, the BIMI-Selector header 684 should be set appropriately. If for some reason this selector cannot 685 be accessed by the Protocol Client, the fallback is the default 686 Assertion Record on the Organization domain. 688 The BIMI-Location header MUST NOT be set by email senders, and 689 Protocol Clients MUST ignore it. 691 8. Receiver Actions 693 This section includes a walk through of the actions a Protocol Client 694 takes when evaluating an email message for BIMI Assertion. 696 8.1. Indicator Discovery 698 Through the BIMI Assertion Record (Section 5.1), the BIMI mechanism 699 uses DNS TXT records to advertise preferences. Preference discovery 700 is accomplished via a method similar to the method used for [DMARC] 701 records. This method, and the important differences between BIMI and 702 [DMARC] mechanisms, are discussed below. 704 Indicator Discovery MUST only be attempted if the message 705 authenticates per Receiver policy. 707 To balance the conflicting requirements of supporting wildcarding, 708 allowing subdomain policy overrides, and limiting DNS query load, 709 Protocol Clients MUST employ the following lookup scheme for the 710 appropriate BIMI record for the message: 712 1. Start with the DNS domain found in the RFC5322.From header in the 713 message. Define this DNS domain as the Author Domain. 715 2. If the message for which the indicator is being determined 716 specifies a selector value in the BIMI Selector Header 717 (Section 6.1), use this value for the selector. Otherwise the 718 value 'default' MUST be used for the selector. 720 3. Clients MUST query the DNS for a BIMI TXT record at the DNS 721 domain constructed by concatenating the selector, the string 722 '_bimi', and the Author Domain. A possibly empty set of records 723 is returned. 725 4. Records that do not start with a "v=" tag that identifies the 726 current version of BIMI MUST be discarded. 728 5. If the set is now empty, the Client MUST query the DNS for a BIMI 729 TXT record at the DNS domain constructed by concatenating the 730 selector 'default', the string '_bimi', and the Organizational 731 Domain (as defined in [DMARC]) corresponding to the Author 732 Domain. A custom selector that does not exist falls back to 733 default._bimi., and NOT 734 ._bimi.. A possibly empty set of 735 records is returned. 737 6. Records that do not start with a "v=" tag that identifies the 738 current version of BIMI MUST be discarded. 740 7. If the remaining set contains multiple records or no records, 741 indicator discovery terminates and BIMI processing MUST NOT be 742 performed for this message. 744 8. If the remaining set contains only a single record, this record 745 is used for BIMI Assertion. 747 8.2. Indicator Validation 749 If an Assertion Record is found and has an a= tag, it must be used to 750 validate the indicator using the following algorithm: 752 1. Use the mechanism in the a= tag to retrieve the validated hash. 754 2. Compute the hash of the logo in the l= tag. 756 3. If the hash of the logo does not match the validated hash, then 757 logo validation has failed and then indicator MUST NOT be 758 displayed. 760 4. If the hashes match, and the validated hash is from a trusted 761 source, then the indicator can be displayed per receiver policy. 763 8.3. Affix BIMI status to Authentication Results header field 765 Upon completion of Indicator Discovery, an MTA SHOULD affix the 766 result in the Authentication-Results header using the following 767 syntax, with the following key=value pairs: 769 bimi: Result of the bimi lookup (plain-text; REQUIRED). Range of 770 values are 'pass' (BIMI successfully validated), 'none' (no BIMI 771 record present), 'fail' (syntax error in the BIMI record, or some 772 other error), 'temperror' (DNS lookup problem), or 'skipped' (BIMI 773 check did not perform, possibly because the message did not comply 774 with the minimum requirements such as passing DMARC, or the MTA does 775 not trust the sending domain). The MTA MAY put comments in 776 parentheses after bimi result, e.g., "bimi=skipped (sender not 777 trusted)" or "bimi=skipped (message failed DMARC)". 779 header.d: Domain used in a successful BIMI lookup (plain-text; 780 REQUIRED if bimi=pass). If the first lookup fails for whatever 781 reason, and the second one passes (e.g., using the organizational 782 domain), the organizational domain should appear here. If both fail 783 (or have no record), then the first domain appears here. 785 selector: Selector used in a successful BIMI lookup (plain-text; 786 REQUIRED if bimi=pass). Range of values include the value in the 787 BIMI-Selector header, and 'default'. If the first lookup fails (or 788 has no record) and second passes, the second selector should appear 789 here. If both fail (or have no record), then the first selector 790 should appear here. 792 8.4. Handle Existing BIMI-Location Headers 794 Regardless of success of the BIMI lookup, if the BIMI-Location header 795 already exists it MUST be either removed or renamed. 797 This is because the MTA doing BIMI Assertion is the only entity 798 allowed to specify the BIMI-Location header, and allowing any 799 existing header through is a security risk. 801 Additionally, at this point, if the original email message had a DKIM 802 signature, it has already been evaluated. Removing the header at 803 this point should not break DKIM, especially because this header 804 should not be signed per this spec. 806 8.5. Construct BIMI-Location URI(s) 808 The l= value of the BIMI-Location header is a comma separated list of 809 URIs to Indicators the MTA believes are most applicable to its MUAs. 810 From the options provided by the Assertion Record, MTAs SHOULD choose 811 the Indicators to include based on Receiver policy for optimal 812 performance and user experience for its MUAs from the. 814 MTAs MAY add as many comma separated URIs to the l= tag in the BIMI- 815 Location header as they wish, MUAs MUST support at least 2 location 816 URIs in the header, and MAY support more. 818 8.6. Set appropriate flags on the mail store 820 Once an MTA has finished BIMI Assertion, it needs to deposit the 821 email somewhere where the user can eventually access it with an MUA. 822 Users typically access their email on mail stores through either 823 POP3, IMAP, and MAPI. Separate documents will define protocol- 824 specific BIMI extensions for mail stores. 826 If a mail store is BIMI-compliant, the MTA SHOULD set a flag on the 827 message when depositing in the mail store. This is to communicate 828 between the MTA and its MUA that the BIMI-Location header was set 829 locally and can be trusted. 831 If an MUA has a BIMI-compliant mail store, and no appropriate flag is 832 set, the MUA SHOULD ignore the BIMI-Location header. 834 If a mail store ingests a message from another mail store through 835 some other means, the ingesting mail store may or may not set the 836 protocol-specific BIMI flag when it pulls down the relayed message. 837 If it trusts the other mail store, it may simply set the same flag. 838 Or, it may perform BIMI Assertion from scratch, create or replace the 839 BIMI-Location header, and set its own flag appropriately. Or, it may 840 simply choose not to set the flag at all. 842 9. Security Considerations 844 The consistent use of brand indicators is valuable for Domain Owners, 845 Mail Receivers, and End Users. However, this also creates room for 846 abuse, especially for determined malicious actors. 848 9.1. Lookalike Domains and Copycat Indicators 850 Publishing BIMI records is not sufficient for an MTA to signal to the 851 MUA to load the BIMI indicator. Instead, the Domain Owner should 852 have a good reputation with the MTA. Thus, BIMI display requires 853 passing BIMI, and passing email authentication checks, and having a 854 good reputation at the receiver. The receiver may use a manually 855 maintained list of large brands, or it may import a list from a third 856 party of good domains, or it may apply its own reputation heuristics 857 before deciding whether or not to load the BIMI indicator. 859 9.2. Large files and buffer overflows 861 The MTA or MUA should perform some basic analysis and avoid loading 862 indicators that are too large or too small. The Receiver may choose 863 to maintain a manual list and do the inspection of its list offline 864 so it doesn't have to do it at time-of-scan. 866 9.3. Slow DNS queries 868 All email Receivers already have to query for DNS records, and all of 869 them have built-in timeouts when performing DNS queries. 870 Furthermore, the use of caching when loading images can help cut down 871 on load time. Virtually all email clients have some sort of image- 872 downloading built-in and make decisions when to load or not load 873 images. 875 9.4. Unaligned indicators and asserting domains 877 There is no guarantee that a group responsible for managing brand 878 indicators will have access to put these indicators directly in any 879 specific location of a domain, and requiring that indicators live on 880 the asserted domain is too high a bar. Additionally, letting a brand 881 have indicator locations outside its domain may be desirable so that 882 someone sending legitimate authenticated email on the Domain Owner's 883 behalf can manage and set selectors as an authorized third party 884 without requiring access to the Domain Owner's DNS or web services. 886 9.5. Unsigned BIMI-Selector Header 888 If a Domain Owner relies on SPF but not DKIM for email 889 authentication, then adding a requirement of DKIM may create too high 890 of a bar for that sender. On the other hand, Receivers doing BIMI 891 assertion may factor in the lack of DKIM signing when deciding 892 whether to add a BIMI-Location header. 894 9.6. CGI scripts in Indicator payload 896 MTAs and MVAs should aggressively police Indicators to ensure they 897 are the Indicators they claim to be, are within appropriate size 898 limits, and pass other sanity checks. Additionally, MTAs might cache 899 good Indicators and serve them directly to their MUAs, which would in 900 practice bypass any malicious dynamic payload set to trigger against 901 an end user but not an MTA. 903 9.7. Metadata in Indicators 905 Domain Owners should be careful to strip any metadata out of 906 published Indicators that they don't want to expose or which might 907 bloat file size. MTAs and MVAs might wish to inspect and remove such 908 data from Indicators before exposing them to end users. 910 10. IANA Considerations 912 IANA will need to reserve two new entries for the "Permanent Message 913 Header Field Names" registry and create a registry for support file 914 formats for BIMI. 916 10.1. Permanent Header Field Updates 918 IANA will need to reserve two new entries to the "Permanent Message 919 Header Field Names" registry. 921 Header field name: BIMI-Selector 923 Applicable protocol: mail 925 Status: standard 927 Author/Change controller: IETF 929 Specification document: This one 931 Header field name: BIMI-Location 933 Applicable protocol: mail 935 Status: standard 937 Author/Change controller: IETF 939 Specification document: This one 941 10.2. Registry for Support BIMI Formats 943 Names of support file types supported by BIMI must be registered by 944 IANA. 946 New entries are assigned only for values that have been documented in 947 a published RFC that has had IETF Review, per [IANA-CONSIDERATIONS]. 948 Each method must register a name, the file extension, the 949 specification that defines it, and a description. 951 10.3. Other IANA needs 953 NOTE TO WORKING GROUP: The registry for BIMI tags needs to be 954 properly set up, as does the registry for validation actions. 956 11. References 958 11.1. Normative References 960 [ABNF] Overell, Crocker,., "Augmented BNF for Syntax 961 Specifications: ABNF", January 2008, 962 . 964 [Authentication-Results] 965 Kucherawy, M, ., "Message Header Field for Indicating 966 Message Authentication Status", August 2015, 967 . 969 [DKIM] Kucherawy, Ed, Crocker,., "DomainKeys Identified Mail 970 (DKIM) Signatures", September 2011, 971 . 973 [DMARC] Zwicky, Ed, Kucherawy,., "Domain-based Message 974 Authentication, Reporting, and Conformance (DMARC)", March 975 2015, . 977 [DNS] Mockapetris, P, ., "Domain names - implementation and 978 specification", November 1987, 979 . 981 [EMAIL-ARCH] 982 Crocker, D, ., "Internet Mail Architecture", July 2009, 983 . 985 [KEYWORDS] 986 Bradner, S, ., "Key words for use in RFCs to Indicate 987 Requirement Levels", March 1997, 988 . 990 [SMTP] Klensin, J, ., "Simple Mail Transfer Protocol", October 991 2008, . 993 [SPF] Kitterman, S, ., "Sender Policy Framework (SPF) for 994 Authorizing Use of Domains in Email, Version 1", April 995 2014, . 997 [URI] Masinter, Berners-Lee,., "Uniform Resource Identifier 998 (URI): Generic Syntax", January 2005, 999 . 1001 11.2. URIs 1003 [1] https://tools.ietf.org/html/rfc6376#section-1 1005 [2] https://tools.ietf.org/html/rfc7208#section-3.3 1007 [3] https://tools.ietf.org/html/rfc6376#section-3.1 1009 Appendix A. Example Selector Discovery (INFORMATIVE) 1011 This section shows several examples of how a receiving MTA should 1012 determine which Assertion Record to use depending on the BIMI- 1013 Selector header. 1015 A.1. No BIMI-Selector Header 1017 The domain example.com does not send with a BIMI-Selector header. 1019 From: sender@example.com 1021 The MTA would lookup default._bimi.example.com for the BIMI DNS 1022 record. 1024 A.2. With BIMI-Selector Header 1026 The domain example.com sends with a BIMI-Selector header: 1028 From: sender@example.com 1029 BIMI-Selector: v=BIMI1; s=selector; 1031 The MTA would lookup selector._bimi.example.com. 1033 A.3. Without BIMI-Selector Header on a subdomain 1035 The domain foo.example.com sends without a BIMI-Selector header: 1037 From: sender@foo.example.com 1039 The MTA would lookup default._bimi.foo.example.com for the BIMI DNS 1040 record. If it did not exist, it would lookup 1041 default._bimi.example.com. 1043 A.4. With BIMI-Selector Header on a subdomain 1045 The domain foo.example.com sends without a BIMI-Selector header: 1047 From: sender@foo.example.com 1048 BIMI-Selector: v=BIMI1; s=selector; 1050 The MTA would lookup selector._bimi.foo.example.com for the BIMI DNS 1051 record. If it did not exist, it would fall back to the lookup 1052 default._bimi.example.com. 1054 A.5. Invalid BIMI-Selector Header 1056 The domain example.com sends with a BIMI-Selector header, but does 1057 not include the required field 'v=': 1059 From: sender@example.com 1060 BIMI-Selector: s=selector; 1062 The MTA would ignore this header, and lookup 1063 default._bimi.example.com. 1065 Appendix B. Example Authentication-Results entry (INFORMATIONAL) 1067 This section shows example Authentication-Results stamps based on 1068 different BIMI lookup statuses. 1070 B.1. Successful BIMI lookup 1072 From: sender@example.com 1073 BIMI-Selector: v=BIMI1; s=selector; 1074 Authentication-Results: bimi=pass header.d=example.com selector=selector; 1076 B.2. No BIMI record 1078 From: sender@sub.example.com 1079 Authentication-Results: bimi=none; 1081 In this example, sub.example.com does not have a BIMI record at 1082 default._bimi.sub.example.com, nor does default._bimi.example.com 1084 B.3. Subdomain has no default record, but organizational domain does 1086 From: sender@sub.example.com 1087 Authentication-Results: bimi=pass header.d=example.com selector=default; 1088 B.4. Subdomain has no record for selector, but organization domain has 1089 a default 1091 From: sender@sub.example.com 1092 BIMI-Selector: v=BIMI1; s=selector; 1093 Authentication-Results: bimi=pass header.d=example.com selector=default; 1095 In this example, the sender specified a DNS record at 1096 selector._bimi.sub.example.com but it did not exist. The fallback is 1097 to use default._bimi.example.com, not selector._bimi.example.com even 1098 if that record exists. 1100 Appendix C. Example BIMI-Location Construction (INFORMATIONAL) 1102 This section shows how an example MTA might evaluate an incoming 1103 email for BIMI participation, and how it could share that 1104 determination with its MUA(s). 1106 C.1. MTA Receives an email 1108 The MTA receives the following DKIM signed message: 1110 DKIM-Signature: v=1; s=myExample; d=example.com; h=From;BIMI-Selector;Date;bh=...;b=... 1111 From: sender@example.com 1112 BIMI-Selector: v=BIMI1; s=brand; 1113 BIMI-Location: image.example.com/bimi/logo/example-bimi.svg 1114 Subject: Hi, this is a message from the good folks at Example Learning 1116 C.2. MTA does its authentication checks 1118 The receiving MTA receives the message and performs an SPF 1119 verification (which fails), a DKIM verification (which passes), and a 1120 DMARC verification (which passes). The domain is verified and has 1121 good reputation. The Receiver proceeds to perform a BIMI lookup. 1123 C.3. MTA performs BIMI Assertion 1125 The MTA sees that the message has a BIMI-Selector header, and it is 1126 covered by the DKIM-Signature, and the DKIM-Signature that passed 1127 DKIM is the one that covers the BIMI-Selector header. The MTA sees 1128 the header validates and contains 'v=BIMI1', and 's=brand'. It 1129 performs a DNS query for brand._bimi.example.com and retrieves: 1131 brand._bimi.example.com IN TXT "v=BIMI1; l=https://image.example.com/bimi/logo/" 1133 The MTA verifies the syntax of the BIMI DNS record, and it, too 1134 passes. 1136 C.4. MTA appends to Authentication-Results 1138 The MTA computes and affixes the results of the BIMI to the 1139 Authentication-Results header: 1141 Authentication-Results: spf=fail smtp.mailfrom=example.com; 1142 dkim=pass (signature was verified) header.d=example.com; 1143 dmarc=pass header.from=example.com; 1144 bimi=pass header.d=example.com selector=brand; 1146 C.5. MTA Constructs BIMI-Location header 1148 The MTA knows it has cached the indicator already, and wishes to use 1149 this cached indicator instead of a direct reference to the l= tag. 1151 Finally, the MTA removes the existing BIMI-Location header, and 1152 stamps the new one: 1154 BIMI-Location: v=BIMI1; l=https://cache.mta.example/bimi/logo/bimi-example.com-sel-brand.svg 1156 That the original sender signed a BIMI-Location header against this 1157 spec is irrelevant. It was used for DKIM validation and then thrown 1158 out by the MTA. 1160 The MTA then sets any relevant BIMI flags on the mail store when it 1161 deposits it. 1163 C.6. The MUA displays the indicator 1165 The mail is opened from the mail store in an MUA. The MUA checks to 1166 make sure the appropriate BIMI mail store flag has been set, so that 1167 it knows it can trust the BIMI-Location header. Finally, the MUA 1168 makes a simple determination of which image to show based upon the 1169 URI(s) in the BIMI-Location header. 1171 Authors' Addresses 1173 Seth Blank 1174 Valimail 1176 Email: seth@valimail.com 1178 Peter Goldstein 1179 Valimail 1181 Email: peter@valimail.com 1182 Thede Loder (editor) 1183 Skye Logicworks 1185 Email: thede@skyelogicworks.com 1187 Terry Zink (editor) 1189 Email: tzink@terryzink.com