< draft-blank-ietf-bimi-01.txt   draft-blank-ietf-bimi-02.txt >
Network Working Group S. Blank Network S. Blank
Internet-Draft P. Goldstein Internet-Draft P. Goldstein
Intended status: Experimental Valimail Intended status: Standards Track Valimail
Expires: 1 February 2021 T. Loder, Ed. Expires: 9 September 2021 T. Loder (ed)
Skye Logicworks, LLC Skye Logicworks LLC
T. Zink, Ed. T. Zink (ed)
Zink Magical Contraptions
M. Bradshaw, Ed. M. Bradshaw (ed)
Fastmail Fastmail
31 July 2020 8 March 2021
Brand Indicators for Message Identification (BIMI) Brand Indicators for Message Identification (BIMI)
draft-blank-ietf-bimi-01 draft-blank-ietf-bimi-02
Abstract Abstract
Brand Indicators for Message Identification (BIMI) permits Domain Brand Indicators for Message Identification (BIMI) permits Domain
Owners to coordinate with Mail User Agents (MUAs) to display brand- Owners to coordinate with Mail User Agents (MUAs) to display brand-
specific Indicators next to properly authenticated messages. There specific Indicators next to properly authenticated messages. There
are two aspects of BIMI coordination: a scalable mechanism for Domain are two aspects of BIMI coordination: a scalable mechanism for Domain
Owners to publish their desired Indicators, and a mechanism for Mail Owners to publish their desired Indicators, and a mechanism for Mail
Transfer Agents (MTAs) to verify the authenticity of the Indicator. Transfer Agents (MTAs) to verify the authenticity of the Indicator.
This document specifies how Domain Owners communicate their desired This document specifies how Domain Owners communicate their desired
skipping to change at line 45 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 February 2021. This Internet-Draft will expire on 5 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Requirements 2.1. High-Level Goals . . . . . . . . . . . . . . . . . . . . 7
3.1. High-Level Goals 2.2. Security . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Security 2.3. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Out of Scope 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 8
4. Terminology and Definitions 3.1. BIMI Assertion . . . . . . . . . . . . . . . . . . . . . 9
4.1. BIMI Assertion 3.2. Indicator . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Indicator 3.3. Mark Verifying Authority (MVA) . . . . . . . . . . . . . 9
4.3. Mark Verifying Authority (MVA) 3.4. BIMI Evidence Document . . . . . . . . . . . . . . . . . 9
4.4. BIMI Evidence Document 3.5. Verified Mark Certificate (VMC) . . . . . . . . . . . . . 9
4.5. Verified Mark Certificate (VMC) 3.6. Protocol Client . . . . . . . . . . . . . . . . . . . . . 10
4.6. Protocol Client 3.7. Verifying Protocol Client . . . . . . . . . . . . . . . . 10
4.7. Verifying Protocol Client 4. BIMI DNS Records . . . . . . . . . . . . . . . . . . . . . . 10
5. BIMI DNS Records 4.1. MUA Obligations . . . . . . . . . . . . . . . . . . . . . 11
5.1. MUA Obligations 4.2. Assertion Record Definition . . . . . . . . . . . . . . . 11
5.2. Assertion Record 4.2.1. Declination to Publish . . . . . . . . . . . . . . . 13
5.2.1. Declination to Publish 4.2.2. Supported Image Formats for l= tag . . . . . . . . . 13
5.2.2. Supported Image Formats for l= tag 4.3. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Selectors 5. BIMI Header Fields . . . . . . . . . . . . . . . . . . . . . 14
6. BIMI Header Fields 5.1. BIMI-Selector Header . . . . . . . . . . . . . . . . . . 14
6.1. BIMI-Selector Header 5.2. BIMI-Location Header . . . . . . . . . . . . . . . . . . 15
6.2. BIMI-Location Header 5.3. BIMI-Indicator Header . . . . . . . . . . . . . . . . . . 16
6.3. BIMI-Indicator Header 5.4. Header Signing . . . . . . . . . . . . . . . . . . . . . 16
6.4. Header Signing 6. Domain Owner Actions . . . . . . . . . . . . . . . . . . . . 17
7. Domain Owner Actions 6.1. Determine and Publish Indicator(s) for Use . . . . . . . 17
7.1. Determine and Publish Indicator(s) for Use 6.2. Publish Assertion Records . . . . . . . . . . . . . . . . 17
7.2. Publish Assertion Records 6.3. Manage multiple uses of the same Indicator(s) within a
7.3. Manage multiple uses of the same Indicator(s) within trust boundary . . . . . . . . . . . . . . . . . . . . . 17
a trust boundary 6.4. Set the headers on outgoing email as appropriate . . . . 17
7.4. Set the headers on outgoing email as appropriate 7. Receiver Actions . . . . . . . . . . . . . . . . . . . . . . 18
8. Receiver Actions 7.1. Authentication Requirements . . . . . . . . . . . . . . . 18
8.1. Authentication Requirements 7.2. Assertion Record Discovery . . . . . . . . . . . . . . . 19
8.2. Assertion Record Discovery 7.3. Indicator Discovery. . . . . . . . . . . . . . . . . . . 20
8.3. Indicator Discovery. 7.4. Indicator Discovery With Evidence. . . . . . . . . . . . 20
8.4. Indicator Discovery With Evidence. 7.5. Indicator Discovery Without Evidence. . . . . . . . . . . 21
8.5. Indicator Discovery Without Evidence. 7.6. Indicator Validation . . . . . . . . . . . . . . . . . . 21
8.6. Indicator Validation 7.7. Affix BIMI Status to Authentication Results Header
8.7. Affix BIMI Status to Authentication Results Header Field . . . . . . . . . . . . . . . . . . . . . . . . . 22
Field 7.8. Handle Existing BIMI-Location and BIMI-Indicator
8.8. Handle Existing BIMI-Location and BIMI-Indicator Headers . . . . . . . . . . . . . . . . . . . . . . . . 23
Headers 7.9. Construct BIMI-Location URI . . . . . . . . . . . . . . . 23
8.9. Construct BIMI-Location URI 7.10. Construct BIMI-Indicator header . . . . . . . . . . . . . 23
8.10. Construct BIMI-Indicator header 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations 8.1. Indirect Mail Flows . . . . . . . . . . . . . . . . . . . 24
9.1. Indirect Mail Flows 8.2. Lookalike Domains and Copycat Indicators . . . . . . . . 24
9.2. Lookalike Domains and Copycat Indicators 8.3. Large files and buffer overflows . . . . . . . . . . . . 24
9.3. Large files and buffer overflows 8.4. Slow DNS queries . . . . . . . . . . . . . . . . . . . . 24
9.4. Slow DNS queries 8.5. Unaligned Indicators and asserting domains . . . . . . . 25
9.5. Unaligned Indicators and asserting domains 8.6. Unsigned BIMI-Selector Header . . . . . . . . . . . . . . 25
9.6. Unsigned BIMI-Selector Header 8.7. CGI scripts in Indicator payload . . . . . . . . . . . . 25
9.7. CGI scripts in Indicator payload 8.8. Metadata in Indicators . . . . . . . . . . . . . . . . . 25
9.8. Metadata in Indicators 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations 9.1. Permanent Header Field Updates . . . . . . . . . . . . . 25
10.1. Permanent Header Field Updates 9.2. Registry for Supported BIMI Formats . . . . . . . . . . . 26
10.2. Registry for Supported BIMI Formats 9.3. Other IANA needs . . . . . . . . . . . . . . . . . . . . 26
10.3. Other IANA needs 10. Normative References . . . . . . . . . . . . . . . . . . . . 26
11. References 11. Informative References . . . . . . . . . . . . . . . . . . . 27
11.1. Normative References Appendix A. Example Selector Discovery (INFORMATIVE) . . . . . . 28
11.2. Informative References A.1. No BIMI-Selector Header . . . . . . . . . . . . . . . . . 28
Appendix A. Example Selector Discovery (INFORMATIVE) A.2. With BIMI-Selector Header . . . . . . . . . . . . . . . . 28
A.1. No BIMI-Selector Header A.3. Without BIMI-Selector Header on a subdomain . . . . . . . 28
A.2. With BIMI-Selector Header A.4. With BIMI-Selector Header on a subdomain . . . . . . . . 28
A.3. Without BIMI-Selector Header on a subdomain A.5. Invalid BIMI-Selector Header . . . . . . . . . . . . . . 29
A.4. With BIMI-Selector Header on a subdomain Appendix B. Example Authentication-Results entry
A.5. Invalid BIMI-Selector Header (INFORMATIONAL) . . . . . . . . . . . . . . . . . . . . . 29
Appendix B. Example Authentication-Results entry (INFORMATIONAL) B.1. Successful BIMI lookup . . . . . . . . . . . . . . . . . 29
B.1. Successful BIMI lookup B.2. No BIMI record . . . . . . . . . . . . . . . . . . . . . 29
B.2. No BIMI record B.3. Declination to Publish . . . . . . . . . . . . . . . . . 29
B.3. Subdomain has no default record, but organizational B.4. Subdomain has no default record, but organizational domain
domain does does . . . . . . . . . . . . . . . . . . . . . . . . . . 29
B.4. Subdomain has no record for selector, but B.5. Subdomain and orgznizational domain have no record for
organization domain has a default selector, but organization . . . . . . . . . . . . . . . 30
Appendix C. Example BIMI Headers Construction (INFORMATIONAL) B.6. Subdomain has no record for selector, but organization
C.1. MTA Receives an email domain does . . . . . . . . . . . . . . . . . . . . . . . 30
C.2. MTA does its authentication checks Appendix C. Example BIMI Headers Construction (INFORMATIONAL) . 30
C.3. MTA performs BIMI Assertion C.1. MTA Receives an email . . . . . . . . . . . . . . . . . . 30
C.4. MTA appends to Authentication-Results C.2. MTA does its authentication checks . . . . . . . . . . . 30
C.5. MTA Constructs BIMI-Location and BIMI-Indicator C.3. MTA performs BIMI Assertion . . . . . . . . . . . . . . . 31
headers C.4. MTA appends to Authentication-Results . . . . . . . . . . 31
C.6. The MUA displays the Indicator C.5. MTA Constructs BIMI-Location and BIMI-Indicator
C.7. Acknowledgements headers . . . . . . . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses C.6. The MUA displays the Indicator . . . . . . . . . . . . . 32
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source for this draft is maintained in GitHub at:
https://github.com/BLAHBLAHBLAH (https://github.com/BLAHBLAHBLAH)
This document defines Brand Indicators for Message Identification This document defines Brand Indicators for Message Identification
(BIMI), which enables Domain Owners to coordinate with Mail Box (BIMI), which enables Domain Owners to coordinate with Mail Box
Providers (MBPs), Mail Transfer Agents (MTAs), and Mail User Agents Providers (MBPs), Mail Transfer Agents (MTAs), and Mail User Agents
(MUAs) in the display of brand-specific Indicators next to properly (MUAs) in the display of brand-specific Indicators next to properly
authenticated messages. authenticated messages.
BIMI is designed to be open and to work at Internet scale. BIMI is BIMI is designed to be open and to work at Internet scale. BIMI is
intended to drive adoption of email authentication best practices by intended to drive adoption of email authentication best practices by
leveraging existing [DMARC] policies, the supporting authentication leveraging existing DMARC [RFC7489] policies, the supporting
methods [DKIM] and [SPF], and other associated standards such as authentication methods DKIM [RFC6376] and SPF [RFC7208], and other
[ARC]. associated standards such as ARC [RFC8617].
The approach taken by BIMI is heavily influenced by the approach The approach taken by BIMI is heavily influenced by the approach
taken in [DKIM], in that BIMI: taken in DKIM [RFC6376], in that BIMI:
* has no dependency on the deployment of any new Internet protocols * has no dependency on the deployment of any new Internet protocols
or services for Indicator registration or revocation; or services for indicator registration or revocation;
* makes no attempt to include encryption as part of the mechanism; * makes no attempt to include encryption as part of the mechanism;
* is compatible with the existing email infrastructure and * is compatible with the existing email infrastructure and
transparent to the fullest extent possible; transparent to the fullest extent possible;
* requires minimal new infrastructure; * requires minimal new infrastructure;
* can be implemented independently of clients in order to reduce * can be implemented independently of clients in order to reduce
deployment time; deployment time;
* can be deployed incrementally; and * can be deployed incrementally; and
* allows delegation of Indicator hosting to third parties. * allows delegation of indicator hosting to third parties.
To participate in BIMI, Domain Owners MUST have a strong [DMARC] To participate in BIMI, Domain Owners MUST have a strong [DMARC]
policy (quarantine or reject) on both the Organizational Domain, and policy (quarantine or reject) on both the Organizational Domain, and
the RFC5322.From Domain of the message. Quarantine policies MUST NOT the RFC5322.From Domain of the message. Quarantine policies MUST NOT
have a pct less than pct=100. have a pct less than pct=100.
This document defines how Domain Owners specify their desired This document defines how Domain Owners specify their desired
Indicators through the BIMI Assertion Record in DNS and how that indicators through the BIMI Assertion Record in DNS and how that
record is to be interpreted by MTAs and MUAs. This document does not record is to be interpreted by MTAs and MUAs. This document does not
cover how domains or Indicators are verified, how MUAs should display cover how domains or indicators are verified, how MUAs should display
the Indicators, or how other protocols (i.e. IMAP, JMAP) can be the indicators, or how other protocols (i.e. IMAP, JMAP) can be
extended to work with BIMI. Other documents may cover these topics. extended to work with BIMI. Other documents may cover these topics.
MUAs and Mail Box Providers (MBPs) are free to define their own MUAs and Mail Box Providers (MBPs) are free to define their own
policies for making use of BIMI data and for Indicator display as policies for making use of BIMI data and for indicator display as
they see fit. they see fit.
2. Overview 2. Overview
The Sender Policy Framework ([SPF]), DomainKeys Identified Mail The Sender Policy Framework (SPF [RFC7208]), DomainKeys Identified
([DKIM]), Domain-based Message Authentication, Reporting, and Mail (DKIM [RFC6376]), "Domain-based Message Authentication,
Conformance ([DMARC]), and Authenticated Received Chain ([ARC]) Reporting, and Conformance" (DMARC [RFC7489]), and Authenticated
provide mechanisms for domain-level authentication of email messages. Received Chain (ARC [RFC8617]) provide mechanisms for domain-level
They enable cooperating email senders and receivers to distinguish authentication of email messages. They enable cooperating email
messages that are authorized to use the domain name from those that senders and receivers to distinguish messages that are authorized to
are not. BIMI relies on these authentication protocols, but is not a use the domain name from those that are not. BIMI relies on these
new authentication protocol itself. authentication protocols, but is not a new authentication protocol
itself.
MUAs are increasingly incorporating graphical Indicators to indicate MUAs are increasingly incorporating graphical Indicators to indicate
the identity of the sender of a message. While a discussion of the the identity of the sender of a message. While a discussion of the
merits of doing this is beyond the scope of this document, at present merits of doing this is beyond the scope of this document, at present
there are no open standards for publishing and aiding discovery of there are no open standards for publishing and aiding discovery of
preferred Indicators or for tying display of them to authentic preferred Indicators or for tying display of them to authentic
messages only. messages only.
Because of the desire to have brand-specific Indicators available, Because of the desire to have brand-specific Indicators available,
some mail-receiving organizations have developed closed systems for some mail-receiving organizations have developed closed systems for
obtaining and displaying Brand Indicators for select domains. While obtaining and displaying Brand Indicators for select domains. While
this has enabled these mail-receiving organizations to display brand this has enabled these mail-receiving organizations to display brand
Indicators for a limited subset of messages, this closed approach has Indicators for a limited subset of messages, this closed approach has
a number of downsides: a number of downsides:
* It puts a significant burden on each mail-receiving organization, 1. It puts a significant burden on each mail-receiving organization,
because they must identify and manage a large database of Brand because they must identify and manage a large database of Brand
Indicators. Indicators.
* Scalability is challenging for closed systems that attempt to 2. Scalability is challenging for closed systems that attempt to
capture and maintain complete sets of data across the whole of the capture and maintain complete sets of data across the whole of
Internet. the Internet.
* A lack of uniformity across different mail-receiving organizations 3. A lack of uniformity across different mail-receiving
- each organization will have its own Indicator set, which may or organizations - each organization will have its own Indicator
may not agree with those maintained by other organizations for any set, which may or may not agree with those maintained by other
given domain. organizations for any given domain.
* Domain Owners have limited ability to influence the Brand 4. Domain Owners have limited ability to influence the Brand
Indicator for the domain(s) they own, and any ability they do have Indicator for the domain(s) they own, and any ability they do
is likely to be dependent upon direct coordination with each of have is likely to be dependent upon direct coordination with each
many mail-receiving organizations. of many mail-receiving organizations.
* Many Domain Owners have no ability to participate whatsoever as 5. Many Domain Owners have no ability to participate whatsoever as
they do not have the appropriate relationships to coordinate with they do not have the appropriate relationships to coordinate with
mail-receiving organizations. mail-receiving organizations.
* MUAs that are not associated with a particular mail-receiving 6. MUAs that are not associated with a particular mail-receiving
organization are likely to be disadvantaged, because they are organization are likely to be disadvantaged, because they are
unlikely to receive Indicators in a standardized manner or unlikely to receive Indicators in a standardized manner or
optimized for their user interfaces. optimized for their user interfaces.
This shows the need for a standardized mechanism by which Domain This shows the need for a standardized mechanism by which Domain
Owners interested in ensuring that their Indicators are displayed Owners interested in ensuring that their Indicators are displayed
correctly and appropriately can publish and distribute Brand correctly and appropriately can publish and distribute Brand
Indicators for use by any participating MUA. Indicators for use by any participating MUA.
BIMI removes the substantial burden of curating and maintaining an BIMI removes the substantial burden of curating and maintaining an
Indicator database from MUAs and MBPs, and allows each domain owner Indicator database from MUAs and MBPs, and allows each domain owner
to manage their own Indicators. As an additional benefit, mail- to manage their own Indicators. As an additional benefit, mail-
originating organizations are incentivized to authenticate their originating organizations are incentivized to authenticate their
email as doing so will enable them to influence how email and email as doing so will enable them to influence how email and
Indicators from the organization are displayed. Indicators from the organization are displayed.
The structure of BIMI is as follows: The structure of BIMI is as follows:
* Domain Owners: Publish their preferred Brand Indicators via the 1. Domain Owners:
[DNS].
* Senders: Ensure mail is properly authenticated, and has a * Fully implement the DMARC [RFC7489] mechanism, to include:
sufficiently strict [DMARC] policy.
* MTA: - Creating and publishing in DNS [RFC1035] a DMARC [RFC7489]
policy record that meets the following criteria:
- Confirm authenticity of the message using [DMARC] and whatever o The policy record MUST express either a Requested Mail
other authentication mechanisms they wish to apply. Receiver policy of "quarantine" with an effective
percentage of 100%, or a Requested Mail Receiver policy
of "reject" (with any percentage value).
- Check for a corresponding BIMI record, obtaining references to o Is a subdomain policy is published it MUST NOT be "none"
the Indicator media and optional substantiation of Indicator
ownership rights
- If both the message is authentic and the Indicator is deemed o Be published for the Organizational Domain, and any
acceptable, the receiver adds a header to the message which can subdomains thereof
be used by the MUA to obtain the Domain Owner's preferred Brand
Indicator.
* MUA: retrieves and displays the Brand Indicator as appropriate - Deploying authentication technologies to ensure Identifier
based on its policy and user interface. Alignment
* Publish their preferred Brand Indicators via the DNS
[RFC1035].
2. Senders: Ensure mail is properly authenticated, and has a
sufficiently strict DMARC [RFC7489] policy.
3. MTAs and MBPs:
* Confirm authenticity of the message using DMARC [RFC7489] and
whatever other authentication mechanisms they wish to apply.
* Check for a corresponding BIMI record, obtaining references to
the indicator media and optional substantiation of indicator
ownership rights
* If both the message is authentic and the logo is deemed
acceptable, the receiver adds a header to the message which
can be used by the MUA to obtain the Domain Owner's preferred
brand indicator.
4. MUA: retrieves and displays the brand indicator as appropriate
based on its policy and user interface.
The purpose of this structure is to reduce operational complexity at The purpose of this structure is to reduce operational complexity at
each step. It is also to consolidate validation and Indicator each step. It is also to consolidate validation and Indicator
selection operations into the MTA, so that Domain Owners need only selection operations into the MTA, so that Domain Owners need only
publish a few simple records and MUAs only need simple display logic. publish a few simple records and MUAs only need simple display logic.
It is expected that MBPs implementing BIMI will do so in both their It is expected that MBPs implementing BIMI will do so in both their
MTAs and MUAs. MTAs and MUAs.
3. Requirements #Requirements {#requirements}
Specification of BIMI in this document is guided by the following Specification of BIMI in this document is guided by the following
high-level goals, security dependencies, detailed requirements, and high-level goals, security dependencies, detailed requirements, and
items that are documented as out of scope. items that are documented as out of scope.
An overview of the security challenges and design decisions is An overview of the security challenges and design decisions is
documented at [BIMI-OVERVIEW]. documented at [BIMI-OVERVIEW].
3.1. High-Level Goals 2.1. High-Level Goals
BIMI has the following high-level goals: BIMI has the following high-level goals:
* Allow Domain Owners to suggest appropriate Indicators for display * Allow Domain Owners to suggest appropriate Indicators for display
with authenticated messages originating from their domains. with authenticated messages originating from their domains.
* Enable the authors of MUAs to display meaningful Indicators * Enable the authors of MUAs to display meaningful Indicators
associated with the Domain Owner to recipients of authenticated associated with the Domain Owner to recipients of authenticated
email. email.
* Provide mechanisms to prevent attempts by malicious Domain Owners * Provide mechanisms to prevent attempts by malicious Domain Owners
to fraudulently represent messages from their domains as to fraudulently represent messages from their domains as
originating with other entities. originating with other entities.
* Work at Internet Scale. * Work at Internet Scale.
* Encourage the adoption of Email Authentication Best Practices. * Encourage the adoption of Email Authentication Best Practices.
3.2. Security 2.2. Security
Brand Indicators are a potential vector for abuse. BIMI creates a Brand Indicators are a potential vector for abuse. BIMI creates a
relationship between sending organization and Mail Receiver so that relationship between sending organization and Mail Receiver so that
the receiver can display appropriately designated Indicators if the the receiver can display appropriately designated Indicators if the
sending domain is verified and has meaningful reputation with the sending domain is verified and has meaningful reputation with the
receiver. Without verification and reputation, there is no way to receiver. Without verification and reputation, there is no way to
prevent a bad actor exxample.com from using example.com's Brand prevent a bad actor exxample.com from using example.com's Brand
Indicators and behaving maliciously. This document does not cover Indicators and behaving maliciously. This document does not cover
the different verification and reputation mechanisms available, but the different verification and reputation mechanisms available, but
BIMI relies upon them to be in deployed in order to control abuse. BIMI relies upon them to be in deployed in order to control abuse.
3.3. Out of Scope 2.3. Out of Scope
Several topics and issues are specifically out of scope for the Several topics and issues are specifically out of scope for the
initial version of this work. These include the following: initial version of this work. These include the following:
* Publishing policy other than via the DNS. * Publishing policy other than via the DNS.
* Specific requirements for Indicator display on MUAs. * Specific requirements for Indicator display on MUAs.
* The explicit mechanisms used by Verifying Protocol Clients - this * The explicit mechanisms used by Verifying Protocol Clients - this
will be deferred to a later document. will be deferred to a later document.
4. Terminology and Definitions 3. Terminology and Definitions
This section defines terms used in the rest of the document. This section defines terms used in the rest of the document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in BCP 14
(https://tools.ietf.org/html/bcp14) [RFC2119] [RFC8174] when, and
only when, they appear in all capitals, as shown here.
Readers are encouraged to be familiar with the contents of [EMAIL- Readers are encouraged to be familiar with the contents of [RFC5598].
ARCH]. In particular, that document defines various roles in the In particular, that document defines various roles in the messaging
messaging infrastructure that can appear the same or separate in infrastructure that can appear the same or separate in various
various contexts. For example, a Domain Owner could, via the contexts. For example, a Domain Owner could, via the messaging
messaging mechanisms on which BIMI is based, delegate reponsibility mechanisms on which BIMI is based, delegate reponsibility for
for providing preferred Brand Indicators to a third party with providing preferred brand indicators to a third party with another
another role. This document does not address the distinctions among role. This document does not address the distinctions among such
such roles; the reader is encouraged to become familiar with that roles; the reader is encouraged to become familiar with that material
material before continuing. before continuing.
Syntax descriptions use Augmented BNF [ABNF]. Syntax descriptions use Augmented BNF (ABNF) [RFC5234].
"Author Domain", "Domain Owner", "Organizational Domain", and "Mail "Author Domain", "Domain Owner", "Organizational Domain", and "Mail
Receiver" are imported from [DMARC] Section 3. Receiver" are imported from DMARC [RFC7489] Section 3.
4.1. BIMI Assertion 3.1. BIMI Assertion
The mechanism through which a Protocol Client verifies the BIMI The mechanism through which a Protocol Client verifies the BIMI
Assertion Record and constructs the URI(s) to the requested Assertion Record and constructs the URI(s) to the requested
Indicator(s) to be placed in the BIMI-Location header. Indicator(s) to be placed in the BIMI-Location header.
4.2. Indicator 3.2. Indicator
The icon, logo, image, mark, or other graphical representation of the The icon, logo, image, mark, or other graphical representation of the
brand. The Indicator is defined in a common image format with brand. The Indicator is defined in a common image format with
restrictions detailed in the Assertion Record definition restrictions detailed in the Assertion Record Definition (#assertion-
(Section 5.2). record-definition).
4.3. Mark Verifying Authority (MVA) 3.3. Mark Verifying Authority (MVA)
An entity or organization that can provide evidence of verification An entity or organization that can provide evidence of verification
of Indicators asserted by a Domain Owner to Verifying Protocol of Indicators asserted by a Domain Owner to Verifying Protocol
Clients. The MVA may choose to uphold and confirm the meeting of Clients. The MVA may choose to uphold and confirm the meeting of
certain Indicator standards (ie. size, trademark, content, etc). certain Indicator standards (ie. size, trademark, content, etc).
4.4. BIMI Evidence Document 3.4. BIMI Evidence Document
A document published by a Mark Verifying Authority to assert evicence A document published by a Mark Verifying Authority to assert evicence
of verification. These are defined in a separate document. of verification. These are defined in a separate document.
4.5. Verified Mark Certificate (VMC) 3.5. Verified Mark Certificate (VMC)
A certificate issued by a Certificate Authority in accordance with A certificate issued by a Certificate Authority in accordance with
the Verified Mark Certificate Guidelines. These guidelines are the Verified Mark Certificate Guidelines. These guidelines are
defined in a separate document. defined in a separate document.
A Verified Mark Certificate is one example of a BIMI Evidence A Verified Mark Certificate is one example of a BIMI Evidence
Document. Document.
4.6. Protocol Client 3.6. Protocol Client
An entity designed to obtain and correctly interpret the records An entity designed to obtain and correctly interpret the records
defined in this specification for the purpose of discovering and defined in this specification for the purpose of discovering and
fetching published Indicators. fetching published Indicators.
4.7. Verifying Protocol Client 3.7. Verifying Protocol Client
A Protocol Client that uses optional capabilities to obtain and A Protocol Client that uses optional capabilities to obtain and
evaluate evidence concerning the Domain Owner's rights to use the evaluate evidence concerning the Domain Owner's rights to use the
published Indicators. published Indicators.
5. BIMI DNS Records 4. BIMI DNS Records
Domain owners publish BIMI policies by adding BIMI Assertion Records Domain owners publish BIMI policies by adding BIMI Assertion Records
in the DNS as TXT records. in the DNS as TXT records.
Published policies are interpreted and applied by Protocol Clients. Published policies are interpreted and applied by Protocol Clients.
A Domain Owner signals intended BIMI participation for one or more of A Domain Owner signals intended BIMI participation for one or more of
its domains by publishing an Assertion Record in a subdomain under its domains by publishing an Assertion Record in a subdomain under
it. In doing so, Domain Owners make specific requests of MUAs it. In doing so, Domain Owners make specific requests of MUAs
regarding the preferred set of Indicators to be displayed with regarding the preferred set of Indicators to be displayed with
messages that are confirmed to be authorized to appear from the messages that are confirmed to be authorized to appear from the
skipping to change at line 441 skipping to change at page 10, line 44
BIMI's use of the DNS is driven in part by BIMI's use of domain names BIMI's use of the DNS is driven in part by BIMI's use of domain names
as the basis of sender identity and message authentication. Use of as the basis of sender identity and message authentication. Use of
the DNS as the policy publication service also has the benefit of the DNS as the policy publication service also has the benefit of
reusing an extremely well-established operations, administration, and reusing an extremely well-established operations, administration, and
management infrastructure, rather than creating a new one. management infrastructure, rather than creating a new one.
BIMI's policy payload is intentionally only published via a DNS BIMI's policy payload is intentionally only published via a DNS
record and not via one or more email headers. This serves three record and not via one or more email headers. This serves three
purposes: purposes:
* There is one and only one mechanism for both simple and complex 1. There is one and only one mechanism for both simple and complex
policies to be published. policies to be published.
* Operational complexity is reduced. MTAs only need to check a 2. Operational complexity is reduced. MTAs only need to check a
single record in a consistent manner to discover and enforce single record in a consistent manner to discover and enforce
policy. policy.
* Indicators SHOULD be verified and cached in advance, so that 3. Indicators SHOULD be verified and cached in advance, so that
malicious headers cannot be used as an attack vector. malicious headers cannot be used as an attack vector.
Per [DNS], a TXT record can comprise several "character-string" Per DNS [RFC1035], a TXT record can comprise several "character-
objects. BIMI TXT records with multiple strings must be treated in string" objects. BIMI TXT records with multiple strings must be
an identical manner to SPF Section 3.3 (https://tools.ietf.org/html/ treated in an identical manner to SPF Section 3.3
rfc7208#section-3.3). (https://tools.ietf.org/html/rfc7208#section-3.3).
5.1. MUA Obligations 4.1. MUA Obligations
MUAs implementing the BIMI mechanism SHOULD make a best-effort MUAs implementing the BIMI mechanism SHOULD make a best-effort
attempt to adhere to the Domain Owner's published BIMI policy. attempt to adhere to the Domain Owner's published BIMI policy.
However, MUAs have final control over the user interface published to However, MUAs have final control over the user interface published to
their end users, and MAY use alternate Indicators than those their end users, and MAY use alternate Indicators than those
specified in the BIMI assertion record or no Indicator at all. specified in the BIMI assertion record or no Indicator at all.
5.2. Assertion Record 4.2. Assertion Record Definition
All Domain Owner BIMI preferences are expressed in DNS TXT records All Domain Owner BIMI preferences are expressed in DNS TXT records
published in subdomains named "_bimi". Multiple sets of preferences published in subdomains named "_bimi". Multiple sets of preferences
can be associated with a single RFC5322.From domain. To distinguish can be associated with a single RFC5322.From domain. To distinguish
between these different preferences, BIMI defines and uses selectors. between these different preferences, BIMI defines and uses
Senders declare which selector to use for a given message by [selectors]{#selectors}. Senders declare which selector to use for a
specifying the selector in an optional BIMI-Selector header given message by specifying the selector in an optional BIMI-Selector
(Section 6.1). header (#bimi-selector).
For example, the Domain Owner of "example.com" would post BIMI policy For example, the Domain Owner of "example.com" would post BIMI policy
in a TXT record at "default._bimi.example.com". Similarly, a Mail in a TXT record at "default._bimi.example.com". Similarly, a Mail
Receiver wishing to query for BIMI policy regarding mail with an Receiver wishing to query for BIMI policy regarding mail with an
RFC5322.From Author Domain of "example.com" and a selector "default" RFC5322.From Author Domain of "example.com" and a selector "default"
(the default) would query the TXT record located at the subdomain of (the default) would query the TXT record located at the subdomain of
"default._bimi.example.com". The DNS-based BIMI policy record is "default._bimi.example.com". The DNS-based BIMI policy record is
referred to as the "BIMI Assertion Record" or "Assertion Record". referred to as the "BIMI Assertion Record" or "Assertion Record".
BIMI Assertion Records follow the extensible "tag-value" syntax for BIMI Assertion Records follow the extensible "tag-value" syntax for
DNS-based key records as defined in [DKIM]. DNS-based key records as defined in DKIM [RFC6376].
Assertion Records are defined precisely. Mail receivers MUST NOT Assertion Records are defined precisely. Mail receivers MUST NOT
attempt to fix syntactical or capitalization errors. If a required attempt to fix syntactical or capitalization errors. If a required
tag is missing, or its value not well-formed, it is an error. tag is missing, or its value not well-formed, it is an error.
This section creates a registry for known BIMI tags and registers the This section creates a registry for known BIMI tags and registers the
initial set defined in this document. Only tags defined in this initial set defined in this document. Only tags defined in this
document or in later extensions, and thus added to the registry, are document or in later extensions, and thus added to the registry, are
to be processed; unknown tags MUST be ignored. to be processed; unknown tags MUST be ignored.
skipping to change at line 539 skipping to change at page 12, line 44
l= location (URI; REQUIRED). The value of this tag is either empty l= location (URI; REQUIRED). The value of this tag is either empty
indicating declination to publish, or a single URI representing the indicating declination to publish, or a single URI representing the
location of a Brand Indicator file. The only supported transport is location of a Brand Indicator file. The only supported transport is
HTTPS. HTTPS.
ABNF: ABNF:
bimi-location = %x6c *WSP "=" bimi-uri bimi-location = %x6c *WSP "=" bimi-uri
Therefore, the formal definition of the BIMI Assertion Record, using Therefore, the formal definition of the BIMI Assertion Record, using
[ABNF], is as follows: ABNF [RFC5234], is as follows:
bimi-sep = *WSP %x3b *WSP bimi-sep = *WSP %x3b *WSP
bimi-record = bimi-version (bimi-sep bimi-location) (bimi-sep bimi-evidence-location) \[bimi-sep\] bimi-record = bimi-version (bimi-sep bimi-location) (bimi-sep bimi-evidence-location) \[bimi-sep\]
; components other than bimi-version may appear in any order ; components other than bimi-version may appear in any order
5.2.1. Declination to Publish 4.2.1. Declination to Publish
If both the "l=" and "a=" tags are empty, it is an explicit refusal If both the "l=" and "a=" tags are empty, it is an explicit refusal
to participate in BIMI. This is distinct from not publishing a BIMI to participate in BIMI. This is distinct from not publishing a BIMI
record. For example, an empty BIMI record enables a Domain Owner to record. For example, an empty BIMI record enables a Domain Owner to
decline BIMI participation for a subdomain when its organizational decline BIMI participation for a subdomain when its organizational
domain has default Indicators available. Furthermore, messages sent domain has default Indicators available. Furthermore, messages sent
using a selector that has declined to publish will not show an using a selector that has declined to publish will not show an
Indicator while messages with other selectors would display normally. Indicator while messages with other selectors would display normally.
An explicit declination to publish looks like: An explicit declination to publish looks like:
v=BIMI1; l=; a=; v=BIMI1; l=; a=;
5.2.2. Supported Image Formats for l= tag 4.2.2. Supported Image Formats for l= tag
Any format in the BIMI-formats IANA registry are acceptable targets Any format in the BIMI-formats IANA registry are acceptable targets
for the l= tag. If an l= tag URI ends with any other image format for the l= tag. If an l= tag URI ends with any other image format
suffix, or if the document retrievable from the location(s) in the l= suffix, or if the document retrievable from the location(s) in the l=
tag are of any other format, the evaluation of the record MUST be tag are of any other format, the evaluation of the record MUST be
treated as a permanent error. treated as a permanent error.
As of the publishing of this document, only SVG and SVGZ, as defined As of the publishing of this document, only SVG and SVGZ, as defined
in RFC6170 section 5.2 (https://tools.ietf.org/html/rfc6170#section- in RFC6170 section 5.2 (https://tools.ietf.org/html/rfc6170#section-
5.2) is acceptable in the l= tag. Further restrictions apply to the 5.2) is acceptable in the l= tag. Further restrictions apply to the
SVG; these are documented elsewhere. SVG; these are documented elsewhere.
5.3. Selectors 4.3. Selectors
To support publishing and display of more than one distinct Brand To support publishing and display of more than one distinct Brand
Indicator per domain, the brand Indicator namespace is subdivided for Indicator per domain, the brand Indicator namespace is subdivided for
publishing of multiple Assertion Records using "selectors". publishing of multiple Assertion Records using "selectors".
Selectors allow the Domain Owner to choose the brand Indicator, for Selectors allow the Domain Owner to choose the brand Indicator, for
example, by type of recipient, by message source, or by other example, by type of recipient, by message source, or by other
considerations like seasonal branding. BIMI selectors are modeled considerations like seasonal branding. BIMI selectors are modeled
after DKIM selectors (https://tools.ietf.org/html/rfc6376#section- after DKIM selectors (https://tools.ietf.org/html/rfc6376#section-
3.1). 3.1).
The selector "default" is the default Assertion Record. Domain The selector "default" is the default Assertion Record. Domain
Owners can specify which other selector to use on a per-message basis Owners can specify which other selector to use on a per-message basis
by utilizing the BIMI-Selector Header (Section 6.1). by utilizing the BIMI-Selector Header (#bimi-selector).
Periods are allowed in selectors and are component separators. When Periods are allowed in selectors and are component separators. When
BIMI Assertion Records are retrieved from the DNS, periods in BIMI Assertion Records are retrieved from the DNS, periods in
selectors define DNS label boundaries in a manner similar to the selectors define DNS label boundaries in a manner similar to the
conventional use in domain names. In a DNS implementation, this can conventional use in domain names. In a DNS implementation, this can
be used to allow delegation of a portion of the selector namespace. be used to allow delegation of a portion of the selector namespace.
ABNF: ABNF:
selector = sub-domain *( "." sub-domain ) selector = sub-domain *( "." sub-domain )
skipping to change at line 609 skipping to change at page 14, line 19
; from [SMTP] Domain, ; from [SMTP] Domain,
; excluding address-literal ; excluding address-literal
The number of selectors for each domain is determined by the Domain The number of selectors for each domain is determined by the Domain
Owner. Many Domain Owners will be satisfied with just one selector, Owner. Many Domain Owners will be satisfied with just one selector,
whereas organizations with more complex branding requirements can whereas organizations with more complex branding requirements can
choose to manage disparate selectors. BIMI sets no maximum limit on choose to manage disparate selectors. BIMI sets no maximum limit on
the number of selectors. the number of selectors.
6. BIMI Header Fields 5. BIMI Header Fields
Once BIMI policies are published in DNS via Assertion Records, Domain Once BIMI policies are published in DNS via Assertion Records, Domain
Owners can provide additional guidance to Mail Receivers, and Mail Owners can provide additional guidance to Mail Receivers, and Mail
Receivers to their MUAs through the use of BIMI header fields. Receivers to their MUAs through the use of BIMI header fields.
BIMI header fields are case insensitive. If a required tag is BIMI header fields are case insensitive. If a required tag is
missing, it is an error. missing, it is an error.
6.1. BIMI-Selector Header 5.1. BIMI-Selector Header
BIMI DNS records are placed in <selector>._bimi.<domain>, and by BIMI DNS records are placed in <selector>._bimi.<domain>, and by
default they are placed in default._bimi.<domain>. That is, for default they are placed in default._bimi.<domain>. That is, for
example.com, the default Assertion Record is located in the DNS at example.com, the default Assertion Record is located in the DNS at
default._bimi.example.com. However, a Domain Owner may override the default._bimi.example.com. However, a Domain Owner may override the
use of the default selector and specify the use of an alternative use of the default selector and specify the use of an alternative
using the RFC5322-compliant header 'BIMI-Selector'. The BIMI- using the RFC5322-compliant header 'BIMI-Selector'. The BIMI-
Selector header consists of key value pairs: Selector header consists of key value pairs:
v= Version (plain-text; REQUIRED). The version of BIMI. It MUST v= Version (plain-text; REQUIRED). The version of BIMI. It MUST
skipping to change at line 650 skipping to change at page 15, line 14
ABNF: ABNF:
bimi-selector = "s" *WSP "=" *WSP selector bimi-selector = "s" *WSP "=" *WSP selector
And the formal definition of the BIMI Selector Header, using ABNF, is And the formal definition of the BIMI Selector Header, using ABNF, is
as follows: as follows:
bimi-selector-header = bimi-header-version bimi-sep bimi-selector \[bimi-sep\] bimi-selector-header = bimi-header-version bimi-sep bimi-selector \[bimi-sep\]
6.2. BIMI-Location Header 5.2. BIMI-Location Header
BIMI-Location is the header a Mail Receiver inserts that tells the BIMI-Location is the header a Mail Receiver inserts that tells the
MUA where to get the BIMI Indicator from. MUA where to get the BIMI Indicator from.
The syntax of the header is as follows: The syntax of the header is as follows:
v= Version (plain-text; REQUIRED). The version of BIMI. It MUST v= Version (plain-text; REQUIRED). The version of BIMI. It MUST
have the value of "BIMI1" for implementations compliant with this have the value of "BIMI1" for implementations compliant with this
version of BIMI. The value of this tag MUST match precisely; if it version of BIMI. The value of this tag MUST match precisely; if it
does not or it is absent, the entire header MUST be ignored. It MUST does not or it is absent, he entire header MUST be ignored. It MUST
be the first tag in the list. be the first tag in the list.
The ABNF for bimi-header-version is imported exactly from the [BIMI Selector Header](#bimi-selector). The ABNF for bimi-header-version is imported exactly from the
[BIMI Selector Header](#bimi-selector).
l: location of the BIMI Indicator (URI; OPTIONAL if a bimi-evidence- l: location of the BIMI Indicator (URI; OPTIONAL if a bimi-evidence-
location-header-uri is specified, otherwise REQUIRED.). Inserted by location-header-uri is specified, otherwise REQUIRED.). Inserted by
the MTA after performing the required checks and obtaining the the MTA after performing the required checks and obtaining the
applicable domain's published Assertion Record. The value of this applicable domain's published Assertion Record. The value of this
tag is a URI representing the location of the Brand Indicator file. tag is a URI representing the location of the Brand Indicator file.
HTTPS is the only supported transport. HTTPS is the only supported transport.
ABNF: ABNF:
skipping to change at line 686 skipping to change at page 16, line 4
a: location of the BIMI Evidence Document (URI; REQUIRED if the BIMI a: location of the BIMI Evidence Document (URI; REQUIRED if the BIMI
Evidence Document was verified). Inserted by the MTA after Evidence Document was verified). Inserted by the MTA after
performing the required checks and obtaining the applicable domain's performing the required checks and obtaining the applicable domain's
published Assertion Record. The value of this tag is a URI published Assertion Record. The value of this tag is a URI
representing the location of the BIMI Evidence Document. HTTPS is representing the location of the BIMI Evidence Document. HTTPS is
the only supported transport. the only supported transport.
ABNF: ABNF:
bimi-evidenced-location-header-uri = "a" *WSP "=" bimi-uri bimi-evidenced-location-header-uri = "a" *WSP "=" bimi-uri
And the formal definition of the BIMI Location Header, using ABNF, is And the formal definition of the BIMI Location Header, using ABNF, is
as follows: as follows:
bimi-location-header-location-only = bimi-location-header-uri bimi-location-header-location-only = bimi-location-header-uri
bimi-location-header-evidence-only = bimi-evidence-location-header-uri bimi-location-header-evidence-only = bimi-evidence-location-header-uri
bimi-location-header-both = bimi-location-header-uri bimi-evidence-location-header-uri bimi-location-header-both = bimi-location-header-uri bimi-evidence-location-header-uri
bimi-location-options = bimi-location-header-location-only / bimi-location-header-evidence-only / bimi-location-header-both bimi-location-options = bimi-location-header-location-only / bimi-location-header-evidence-only / bimi-location-header-both
bimi-location-header = bimi-header-version bimi-sep bimi-location-options \[bimi-sep\] bimi-location-header = bimi-header-version bimi-sep bimi-location-options \[bimi-sep\]
6.3. BIMI-Indicator Header 5.3. BIMI-Indicator Header
BIMI-Indicator is the header a Mail Receiver inserts to pass a BIMI-Indicator is the header a Mail Receiver inserts to pass a
verified Indicator to the MUA. verified Indicator to the MUA.
The header contains the SVG of the Indicator encoded as base64, and The header contains the SVG of the Indicator encoded as base64, and
is inserted by the MTA after performing the required checks and is inserted by the MTA after performing the required checks and
obtaining the applicable domain's published Assertion Record. The obtaining the applicable domain's published Assertion Record. The
contents of this tag MUST match the SVG Indicator content retrieved contents of this tag MUST match the SVG Indicator content retrieved
from the URI specified in the BIMI-Location header. If he Indicator from the URI specified in the BIMI-Location header. If he Indicator
was supplied as a gzipped SVGZ file then the MTA MUST uncompress the was supplied as a gzipped SVGZ file then the MTA MUST uncompress the
file before base64 encoding. file before base64 encoding.
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS) base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
[ [FWS] "=" [ [FWS] "=" ] ] [ [FWS] "=" [ [FWS] "=" ] ]
And the formal definition of the BIMI Indicator Header, using ABNF, And the formal definition of the BIMI Indicator Header, using ABNF,
is as follows: is as follows:
bimi-indicator-header = bimi-sep base64string \[bimi-sep\] bimi-indicator-header = bimi-sep base64string \[bimi-sep\]
6.4. Header Signing 5.4. Header Signing
If present, the BIMI-Selector header SHOULD be included in the DMARC- If present, the BIMI-Selector header SHOULD be included in the DMARC-
aligned DKIM signature used to confirm authenticity of the message. aligned DKIM signature used to confirm authenticity of the message.
If it is not included in the DMARC-compliant DKIM signature, the If it is not included in the DMARC-compliant DKIM signature, the
header SHOULD be ignored. header SHOULD be ignored.
Receivers MAY choose to apply additional methods to validate the Receivers MAY choose to apply additional methods to validate the
BIMI-Selector header, for example by evaluating a trusted [ARC] BIMI-Selector header, for example by evaluating a trusted [ARC]
chain. In this case the Receiver MAY choose to treat the message as chain. In this case the Receiver MAY choose to treat the message as
if the BIMI-Selector header was signed. if the BIMI-Selector header was signed.
The BIMI-Location and BIMI-Indicator headers MUST NOT be DKIM signed. The BIMI-Location and BIMI-Indicator headers MUST NOT be DKIM signed.
This header is untrusted by definition, and is only for use between This header is untrusted by definition, and is only for use between
an MTA and its MUAs, after DKIM has been validated by the MTA. an MTA and its MUAs, after DKIM has been validated by the MTA.
Therefore, signing this header is meaningless, and any messages with Therefore, signing this header is meaningless, and any messages with
it signed are either coming from malicious or misconfigured third it signed are either coming from malicious or misconfigured third
parties. parties.
7. Domain Owner Actions 6. Domain Owner Actions
This section includes a walk through of the actions a Domain Owner This section includes a walk through of the actions a Domain Owner
takes when setting up Assertion Records and sending email messages. takes when setting up Assertion Records and sending email messages.
7.1. Determine and Publish Indicator(s) for Use 6.1. Determine and Publish Indicator(s) for Use
Domain Owners should consider which Indicator file formats to choose Domain Owners should consider which Indicator file formats to choose
when setting up their BIMI Assertion Records. For a Sender, BIMI when setting up their BIMI Assertion Records. For a Sender, BIMI
provides control over which Indicators are eligible and can be chosen provides control over which Indicators are eligible and can be chosen
for display, but not the ultimate manner in which the MUA will for display, but not the ultimate manner in which the MUA will
display the Indicator. display the Indicator.
7.2. Publish Assertion Records 6.2. Publish Assertion Records
For each set of Indicators and domains, publish the appropriate For each set of Indicators and domains, publish the appropriate
Assertion Record as either "default" or a named selector as a DNS TXT Assertion Record as either "default" or a named selector as a DNS TXT
record within the appropriate "_bimi" namespace. record within the appropriate "_bimi" namespace.
7.3. Manage multiple uses of the same Indicator(s) within a trust boundary 6.3. Manage multiple uses of the same Indicator(s) within a trust
boundary
For Domain Owners with multiple domains that wish to share the same For Domain Owners with multiple domains that wish to share the same
set of Indicators within a trust boundary and only manage those set of Indicators within a trust boundary and only manage those
Indicators from a single DNS location, it is RECOMMENDED to use DNS Indicators from a single DNS location, it is RECOMMENDED to use DNS
CNAMEs. CNAMEs.
Using a CNAME here is functionally similar to the SPF redirect Using a CNAME here is functionally similar to the SPF redirect
modifier. Since BIMI does not require l= tags to be aligned to the modifier. Since BIMI does not require l= tags to be aligned to the
Author Domain, CNAMEs present a cleaner solution than extending the Author Domain, CNAMEs present a cleaner solution than extending the
protocol. protocol.
7.4. Set the headers on outgoing email as appropriate 6.4. Set the headers on outgoing email as appropriate
Once a default Assertion Record has been published for an Author Once a default Assertion Record has been published for an Author
Domain, all emails from this domain should display the appropriate Domain, all emails from this domain should display the appropriate
Indicator in participating MUAs. Indicator in participating MUAs.
If a non-default Indicator is desired, the BIMI-Selector header If a non-default Indicator is desired, the BIMI-Selector header
should be set appropriately. If for some reason this selector cannot should be set appropriately. If for some reason this selector cannot
be accessed by the Protocol Client, the fallback is the default be accessed by the Protocol Client, the fallback is the default
Assertion Record on the Organization domain. Assertion Record on the Organization domain.
The BIMI-Location header MUST NOT be set by email senders, and The BIMI-Location header MUST NOT be set by email senders, and
Protocol Clients MUST ignore it. Protocol Clients MUST ignore it.
8. Receiver Actions 7. Receiver Actions
This section includes a walk through of the actions a Protocol Client This section includes a walk through of the actions a Protocol Client
takes when evaluating an email message for BIMI Assertion. takes when evaluating an email message for BIMI Assertion.
8.1. Authentication Requirements 7.1. Authentication Requirements
Before applying BIMI processing for a message, a receiver MUST verify Before applying BIMI processing for a message, a receiver MUST verify
that the message passed the following BIMI authentication that the message passed the following BIMI authentication
requirements: requirements:
1. If more than 1 RFC5322.From header is present in the message, or 1. If more than 1 RFC5322.From header is present in the message, or
any RFC5322.From header contains more than 1 email address then any RFC5322.From header contains more than 1 email address then
BIMI processing MUST NOT be performed for this message. BIMI processing MUST NOT be performed for this message.
2. Start with the DNS domain found in the RFC5322.From header in the 2. Start with the DNS domain found in the RFC5322.From header in the
message. Define this DNS domain as the Author Domain. message. Define this DNS domain as the Author Domain.
3. Find the Organizational Domain for the Author Domain. Define 3. Find the Organizational Domain for the Author Domain. Define
this DNS domain as the Author Organizational Domain. If the this DNS domain as the Author Organizational Domain. If the
Author Domain is an Organizational Domain then this will be Author Domain is an Organizational Domain then this will be
identical to the Author Domain. identical to the Author Domain.
4. Evaluate the [DMARC] result for the Author Domain. Define the 4. Evaluate the DMARC [RFC7489] result for the Author Domain.
result as the BIMI DMARC Result. Define the result as the BIMI DMARC Result.
5. If the BIMI DMARC result is not 'pass', then the receiver MAY 5. If the BIMI DMARC result is not 'pass', then the receiver MAY
choose to apply additional authentication methods, for example by choose to apply additional authentication methods, for example by
evaluating a trusted [ARC] chain, a list of trusted forwarders, evaluating a trusted ARC [RFC8617] chain, a list of trusted
or by applying a local policy. In this case the Receiver MAY forwarders, or by applying a local policy. In this case the
choose to treat the message as if the BIMI DMARC Result was Receiver MAY choose to treat the message as if the BIMI DMARC
'pass'. Result was 'pass'.
6. If the [DMARC] result for the Author Domain is not 'pass', and 6. If the DMARC [RFC7489] result for the Author Domain is not
the message could not be authenticated by any additional 'pass', and the message could not be authenticated by any
authentication method, then BIMI processing MUST NOT be performed additional authentication method, then BIMI processing MUST NOT
for this message. be performed for this message.
7. If the [DMARC] policy for the Author Domain or Author 7. If the DMARC [RFC7489] policy for the Author Domain or Author
Organizational Domain is p=none then BIMI processing MUST NOT be Organizational Domain is p=none then BIMI processing MUST NOT be
performed for this message. performed for this message.
8. IF the [DMARC] record for the Author Domain or Author 8. If the DMARC [RFC7489] record for the Author Domain or Author
Organizational Domain includes a subdomain policy, and that Organizational Domain includes a subdomain policy, and that
subdomain policy is sp=none then BIMI processing MUST NOT be subdomain policy is sp=none then BIMI processing MUST NOT be
performed for this message. performed for this message.
9. If the [DMARC] policy for the Author Domain or Author 9. If the DMARC [RFC7489] policy for the Author Domain or Author
Organizational Domain is p=quarantine, and the [DMARC] record Organizational Domain is p=quarantine, and the DMARC [RFC7489]
defines a percentage tag, then that tag MUST be pct=100, record defines a percentage tag, then that tag MUST be pct=100,
otherwise BIMI processing MUST NOT be performed for this message. otherwise BIMI processing MUST NOT be performed for this message.
8.2. Assertion Record Discovery 7.2. Assertion Record Discovery
Through the BIMI Assertion Record (Section 5.2), Domain Owners use Through the BIMI Assertion Record (#assertion-record-definition),
DNS TXT records to advertise their preferences. Preference discovery Domain Owners use DNS TXT records to advertise their preferences.
is accomplished via a method similar to the method used for [DMARC] Preference discovery is accomplished via a method similar to the
records. This method, and the important differences between BIMI and method used for DMARC [RFC7489] records. This method, and the
[DMARC] mechanisms, are discussed below. important differences between BIMI and DMARC [RFC7489] mechanisms,
are discussed below.
Assertion Record Discovery MUST NOT be attempted if the message Assertion Record Discovery MUST NOT be attempted if the message
authentication fails per Receiver policy. authentication fails per Receiver policy.
To balance the conflicting requirements of supporting wildcarding, To balance the conflicting requirements of supporting wildcarding,
allowing subdomain policy overrides, and limiting DNS query load, allowing subdomain policy overrides, and limiting DNS query load,
Protocol Clients MUST employ the following lookup scheme for the Protocol Clients MUST employ the following lookup scheme for the
appropriate BIMI record for the message: appropriate BIMI record for the message:
1. Start with the DNS domain found in the RFC5322.From header in the 1. Start with the DNS domain found in the RFC5322.From header in the
message. Define this DNS domain as the Author Domain. message. Define this DNS domain as the Author Domain.
2. If the message for which the Indicator is being determined 2. If the message for which the Indicator is being determined
specifies a selector value in the BIMI Selector Header specifies a selector value in the BIMI Selector Header (#bimi-
(Section 6.1), use this value for the selector. Otherwise the selector), use this value for the selector. Otherwise the value
value 'default' MUST be used for the selector. 'default' MUST be used for the selector.
3. Clients MUST query the DNS for a BIMI TXT record at the DNS 3. Clients MUST query the DNS for a BIMI TXT record at the DNS
domain constructed by concatenating the selector, the string domain constructed by concatenating the selector, the string
'_bimi', and the Author Domain. A possibly empty set of records '_bimi', and the Author Domain. A possibly empty set of records
is returned. is returned.
4. Records that do not start with a "v=" tag that identifies the 4. Records that do not start with a "v=" tag that identifies the
current version of BIMI MUST be discarded. current version of BIMI MUST be discarded.
5. If the set is now empty, the Client MUST query the DNS for a BIMI 5. If the set is now empty, the Client MUST query the DNS for a BIMI
TXT record at the DNS domain constructed by concatenating the TXT record at the DNS domain constructed by concatenating the
selector 'default', the string '_bimi', and the Organizational selector, the string '_bimi', and the Organizational Domain (as
Domain (as defined in [DMARC]) corresponding to the Author defined in DMARC [RFC7489]) corresponding to the Author Domain.
Domain. A custom selector that does not exist falls back to A custom selector that does not exist falls back to
default._bimi.<organizationalDomain>, and NOT
<selector>._bimi.<organizationalDomain>. A possibly empty set of <selector>._bimi.<organizationalDomain>. A possibly empty set of
records is returned. records is returned.
6. Records that do not start with a "v=" tag that identifies the 6. Records that do not start with a "v=" tag that identifies the
current version of BIMI MUST be discarded. current version of BIMI MUST be discarded.
7. If the remaining set contains multiple records or no records, 7. If the remaining set contains multiple records or no records,
Assertion Record Discovery terminates and BIMI processing MUST Assertion Record Discovery terminates and BIMI processing MUST
NOT be performed for this message. NOT be performed for this message.
8. If the remaining set contains only a single record, this record 8. If the remaining set contains only a single record, this record
is used for BIMI Assertion. is used for BIMI Assertion.
8.3. Indicator Discovery. 7.3. Indicator Discovery.
1. If the retrieved Assertion Record does not include a valid bimi- 1. If the retrieved Assertion Record does not include a valid bimi-
location in the l= tag, then Indicator Discovery has failed, and location in the l= tag, then Indicator Discovery has failed, and
the Indicator MUST NOT be displayed. The bimi-location entry the Indicator MUST NOT be displayed. The bimi-location entry
MUST be a URI with a HTTPS transport. MUST be a URI with a HTTPS transport.
2. If the retrieved Assertion Record includes a bimi-evidence- 2. If the retrieved Assertion Record includes a bimi-evidence-
location entry in the a= tag, and the receiver supports BIMI location entry in the a= tag, and the receiver supports BIMI
Evidence Document validation, then proceed to the Indicator Evidence Document validation, then proceed to the Indicator
Discovery With Evidence (Section 8.4) step. Discovery With Evidence (#indicator-discovery-with-evidence)
step.
3. If the receiver does not support BIMI Evidence Document 3. If the receiver does not support BIMI Evidence Document
validation, or the retrieved Assertion Record does not include a validation, or the retrieved Assertion Record does not include a
bimi-evidence-location entry, then proceed to the Indicator bimi-evidence-location entry, then proceed to the Indicator
Discovery Without Evidence (Section 8.5) step. Discovery Without Evidence (#indicator-discovery-without-
evidence) step.
8.4. Indicator Discovery With Evidence. 7.4. Indicator Discovery With Evidence.
Individual types of BIMI Evidence Document MAY specify extra Individual types of BIMI Evidence Document MAY specify extra
discovery and validation steps. These will be defined in separate discovery and validation steps. These will be defined in separate
documents. documents.
8.5. Indicator Discovery Without Evidence. 7.5. Indicator Discovery Without Evidence.
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.
If an Assertion Record is found, and has an empty or missing bimi- If an Assertion Record is found, and has an empty or missing bimi-
evidence-location entry then no evidence has is presented, and the evidence-location entry then no evidence has is presented, and the
Indicator MUST be retrieved from the URI specified in the bimi- Indicator MUST be retrieved from the URI specified in the bimi-
location entry using the following algorithm: location entry using the following algorithm:
1. Retrieve the SVG Indicator from the URI specified in the l= tag. 1. Retrieve the SVG Indicator from the URI specified in the l= tag.
This MUST be a URI with a HTTPS transport. This MUST be a URI with a HTTPS transport.
2. If the TLS server identity certificate presented during the TLS 2. If the TLS server identity certificate presented during the TLS
session setup does not chain-up to a root certificate the Client session setup does not chain-up to a root certificate the Client
trusts then Indicator validation has failed and the Indicator trusts then Indicator validation has failed and the Indicator
MUST NOT be displayed. MUST NOT be displayed.
3. Proceed to the Indicator Validation (Section 8.6) step. 3. Proceed to the Indicator Validation (#indicator-validation) step.
8.6. Indicator Validation 7.6. Indicator Validation
1. Check the file size of the retrieved Indicator against 1. Check the file size of the retrieved Indicator against
recommended maximum sizes as defined in this document, and in the recommended maximum sizes as defined in this document, and in the
BIMI SVG document. A receiver MAY choose to implement their own BIMI SVG document. A receiver MAY choose to implement their own
file size restrictions. If the Indicator is larger than the file size restrictions. If the Indicator is larger than the
maximum size the the receiver MAY choose not to display the maximum size the the receiver MAY choose not to display the
Indicator. A receiver MAY choose to implement the size limit as Indicator. A receiver MAY choose to implement the size limit as
a retrieval limit rather than retrieving the entire document and a retrieval limit rather than retrieving the entire document and
then checking the size. then checking the size.
2. If the SVG Indicator is missing, or is not a valid SVG or SVGZ 2. If the SVG Indicator is missing, or is not a valid SVG or SVGZ
document then validation has failed and the Indicator MUST NOT be document then validation has failed and the Indicator MUST NOT be
displayed. displayed.
3. Check the retrieved Indicator against the SVG validation steps 3. Check the retrieved Indicator against the SVG validation steps
specified in this document, and in the BIMI SVG document. (Note specified in this document, and in the BIMI SVG document.
to WG, do we want to specify the SVG_1.2_PS profile here or leave
that to the other document?)
4. If Indicator verification has passed, and the Indicator is from a 4. If Indicator verification has passed, and the Indicator is from a
trusted source, then the Indicator MAY be displayed per receiver trusted source, then the Indicator MAY be displayed per receiver
policy. policy.
(Note to WG, add link to BIMI SVG document) 7.7. Affix BIMI Status to Authentication Results Header Field
8.7. Affix BIMI Status to Authentication Results Header Field
Upon completion of Assertion Record Discovery, Indicator Discovery, Upon completion of Assertion Record Discovery, Indicator Discovery,
and Indicator Validation, an MTA SHOULD affix the result in the and Indicator Validation, an MTA SHOULD affix the result in the
Authentication-Results header using the following syntax, with the Authentication-Results header using the following syntax, with the
following key=value pairs: following key=value pairs:
bimi: Result of the bimi lookup (plain-text; REQUIRED). Range of bimi: Result of the bimi lookup (plain-text; REQUIRED). Range of
values are 'pass' (BIMI successfully validated), 'none' (no BIMI values are 'pass' (BIMI successfully validated), 'none' (no BIMI
record present), 'fail' (syntax error in the BIMI record, failure in record present), 'fail' (syntax error in the BIMI record, failure in
Discovery or Validation steps, or some other error), 'temperror' (DNS Discovery or Validation steps, or some other error), 'temperror' (DNS
lookup problem), or 'skipped' (BIMI check was not performed, possibly lookup problem), 'declined' (The domain owner published an explicit
because the message did not comply with the minimum requirements such declination record), or 'skipped' (BIMI check was not performed,
as passing DMARC, or the MTA does not trust the sending domain). The possibly because the message did not comply with the minimum
MTA MAY put comments in parentheses after bimi result, e.g., requirements such as passing DMARC, or the MTA does not trust the
"bimi=fail (Invalid SVG)", "bimi=skipped (sender not trusted)" or sending domain). The MTA MAY put comments in parentheses after bimi
"bimi=skipped (message failed DMARC)". result, e.g., "bimi=fail (Invalid SVG)", "bimi=skipped (sender not
trusted)" or "bimi=skipped (message failed DMARC)".
header.d: Domain of the BIMI Assertion Record which was evaluated header.d: Domain of the BIMI Assertion Record which was evaluated
(plain-text; REQUIRED if bimi=pass). For example, this will be the (plain-text; REQUIRED if bimi=pass). For example, this will be the
organizational domain if the BIMI lookup used the fallback record, organizational domain if the BIMI lookup used the fallback record,
otherwise it will be the RFC5322.From domain. otherwise it will be the RFC5322.From domain.
header.selector: Selector of the BIMI Assertion Record which was header.selector: Selector of the BIMI Assertion Record which was
evaluated (plain-text; REQUIRED if bimi=pass). For example, if a evaluated (plain-text; REQUIRED if bimi=pass). For example, if a
BIMI-Selector Header was present and used to discover a BIMI BIMI-Selector Header was present and used to discover a BIMI
Assertion Record then this will be the Selector used, otherwise this Assertion Record then this will be the Selector used, otherwise this
skipping to change at line 995 skipping to change at page 23, line 5
checked). If the Authority Evidence presented in the BIMI Assertion checked). If the Authority Evidence presented in the BIMI Assertion
Record was checked and found to be valid then this MUST be set to Record was checked and found to be valid then this MUST be set to
pass. If the validation failed then this MUST be set to fail. If no pass. If the validation failed then this MUST be set to fail. If no
Authority Evidence was presented, or the MTA did not check the Authority Evidence was presented, or the MTA did not check the
Authority Evidence then this SHOULD be set to none. Authority Evidence then this SHOULD be set to none.
policy.authority-uri: The URI of the BIMI Evidence Document checked, policy.authority-uri: The URI of the BIMI Evidence Document checked,
as found in the a= tag of the BIMI Assertion Record (plain-text; as found in the a= tag of the BIMI Assertion Record (plain-text;
OPTIONAL). OPTIONAL).
8.8. Handle Existing BIMI-Location and BIMI-Indicator Headers 7.8. Handle Existing BIMI-Location and BIMI-Indicator Headers
Regardless of success of the BIMI lookup, if a BIMI-Location or a Regardless of success of the BIMI lookup, if a BIMI-Location or a
BIMI-Indicator header is already present in a message it MUST be BIMI-Indicator header is already present in a message it MUST be
either removed or renamed. This is because the MTA performing BIMI- either removed or renamed. This is because the MTA performing BIMI-
related processing immediately prior to a Mail Delivery Agent (or related processing immediately prior to a Mail Delivery Agent (or
within the same administrative realm) is the only entity allowed to within the same administrative realm) is the only entity allowed to
specify the BIMI-Location or BIMI-Indicator headers (e.g. not the specify the BIMI-Location or BIMI-Indicator headers (e.g. not the
sending MTA, and not an intermediate MTA). Allowing one or more sending MTA, and not an intermediate MTA). Allowing one or more
existing headers through to a MUA is a security risk. existing headers through to a MUA is a security risk.
If the original email message had a DKIM signature, it has already If the original email message had a DKIM signature, it has already
been evaluated. Removing the BIMI-Location header at this point been evaluated. Removing the BIMI-Location header at this point
should not invalidate the signature since it should not be included should not invalidate the signature since it should not be included
within it per this spec. within it per this spec.
8.9. Construct BIMI-Location URI 7.9. Construct BIMI-Location URI
This header MUST NOT be added if Discovery or Validation steps This header MUST NOT be added if Discovery or Validation steps
failed. failed.
The URI used to retrieve the validated SVG Indicator. If the The URI used to retrieve the validated SVG Indicator. If the
receiver extracted the Indicator from the BIMI Evidence Document then receiver extracted the Indicator from the BIMI Evidence Document then
this SHOULD be the bimi-evidence-location added with a a= tag, this SHOULD be the bimi-evidence-location added with a a= tag,
otherwise it SHOULD be the bimi-location added with a l= tag. If otherwise it SHOULD be the bimi-location added with a l= tag. If
both a= and l= tags are included then the MTA MUST perform checks to both a= and l= tags are included then the MTA MUST perform checks to
ensure that the SVG Indicator referenced by the bimi-location is ensure that the SVG Indicator referenced by the bimi-location is
identical to the SVG Indicator extracted from the BIMI Evidence identical to the SVG Indicator extracted from the BIMI Evidence
Document. Document.
8.10. Construct BIMI-Indicator header 7.10. Construct BIMI-Indicator header
This header MUST NOT be added if Discovery or Validation steps This header MUST NOT be added if Discovery or Validation steps
failed. failed.
Encode the SVG Indicator retrieved and validated during the Indicator Encode the SVG Indicator retrieved and validated during the Indicator
Discovery and Indicator Validation steps as base64 encoded data. If Discovery and Indicator Validation steps as base64 encoded data. If
the Indicator was compressed with gzip when retrieved then the data the Indicator was compressed with gzip when retrieved then the data
SHOULD NOT be uncompressed before being base64 encoded. MUST be uncompressed before being base64 encoded.
The MTA MUST fold the header to be within the line length limits of The MTA MUST fold the header to be within the line length limits of
[SMTP]. SMTP [RFC5321].
9. Security Considerations 8. Security Considerations
The consistent use of Brand Indicators is valuable for Domain Owners, The consistent use of Brand Indicators is valuable for Domain Owners,
Mail Receivers, and End Users. However, the routine display of brand Mail Receivers, and End Users. However, the routine display of brand
Indicators represents an attractive target for abuse, especially for Indicators represents an attractive target for abuse, especially for
determined malicious actors. Great care is warranted. The determined malicious actors. Great care is warranted. The
discussion following as an incomplete list of considerations. discussion following as an incomplete list of considerations.
9.1. Indirect Mail Flows 8.1. Indirect Mail Flows
If a mail store ingests a message from another mail store through If a mail store ingests a message from another mail store through
some other means, the message may or may not have BIMI headers added some other means, the message may or may not have BIMI headers added
already. If the receiving store trusts the other mail store, it may already. If the receiving store trusts the other mail store, it may
simply use existing headers. Or, it may re-evaluate BIMI policy and simply use existing headers. Or, it may re-evaluate BIMI policy and
requirements, and create or replace the BIMI-Location header. requirements, and create or replace the BIMI-Location header.
9.2. Lookalike Domains and Copycat Indicators 8.2. Lookalike Domains and Copycat Indicators
Publishing BIMI records is not sufficient for an MTA to signal to the Publishing BIMI records is not sufficient for an MTA to signal to the
MUA to load the BIMI Indicator. For example, the Domain Owner may MUA to load the BIMI Indicator. For example, the Domain Owner may
also need to have a sufficiently strong reputation with the MTA. The also need to have a sufficiently strong reputation with the MTA. The
receiver may use a manually maintained list of large brands, it may receiver may use a manually maintained list of large brands, it may
import a list from a third party of acceptable domains, or it may import a list from a third party of acceptable domains, or it may
apply its own reputation heuristics before deciding whether or not to apply its own reputation heuristics before deciding whether or not to
load the BIMI Indicator. BIMI does not specify what MTAs may bring load the BIMI Indicator. BIMI does not specify what MTAs may bring
to bear as additional factors. to bear as additional factors.
9.3. Large files and buffer overflows 8.3. Large files and buffer overflows
The MTA or MUA should perform some basic analysis and avoid loading The MTA or MUA should perform some basic analysis and avoid loading
Indicators that are too large or too small. The Receiver may choose Indicators that are too large or too small. The Receiver may choose
to maintain a manual list and do the inspection of its list offline to maintain a manual list and do the inspection of its list offline
so it doesn't have to do it at time-of-scan. so it doesn't have to do it at time-of-scan.
9.4. Slow DNS queries 8.4. Slow DNS queries
All email Receivers already have to query for DNS records, and all of All email Receivers already have to query for DNS records, and all of
them have built-in timeouts when performing DNS queries. them have built-in timeouts when performing DNS queries.
Furthermore, the use of caching when loading Indicators can help cut Furthermore, the use of caching when loading Indicators can help cut
down on load time. Virtually all email clients have some sort of down on load time. Virtually all email clients have some sort of
image-downloading built-in and make decisions when to load or not image-downloading built-in and make decisions when to load or not
load Indicators. load Indicators.
9.5. Unaligned Indicators and asserting domains 8.5. Unaligned Indicators and asserting domains
There is no guarantee that a group responsible for managing Brand There is no guarantee that a group responsible for managing Brand
Indicators will have access to put these Indicators directly in any Indicators will have access to put these Indicators directly in any
specific location of a domain, and requiring that Indicators live on specific location of a domain, and requiring that Indicators live on
the asserted domain is too high a bar. Additionally, letting a brand the asserted domain is too high a bar. Additionally, letting a brand
have Indicator locations outside its domain may be desirable so that have Indicator locations outside its domain may be desirable so that
someone sending legitimate authenticated email on the Domain Owner's someone sending legitimate authenticated email on the Domain Owner's
behalf can manage and set selectors as an authorized third party behalf can manage and set selectors as an authorized third party
without requiring access to the Domain Owner's DNS or web services. without requiring access to the Domain Owner's DNS or web services.
9.6. Unsigned BIMI-Selector Header 8.6. Unsigned BIMI-Selector Header
If a Domain Owner relies on SPF but not DKIM for email If a Domain Owner relies on SPF but not DKIM for email
authentication, then adding a requirement of DKIM may create too high authentication, then adding a requirement of DKIM may create too high
of a bar for that sender. On the other hand, Receivers doing BIMI of a bar for that sender. On the other hand, Receivers doing BIMI
assertion may factor in the lack of DKIM signing when deciding assertion may factor in the lack of DKIM signing when deciding
whether to add a BIMI-Location header. whether to add a BIMI-Location header.
9.7. CGI scripts in Indicator payload 8.7. CGI scripts in Indicator payload
MTAs and MVAs should aggressively police Indicators to ensure they MTAs and MVAs should aggressively police Indicators to ensure they
are the Indicators they claim to be, are within appropriate size are the Indicators they claim to be, are within appropriate size
limits, and pass other sanity checks. Additionally, MTAs might cache limits, and pass other sanity checks. Additionally, MTAs might cache
good Indicators and serve them directly to their MUAs, which would in good Indicators and serve them directly to their MUAs, which would in
practice bypass any malicious dynamic payload set to trigger against practice bypass any malicious dynamic payload set to trigger against
an end user but not an MTA. an end user but not an MTA.
9.8. Metadata in Indicators 8.8. Metadata in Indicators
Domain Owners should be careful to strip any metadata out of Domain Owners should be careful to strip any metadata out of
published Indicators that they don't want to expose or which might published Indicators that they don't want to expose or which might
bloat file size. MTAs and MVAs might wish to inspect and remove such bloat file size. MTAs and MVAs might wish to inspect and remove such
data from Indicators before exposing them to end users. data from Indicators before exposing them to end users.
10. IANA Considerations 9. IANA Considerations
IANA will need to reserve three new entries for the "Permanent IANA will need to reserve three new entries for the "Permanent
Message Header Field Names" registry and create a registry for Message Header Field Names" registry and create a registry for
support file formats for BIMI. support file formats for BIMI.
10.1. Permanent Header Field Updates 9.1. Permanent Header Field Updates
Header field name: BIMI-Selector Header field name: BIMI-Selector
Applicable protocol: mail Applicable protocol: mail
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: This one Specification document: This one
Header field name: BIMI-Location Header field name: BIMI-Location
Applicable protocol: mail Applicable protocol: mail
Status: standard Status: standard
skipping to change at line 1154 skipping to change at page 26, line 28
Header field name: BIMI-Indicator Header field name: BIMI-Indicator
Applicable protocol: mail Applicable protocol: mail
Status: standard Status: standard
Author/Change controller: IETF Author/Change controller: IETF
Specification document: This one Specification document: This one
10.2. Registry for Supported BIMI Formats 9.2. Registry for Supported BIMI Formats
Names of support file types supported by BIMI must be registered by Names of support file types supported by BIMI must be registered by
IANA. IANA.
New entries are assigned only for values that have been documented in New entries are assigned only for values that have been documented in
a published RFC that has had IETF Review, per [IANA-CONSIDERATIONS]. a published RFC that has had IETF Review, per [IANA-CONSIDERATIONS].
Each method must register a name, the file extension, the Each method must register a name, the file extension, the
specification that defines it, and a description. specification that defines it, and a description.
10.3. Other IANA needs 9.3. Other IANA needs
NOTE TO WORKING GROUP: The registry for BIMI tags needs to be
properly set up, as does the registry for validation actions.
11. References
11.1. Normative References
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[ARC] Andersen, K., Long, B., Blank, S., and M. Kucherawy, "The
Authenticated Received Chain (ARC) Protocol", July 2019,
<http://www.rfc-editor.org/info/rfc8617>.
[Authentication-Results] 10. Normative References
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status", August 2015,
<https://tools.ietf.org/html/rfc7601>.
[DKIM] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys [RFC1035] Mockapetris, P., "Domain names - implementation and
Identified Mail (DKIM) Signatures", September 2011, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
<http://www.rfc-editor.org/info/rfc6376>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[DMARC] Kucherawy, M. and E. Zwicky, "Domain-based Message [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Authentication, Reporting, and Conformance (DMARC)", March Requirement Levels", BCP 14, RFC 2119,
2015, <http://www.rfc-editor.org/info/rfc7489>. DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[DNS] Mockapetris, P., "Domain names - implementation and [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
specification", November 1987, Specifications: ABNF", STD 68, RFC 5234,
<http://www.rfc-editor.org/info/rfc1035>. DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[EMAIL-ARCH] [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
Crocker, D., "Internet Mail Architecture", July 2009, DOI 10.17487/RFC5321, October 2008,
<http://www.rfc-editor.org/info/rfc5598>. <https://www.rfc-editor.org/info/rfc5321>.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
Requirement Levels", March 1997, DOI 10.17487/RFC5598, July 2009,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc5598>.
[Logotype] Santesson, S., Housley, R., and T. Freemani, "Internet [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
X.509 Public Key Infrastructure, Logotypes in X.509 "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
Certificates", February 2004, RFC 6376, DOI 10.17487/RFC6376, September 2011,
<http://www.rfc-editor.org/info/rfc3709>. <https://www.rfc-editor.org/info/rfc6376>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", October [RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
2008, <http://www.rfc-editor.org/info/rfc5321>. Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[SPF] Kitterman, S., "Sender Policy Framework (SPF) for [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Authorizing Use of Domains in Email, Version 1", April Message Authentication, Reporting, and Conformance
2014, <http://www.rfc-editor.org/info/rfc7208>. (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
Resource Identifier (URI): Generic Syntax", January 2005, Kucherawy, Ed., "The Authenticated Received Chain (ARC)
<http://www.rfc-editor.org/info/rfc3986>. Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
<https://www.rfc-editor.org/info/rfc8617>.
11.2. Informative References 11. Informative References
[BIMI-OVERVIEW] [BIMI-OVERVIEW]
Blank, S., Kumaran, N., and J. Levine, "An Overview of the "An Overview of the Design of BIMI",
Design of BIMI", July 2020, <http://tools.ietf.org/html/draft-bkl-bimi-overview-
<https://tools.ietf.org/html/draft-bkl-bimi-overview-00>. 00.html>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Appendix A. Example Selector Discovery (INFORMATIVE) Appendix A. Example Selector Discovery (INFORMATIVE)
This section shows several examples of how a receiving MTA should This section shows several examples of how a receiving MTA should
determine which Assertion Record to use depending on the BIMI- determine which Assertion Record to use depending on the BIMI-
Selector header. Selector header.
A.1. No BIMI-Selector Header A.1. No BIMI-Selector Header
The domain example.com does not send with a BIMI-Selector header. The domain example.com does not send with a BIMI-Selector header.
skipping to change at line 1268 skipping to change at page 28, line 44
The MTA would lookup default._bimi.foo.example.com for the BIMI DNS The MTA would lookup default._bimi.foo.example.com for the BIMI DNS
record. If it did not exist, it would lookup record. If it did not exist, it would lookup
default._bimi.example.com. default._bimi.example.com.
A.4. With BIMI-Selector Header on a subdomain A.4. With BIMI-Selector Header on a subdomain
The domain foo.example.com sends without a BIMI-Selector header: The domain foo.example.com sends without a BIMI-Selector header:
From: sender@foo.example.com From: sender@foo.example.com
BIMI-Selector: v=BIMI1; s=selector; BIMI-Selector: v=BIMI1; s=myselector;
The MTA would lookup selector._bimi.foo.example.com for the BIMI DNS The MTA would lookup myselector._bimi.foo.example.com for the BIMI
record. If it did not exist, it would fall back to the lookup DNS record. If it did not exist, it would fall back to the lookup
default._bimi.example.com. myselector._bimi.example.com.
A.5. Invalid BIMI-Selector Header A.5. Invalid BIMI-Selector Header
The domain example.com sends with a BIMI-Selector header, but does The domain example.com sends with a BIMI-Selector header, but does
not include the required field 'v=': not include the required field 'v=':
From: sender@example.com From: sender@example.com
BIMI-Selector: s=selector; BIMI-Selector: s=myselector;
The MTA would ignore this header, and lookup The MTA would ignore this header, and lookup
default._bimi.example.com. default._bimi.example.com.
Appendix B. Example Authentication-Results entry (INFORMATIONAL) Appendix B. Example Authentication-Results entry (INFORMATIONAL)
This section shows example Authentication-Results stamps based on This section shows example Authentication-Results stamps based on
different BIMI lookup statuses. different BIMI lookup statuses.
B.1. Successful BIMI lookup B.1. Successful BIMI lookup
From: sender@example.com From: sender@example.com
BIMI-Selector: v=BIMI1; s=selector; BIMI-Selector: v=BIMI1; s=myselector;
Authentication-Results: bimi=pass header.d=example.com header.selector=selector; Authentication-Results: bimi=pass header.d=example.com header.selector=myselector;
B.2. No BIMI record B.2. No BIMI record
From: sender@sub.example.com From: sender@sub.example.com
Authentication-Results: bimi=none; Authentication-Results: bimi=none;
In this example, sub.example.com does not have a BIMI record at In this example, sub.example.com does not have a BIMI record at
default._bimi.sub.example.com, nor does default._bimi.example.com default._bimi.sub.example.com, nor does default._bimi.example.com
B.3. Subdomain has no default record, but organizational domain does B.3. Declination to Publish
From: sender@example.com
Authentication-Results: bimi=declined;
In this example the record found at default._bimi.example.com was
"v=BIMI1; l=; a=;", indicating a Declination to Publish a BIMI
Assertion Record, and so indicating that BIMI processing should not
occur on this message.
B.4. Subdomain has no default record, but organizational domain does
From: sender@sub.example.com From: sender@sub.example.com
Authentication-Results: bimi=pass header.d=example.com header.selector=default; Authentication-Results: bimi=pass header.d=example.com header.selector=default;
B.4. Subdomain has no record for selector, but organization domain has a B.5. Subdomain and orgznizational domain have no record for selector,
default but organization
domain has a default
From: sender@sub.example.com From: sender@sub.example.com
BIMI-Selector: v=BIMI1; s=selector; BIMI-Selector: v=BIMI1; s=myselector;
Authentication-Results: bimi=pass header.d=example.com header.selector=default; Authentication-Results: bimi=none;
In this example, the sender specified a DNS record at In this example, the sender specified a DNS record at
selector._bimi.sub.example.com but it did not exist. The fallback is myselector._bimi.sub.example.com but it did not exist. The fallback
to use default._bimi.example.com, not selector._bimi.example.com even is to use myselector._bimi.example.com, which also does not exist.
if that record exists. The assertion record does exist for the default selector at the
organizational domain default._bimi.example.com, however this is not
used as the sender specified a selector of myselector.
B.6. Subdomain has no record for selector, but organization domain does
From: sender@sub.example.com
BIMI-Selector: v=BIMI1; s=myselector;
Authentication-Results: bimi=pass header.d=example.com header.selector=myselector;
In this example, the sender specified a DNS record at
myselector._bimi.sub.example.com but it did not exist. The fallback
is to use myselector._bimi.example.com.
Appendix C. Example BIMI Headers Construction (INFORMATIONAL) Appendix C. Example BIMI Headers Construction (INFORMATIONAL)
This section shows how an example MTA might evaluate an incoming This section shows how an example MTA might evaluate an incoming
email for BIMI participation, and how it could share that email for BIMI participation, and how it could share that
determination with its MUA(s). determination with its MUA(s).
C.1. MTA Receives an email C.1. MTA Receives an email
The MTA receives the following DKIM signed message: The MTA receives the following DKIM signed message:
skipping to change at line 1398 skipping to change at page 32, line 12
spec is irrelevant. It was used for DKIM validation and then thrown spec is irrelevant. It was used for DKIM validation and then thrown
out by the MTA. out by the MTA.
C.6. The MUA displays the Indicator C.6. The MUA displays the Indicator
The mail is opened from the mail store in an MUA. The MUA performs The mail is opened from the mail store in an MUA. The MUA performs
locally defined checks to make sure that it can trust the BIMI- locally defined checks to make sure that it can trust the BIMI-
Indicator header. Finally, the MUA extracts the Indicator from the Indicator header. Finally, the MUA extracts the Indicator from the
BIMI-Indicator header and displays it to the user. BIMI-Indicator header and displays it to the user.
C.7. Acknowledgements Appendix D. Acknowledgements
Many people have contributed to the development of BIMI. Along with Many people have contributed to the development of BIMI. Along with
thanks to members of the current AuthIndicators Working Group, the thanks to members of the current AuthIndicators Working Group, the
editors wish to acknowledge the efforts of Sri Somanchi, Don editors wish to acknowledge the efforts of Sri Somanchi, Don
Cardinal, Steve Jones, and John Levine. Cardinal, Steve Jones, and John Levine.
Authors' Addresses Authors' Addresses
Seth Blank Seth Blank
Valimail Valimail
Email: seth@valimail.com Email: seth@valimail.com
Peter Goldstein Peter Goldstein
Valimail Valimail
Email: peter@valimail.com Email: peter@valimail.com
Thede Loder Thede Loder
Skyelogic Works LLC Skye Logicworks LLC
Email: thede@skyelogicworks.com Email: thede@skyelogicworks.com
Terry Zink Terry Zink
Zink Magical Contraptions
Email: tzink@terryzink.com Email: tzink@terryzink.com
Marc Bradshaw Marc Bradshaw
Fastmail Fastmail
Email: marc@fastmailteam.com Email: marc@fastmailteam.com
 End of changes. 138 change blocks. 
349 lines changed or deleted 398 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/