draft-brand-indicators-for-message-identification-latest.xml

<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.miek.nl" -->
<rfc version="3" ipr="trust200902" docName="draft-brand-indicators-for-message-identification-latest-02" submissionType="IETF" category="std" xml:lang="en" xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true">

<front>
<title abbrev="BIMI">Brand Indicators for Message Identification (BIMI)</title><seriesInfo value="draft-brand-indicators-for-message-identification-latest-02" stream="IETF" status="standard" name="Internet-Draft"></seriesInfo>
<author initials="S." surname="Blank" fullname="Seth Blank"><organization>Valimail</organization><address><postal><street></street>
</postal><email>seth@valimail.com</email>
</address></author>
<author initials="P." surname="Goldstein" fullname="Peter Goldstein"><organization>Valimail</organization><address><postal><street></street>
</postal><email>peter@valimail.com</email>
</address></author>
<author initials="T." surname="Loder (ed)" fullname="Thede Loder"><organization>Skye Logicworks LLC</organization><address><postal><street></street>
</postal><email>thede@skyelogicworks.com</email>
</address></author>
<author initials="T." surname="Zink (ed)" fullname="Terry Zink"><organization></organization><address><postal><street></street>
</postal><email>tzink@terryzink.com</email>
</address></author>
<author initials="M." surname="Bradshaw (ed)" fullname="Marc Bradshaw"><organization>Fastmail</organization><address><postal><street></street>
</postal><email>marc@fastmailteam.com</email>
</address></author>
<date/>
<area>Application</area>
<workgroup>Network</workgroup>

<abstract>
<t>Brand Indicators for Message Identification (BIMI) permits Domain Owners
to coordinate with Mail User Agents (MUAs) to display brand-specific
Indicators next to properly authenticated messages.  There are two aspects
of BIMI coordination: a scalable mechanism for Domain Owners to publish
their desired Indicators, and a mechanism for Mail Transfer Agents (MTAs)
to verify the authenticity of the Indicator.  This document specifies how
Domain Owners communicate their desired Indicators through the BIMI Assertion
Record in DNS and how that record is to be interpreted by MTAs and MUAs. MUAs
and mail-receiving organizations are free to define their own policies for making
use of BIMI data and for Indicator display as they see fit.</t>
</abstract>

</front>

<middle>

<section anchor="introduction"><name>Introduction</name>
<t>RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source for this draft is maintained in GitHub at:
<eref target="https://github.com/BLAHBLAHBLAH">https://github.com/BLAHBLAHBLAH</eref></t>
<t>This document defines Brand Indicators for Message Identification (BIMI),
which enables Domain Owners to coordinate with Mail Box Providers (MBPs),
Mail Transfer Agents (MTAs), and Mail User Agents (MUAs) in the display of
brand-specific Indicators next to properly authenticated messages.</t>
<t>BIMI is designed to be open and to work at Internet scale.  BIMI is
intended to drive adoption of email authentication best practices by
leveraging existing DMARC <xref target="RFC7489"></xref> policies, the supporting authentication
methods DKIM <xref target="RFC6376"></xref> and SPF <xref target="RFC7208"></xref>, and other associated standards
such as ARC <xref target="RFC8617"></xref>.</t>
<t>The approach taken by BIMI is heavily influenced by the approach taken
in DKIM <xref target="RFC6376"></xref>, in that BIMI:</t>

<ul>
<li>has no dependency on the deployment of any new Internet protocols or
services for indicator registration or revocation;</li>
<li>makes no attempt to include encryption as part of the mechanism;</li>
<li>is compatible with the existing email infrastructure and transparent
to the fullest extent possible;</li>
<li>requires minimal new infrastructure;</li>
<li>can be implemented independently of clients in order to reduce
deployment time;</li>
<li>can be deployed incrementally; and</li>
<li>allows delegation of indicator hosting to third parties.</li>
</ul>
<t>To participate in BIMI, Domain Owners MUST have a strong [DMARC] policy
(quarantine or reject) on both the Organizational Domain, and the RFC5322.From
Domain of the message. Quarantine policies MUST NOT have a pct less than pct=100.</t>
<t>This document defines how Domain Owners specify their desired indicators
through the BIMI Assertion Record in DNS and how that record is to be
interpreted by MTAs and MUAs.  This document does not cover how domains
or indicators are verified, how MUAs should display the indicators, or
how other protocols (i.e. IMAP, JMAP) can be extended to work with BIMI.
Other documents may cover these topics.  MUAs and Mail Box Providers (MBPs)
are free to define their own policies for making use of BIMI data and for
indicator display as they see fit.</t>
</section>

<section anchor="why-bimi"><name>Overview</name>
<t>The Sender Policy Framework (SPF <xref target="RFC7208"></xref>), DomainKeys Identified Mail (DKIM
<xref target="RFC6376"></xref>), &quot;Domain-based Message Authentication, Reporting, and Conformance&quot;
(DMARC <xref target="RFC7489"></xref>), and Authenticated Received Chain (ARC <xref target="RFC8617"></xref>) provide
mechanisms for domain-level authentication of email messages.  They enable
cooperating email senders and receivers to distinguish messages that are authorized
to use the domain name from those that are not. BIMI relies on these authentication
protocols, but is not a new authentication protocol itself.</t>
<t>MUAs are increasingly incorporating graphical Indicators to indicate 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 there are no open standards for publishing
and aiding discovery of preferred Indicators or for tying display of them to authentic
messages only.</t>
<t>Because of the desire to have brand-specific Indicators available, some
mail-receiving organizations have developed closed systems for obtaining
and displaying Brand Indicators for select domains.  While this has enabled
these mail-receiving organizations to display brand Indicators for a limited
subset of messages, this closed approach has a number of downsides:</t>

<ol>
<li>It puts a significant burden on each mail-receiving organization, because
they must identify and manage a large database of Brand Indicators.</li>
<li>Scalability is challenging for closed systems that attempt to capture and
maintain complete sets of data across the whole of the Internet.</li>
<li>A lack of uniformity across different mail-receiving organizations - each
organization will have its own Indicator set, which may or may not agree with
those maintained by other organizations for any given domain.</li>
<li>Domain Owners have limited ability to influence the Brand Indicator for the
domain(s) they own, and any ability they do have is likely to be dependent upon
direct coordination with each of many mail-receiving organizations.</li>
<li>Many Domain Owners have no ability to participate whatsoever as they do not
have the appropriate relationships to coordinate with mail-receiving organizations.</li>
<li>MUAs that are not associated with a particular mail-receiving organization
are likely to be disadvantaged, because they are unlikely to receive Indicators
in a standardized manner or optimized for their user interfaces.<br />
</li>
</ol>
<t>This shows the need for a standardized mechanism by which Domain Owners interested
in ensuring that their Indicators are displayed correctly and appropriately can
publish and distribute Brand Indicators for use by any participating MUA.</t>
<t>BIMI removes the substantial burden of curating and maintaining an Indicator
database from MUAs and MBPs, and allows each domain owner to manage their own
Indicators.  As an additional benefit, mail-originating organizations are
incentivized to authenticate their email as doing so will enable them to
influence how email and Indicators from the organization are displayed.</t>
<t>The structure of BIMI is as follows:</t>

<ol>
<li><t>Domain Owners:</t>

<ul>
<li><t>Fully implement the DMARC <xref target="RFC7489"></xref> mechanism, to include:</t>

<ul>
<li><t>Creating and publishing in DNS <xref target="RFC1035"></xref> a DMARC <xref target="RFC7489"></xref> policy record
that meets the following criteria:</t>

<ul>
<li>The policy record MUST express either a Requested Mail Receiver
policy of &quot;quarantine&quot; with an effective percentage of 100%, or a
Requested Mail Receiver policy of &quot;reject&quot; (with any percentage value).</li>
<li>Is a subdomain policy is published it MUST NOT be &quot;none&quot;</li>
<li>Be published for the Organizational Domain, and any subdomains thereof</li>
</ul></li>
<li>Deploying authentication technologies to ensure Identifier Alignment</li>
</ul></li>
<li>Publish their preferred Brand Indicators via the DNS <xref target="RFC1035"></xref>.</li>
</ul></li>
<li>Senders: Ensure mail is properly authenticated, and has a sufficiently
strict DMARC <xref target="RFC7489"></xref> policy.</li>
<li><t>MTAs and MBPs:</t>

<ul>
<li>Confirm authenticity of the message using DMARC <xref target="RFC7489"></xref> and whatever other
authentication mechanisms they wish to apply.</li>
<li>Check for a corresponding BIMI record, obtaining references to the
indicator media and optional substantiation of indicator ownership rights</li>
<li>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.</li>
</ul></li>
<li>MUA: retrieves and displays the brand indicator as appropriate based on
its policy and user interface.</li>
</ol>
<t>The purpose of this structure is to reduce operational complexity at each step.
It is also to consolidate validation and Indicator selection operations into the
MTA, so that Domain Owners need only publish a few simple records and MUAs only
need simple display logic.</t>
<t>It is expected that MBPs implementing BIMI will do so in both their MTAs and MUAs.</t>
<t>#Requirements   {#requirements}</t>
<t>Specification of BIMI in this document is guided by the following high-level goals,
security dependencies, detailed requirements, and items that are documented as out of scope.</t>
<t>An overview of the security challenges and design decisions is documented at <xref target="BIMI-OVERVIEW"></xref>.</t>

<section anchor="goals"><name>High-Level Goals</name>
<t>BIMI has the following high-level goals:</t>

<ul>
<li>Allow Domain Owners to suggest appropriate Indicators for display with authenticated
messages originating from their domains.</li>
<li>Enable the authors of MUAs to display meaningful Indicators associated with the Domain
Owner to recipients of authenticated email.</li>
<li>Provide mechanisms to prevent attempts by malicious Domain Owners to fraudulently
represent messages from their domains as originating with other entities.</li>
<li>Work at Internet Scale.</li>
<li>Encourage the adoption of Email Authentication Best Practices.</li>
</ul>
</section>

<section anchor="security"><name>Security</name>
<t>Brand Indicators are a potential vector for abuse.  BIMI creates a relationship between
sending organization and Mail Receiver so that the receiver can display appropriately
designated Indicators if the sending domain is verified and has meaningful reputation
with the receiver.  Without verification and reputation, there is no way to prevent a
bad actor exxample.com from using example.com's Brand Indicators and behaving maliciously.
This document does not cover the different verification and reputation mechanisms available,
but BIMI relies upon them to be in deployed in order to control abuse.</t>
</section>

<section anchor="out-of-scope"><name>Out of Scope</name>
<t>Several topics and issues are specifically out of scope for the initial version of this work.
These include the following:</t>

<ul>
<li>Publishing policy other than via the DNS.</li>
<li>Specific requirements for Indicator display on MUAs.</li>
<li>The explicit mechanisms used by Verifying Protocol Clients - this will be deferred to a later document.</li>
</ul>
</section>
</section>

<section anchor="terminology"><name>Terminology and Definitions</name>
<t>This section defines terms used in the rest of the document.</t>
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;, &quot;SHALL&quot;, &quot;SHALL NOT&quot;,
&quot;SHOULD&quot;, &quot;SHOULD NOT&quot;, &quot;RECOMMENDED&quot;, &quot;MAY&quot;, and &quot;OPTIONAL&quot; in this
document are to be interpreted as described in
<eref target="https://tools.ietf.org/html/bcp14">BCP 14</eref> <xref target="RFC2119"></xref> <xref target="RFC8174"></xref>
when, and only when, they appear in all capitals, as shown here.</t>
<t>Readers are encouraged to be familiar with the contents of <xref target="RFC5598"></xref>.
In particular, that document defines various roles in the messaging
infrastructure that can appear the same or separate in various contexts.
For example, a Domain Owner could, via the messaging mechanisms on which
BIMI is based, delegate reponsibility for providing preferred brand
indicators to a third party with another role.  This document does not
address the distinctions among such roles; the reader is encouraged to
become familiar with that material before continuing.</t>
<t>Syntax descriptions use Augmented BNF (ABNF) <xref target="RFC5234"></xref>.</t>
<t>&quot;Author Domain&quot;, &quot;Domain Owner&quot;, &quot;Organizational Domain&quot;, and &quot;Mail Receiver&quot;
are imported from DMARC <xref target="RFC7489"></xref> Section 3.</t>

<section anchor="bimi-assertion"><name>BIMI Assertion</name>
<t>The mechanism through which a Protocol Client verifies the BIMI Assertion
Record and constructs the URI(s) to the requested Indicator(s) to be placed
in the BIMI-Location header.</t>
</section>

<section anchor="indicator"><name>Indicator</name>
<t>The icon, logo, image, mark, or other graphical representation of the brand. The
Indicator is defined in a common image format with restrictions detailed in the
<eref target="#assertion-record-definition">Assertion Record Definition</eref>.</t>
</section>

<section anchor="mark-verifying-authority-mva"><name>Mark Verifying Authority (MVA)</name>
<t>An entity or organization that can provide evidence of verification of Indicators
asserted by a Domain Owner to Verifying Protocol Clients.  The MVA may choose to
uphold and confirm the meeting of certain Indicator standards (ie. size, trademark,
content, etc).</t>
</section>

<section anchor="bimi-evidence-document"><name>BIMI Evidence Document</name>
<t>A document published by a Mark Verifying Authority to assert evicence of verification.
These are defined in a separate document.</t>
</section>

<section anchor="verified-mark-certificate-vmc"><name>Verified Mark Certificate (VMC)</name>
<t>A certificate issued by a Certificate Authority in accordance with the Verified Mark
Certificate Guidelines.  These guidelines are defined in a separate document.</t>
<t>A Verified Mark Certificate is one example of a BIMI Evidence Document.</t>
</section>

<section anchor="protocol-client"><name>Protocol Client</name>
<t>An entity designed to obtain and correctly interpret the records defined in this
specification for the purpose of discovering and fetching published Indicators.</t>
</section>

<section anchor="verifying-protocol-client"><name>Verifying Protocol Client</name>
<t>A Protocol Client that uses optional capabilities to obtain and evaluate evidence
concerning the Domain Owner's rights to use the published Indicators.</t>
</section>
</section>

<section anchor="bimi-dns"><name>BIMI DNS Records</name>
<t>Domain owners publish BIMI policies by adding BIMI Assertion Records in the
DNS as TXT records.</t>
<t>Published policies are interpreted and applied by Protocol Clients.  A Domain Owner
signals intended BIMI participation for one or more of its domains by publishing an
Assertion Record in a subdomain under it.  In doing so, Domain Owners make specific
requests of MUAs regarding the preferred set of Indicators to be displayed with
messages that are confirmed to be authorized to appear from the Domain Owner's domain.</t>
<t>The use of BIMI is opt-in.  Receivers default to performing no BIMI-specific message
handling until they choose to do so, and then only if a BIMI record for the sender's
domain is found.</t>
<t>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 the DNS as the policy publication
service also has the benefit of reusing an extremely well-established operations,
administration, and management infrastructure, rather than creating a new one.</t>
<t>BIMI's policy payload is intentionally only published via a DNS record and not via
one or more email headers. This serves three purposes:</t>

<ol>
<li>There is one and only one mechanism for both simple and complex policies to be published.</li>
<li>Operational complexity is reduced.  MTAs only need to check a single record in a consistent
manner to discover and enforce policy.</li>
<li>Indicators SHOULD be verified and cached in advance, so that malicious headers cannot be
used as an attack vector.</li>
</ol>
<t>Per DNS <xref target="RFC1035"></xref>, a TXT record can comprise several &quot;character-string&quot; objects.
BIMI TXT records with multiple strings must be treated in an identical
manner to <eref target="https://tools.ietf.org/html/rfc7208#section-3.3">SPF Section 3.3</eref>.</t>

<section anchor="mua_guidance"><name>MUA Obligations</name>
<t>MUAs implementing the BIMI mechanism SHOULD make a best-effort attempt to adhere
to the Domain Owner's published BIMI policy.  However, MUAs have final control
over the user interface published to their end users, and MAY use alternate
Indicators than those specified in the BIMI assertion record or no Indicator at
all.</t>
</section>

<section anchor="assertion-record-definition"><name>Assertion Record Definition</name>
<t>All Domain Owner BIMI preferences are expressed in DNS TXT records published
in subdomains named &quot;_bimi&quot;.  Multiple sets of preferences can be associated
with a single RFC5322.From domain.  To distinguish between these different
preferences, BIMI defines and uses [selectors]{#selectors}. Senders declare
which selector to use for a given message by specifying the selector in an
optional <eref target="#bimi-selector">BIMI-Selector header</eref>.</t>
<t>For example, the Domain Owner of &quot;example.com&quot; would post BIMI policy in a
TXT record at &quot;default.<em>bimi.example.com&quot;.  Similarly, a Mail Receiver wishing
to query for BIMI policy regarding mail with an RFC5322.From Author Domain of
&quot;example.com&quot; and a selector &quot;default&quot; (the default) would query the TXT record
located at the subdomain of &quot;default.</em>bimi.example.com&quot;.  The DNS-based BIMI
policy record is referred to as the &quot;BIMI Assertion Record&quot; or &quot;Assertion
Record&quot;.</t>
<t>BIMI Assertion Records follow the extensible &quot;tag-value&quot; syntax for DNS-based
key records as defined in DKIM <xref target="RFC6376"></xref>.</t>
<t>Assertion Records are defined precisely. Mail receivers MUST NOT attempt to
fix syntactical or capitalization errors. If a required tag is missing, or
its value not well-formed, it is an error.</t>
<t>This section creates a registry for known BIMI tags and registers the initial
set defined in this document.  Only tags defined in this document or in later
extensions, and thus added to the registry, are to be processed; unknown tags
MUST be ignored.</t>
<t>The following tags are introduced as the initial valid BIMI tags:</t>
<t>v= Version (plain-text; REQUIRED).  Identifies the record retrieved as a BIMI
record.  It MUST have the value of &quot;BIMI1&quot; for implementations compliant with
this version of BIMI.  The value of this tag MUST match precisely; if it does
not match or it is absent, the entire retrieved record MUST be ignored.  It
MUST be the first tag in the list.</t>

<artwork>ABNF:

bimi-version = %x76 *WSP &quot;=&quot; *WSP %x42.49.4d.49 1DIGIT
</artwork>
<t>a= Authority Evidence Location (plain-text; URI; OPTIONAL).  If present, this
tag MUST have an empty value or its value MUST be a single URI.  An empty
value for the tag is interpreted to mean the Domain Owner does not wish to
publish or does not have authority evidence to disclose.  The URI, if present,
MUST contain a fully qualified domain name (FQDN) and MUST specify HTTPS as
the URI scheme (&quot;https&quot;).  The URI SHOULD specify the location of a publicly
retrievable BIMI Evidence Document. The format for evidence documents is
defined in a separate document.</t>
<t>If the a= tag is not present, it is assumed to have an empty value.</t>

<artwork>ABNF:

bimi-evidence-location = %x61 *WSP &quot;=&quot; bimi-uri

bimi-uri = \[FWS\] URI \[FWS\]

; &quot;URI&quot; is imported from [URI]
; HTTPS only
; commas within a URI (ASCII ; 0x2C) MUST be encoded
</artwork>
<t>l= location (URI; REQUIRED).  The value of this tag is either empty
indicating declination to publish, or a single URI representing the
location of a Brand Indicator file.  The only supported transport is HTTPS.</t>

<artwork>ABNF:

bimi-location = %x6c *WSP &quot;=&quot; bimi-uri
</artwork>
<t>Therefore, the formal definition of the BIMI Assertion Record, using ABNF <xref target="RFC5234"></xref>,
is as follows:</t>

<artwork>bimi-sep = *WSP %x3b *WSP

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
</artwork>

<section anchor="declination-to-publish"><name>Declination to Publish</name>
<t>If both the &quot;l=&quot; and &quot;a=&quot; tags are empty, it is an explicit refusal to
participate in BIMI. This is distinct from not publishing a BIMI record.
For example, an empty BIMI record enables a Domain Owner to decline BIMI
participation for a subdomain when its organizational domain has default
Indicators available. Furthermore, messages sent using a selector that
has declined to publish will not show an Indicator while messages with
other selectors would display normally.</t>
<t>An explicit declination to publish looks like:</t>

<artwork>v=BIMI1; l=; a=;
</artwork>
</section>

<section anchor="supported-image-formats-for-l-tag"><name>Supported Image Formats for l= tag</name>
<t>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 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 treated as a permanent
error.</t>
<t>As of the publishing of this document, only SVG and SVGZ, as defined in
<eref target="https://tools.ietf.org/html/rfc6170#section-5.2">RFC6170 section 5.2</eref>
is acceptable in the l= tag.  Further restrictions apply to the SVG;
these are documented elsewhere.</t>
</section>
</section>

<section anchor="selectors"><name>Selectors</name>
<t>To support publishing and display of more than one distinct Brand Indicator
per domain, the brand Indicator namespace is subdivided for publishing of
multiple Assertion Records using &quot;selectors&quot;.  Selectors allow the Domain
Owner to choose the brand Indicator, for example, by type of recipient, by
message source, or by other considerations like seasonal branding.  BIMI
selectors are modeled after
<eref target="https://tools.ietf.org/html/rfc6376#section-3.1">DKIM selectors</eref>.</t>
<t>The selector &quot;default&quot; is the default Assertion Record. Domain Owners can
specify which other selector to use on a per-message basis by utilizing
the <eref target="#bimi-selector">BIMI-Selector Header</eref>.</t>
<t>Periods are allowed in selectors and are component separators.  When BIMI
Assertion Records are retrieved from the DNS, periods in selectors define
DNS label boundaries in a manner similar to the conventional use in domain
names.  In a DNS implementation, this can be used to allow delegation of a
portion of the selector namespace.</t>

<artwork>ABNF:

selector = sub-domain *( &quot;.&quot; sub-domain )

; from [SMTP] Domain,

; excluding address-literal
</artwork>
<t>The number of selectors for each domain is determined by the Domain Owner.
Many Domain Owners will be satisfied with just one selector, whereas
organizations with more complex branding requirements can choose to manage
disparate selectors.  BIMI sets no maximum limit on the number of selectors.</t>
</section>
</section>

<section anchor="bimi-headers"><name>BIMI Header Fields</name>
<t>Once BIMI policies are published in DNS via Assertion Records, Domain Owners
can provide additional guidance to Mail Receivers, and Mail Receivers to their
MUAs through the use of BIMI header fields.</t>
<t>BIMI header fields are case insensitive. If a required tag is missing, it
is an error.</t>

<section anchor="bimi-selector"><name>BIMI-Selector Header</name>
<t>BIMI DNS records are placed in &lt;selector&gt;.<em>bimi.&lt;domain&gt;, and by default
they are placed in default.</em>bimi.&lt;domain&gt;. That is, for example.com, the
default Assertion Record is located in the DNS at default._bimi.example.com.
However, a Domain Owner may override the use of the default selector and
specify the use of an alternative using the RFC5322-compliant header
'BIMI-Selector'. The BIMI-Selector header consists of key value pairs:</t>
<t>v= Version (plain-text; REQUIRED). The version of BIMI. It MUST have the
value of &quot;BIMI1&quot; for implementations compliant with this version of BIMI.
The value of this tag MUST match precisely; if it does not or it is absent,
the entire retrieved record MUST be ignored.  It MUST be the first tag in
the list.</t>

<artwork>ABNF:

bimi-header-version = &quot;v&quot; *WSP &quot;=&quot; *WSP &quot;BIMI&quot; 1DIGIT
</artwork>
<t>s= Selector (plain-text; REQUIRED). The location of the BIMI DNS record,
when combined with the RFC5322.From domain.</t>

<artwork>ABNF:

bimi-selector = &quot;s&quot; *WSP &quot;=&quot; *WSP selector
</artwork>
<t>And the formal definition of the BIMI Selector Header, using ABNF, is as follows:</t>

<artwork>bimi-selector-header = bimi-header-version bimi-sep bimi-selector \[bimi-sep\]
</artwork>
</section>

<section anchor="bimi-location"><name>BIMI-Location Header</name>
<t>BIMI-Location is the header a Mail Receiver inserts that tells the MUA where
to get the BIMI Indicator from.</t>
<t>The syntax of the header is as follows:</t>
<t>v= Version (plain-text; REQUIRED). The version of BIMI. It MUST have the
value of &quot;BIMI1&quot; for implementations compliant with this version of BIMI.
The value of this tag MUST match precisely; if it does not or it is absent,
he entire header MUST be ignored.  It MUST be the first tag in the list.</t>

<artwork>The ABNF for bimi-header-version is imported exactly from the 
[BIMI Selector Header](#bimi-selector).
</artwork>
<t>l: location of the BIMI Indicator (URI; OPTIONAL if a
bimi-evidence-location-header-uri is specified, otherwise REQUIRED.). Inserted
by the MTA after performing the required checks and obtaining the applicable
domain's published Assertion Record.  The value of this tag is a URI representing
the location of the Brand Indicator file.  HTTPS is the only supported transport.</t>

<artwork>ABNF:

bimi-location-header-uri = &quot;l&quot; *WSP &quot;=&quot; bimi-uri
</artwork>
<t>a: location of the BIMI Evidence Document (URI; REQUIRED if the BIMI Evidence
Document was verified). Inserted by the MTA after performing the required checks
and obtaining the applicable domain's published Assertion Record.  The value of
this tag is a URI representing the location of the BIMI Evidence Document.
HTTPS is the only supported transport.</t>

<artwork>ABNF:

bimi-evidenced-location-header-uri = &quot;a&quot; *WSP &quot;=&quot; bimi-uri
</artwork>
<t>And the formal definition of the BIMI Location Header, using ABNF, is as
follows:</t>

<artwork>bimi-location-header-location-only = bimi-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-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\]
</artwork>
</section>

<section anchor="bimi-indicator"><name>BIMI-Indicator Header</name>
<t>BIMI-Indicator is the header a Mail Receiver inserts to pass a verified
Indicator to the MUA.</t>
<t>The header contains the SVG of the Indicator encoded as base64, and is
inserted by the MTA after performing the required checks and obtaining the
applicable domain's published Assertion Record.  The contents of this tag
MUST match the SVG Indicator content retrieved 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 file before base64 encoding.</t>

<artwork>base64string    =  ALPHADIGITPS *([FWS] ALPHADIGITPS)
                   [ [FWS] &quot;=&quot; [ [FWS] &quot;=&quot; ] ]
</artwork>
<t>And the formal definition of the BIMI Indicator Header, using ABNF, is as follows:</t>

<artwork>bimi-indicator-header = bimi-sep base64string \[bimi-sep\]
</artwork>
</section>

<section anchor="header-signing"><name>Header Signing</name>
<t>If present, the BIMI-Selector header SHOULD be included in the DMARC-aligned
DKIM signature used to confirm authenticity of the message.  If it is not
included in the DMARC-compliant DKIM signature, the header SHOULD be ignored.</t>
<t>Receivers MAY choose to apply additional methods to validate the BIMI-Selector
header, for example by evaluating a trusted [ARC] chain. In this case the
Receiver MAY choose to treat the message as if the BIMI-Selector header was
signed.</t>
<t>The BIMI-Location and BIMI-Indicator headers MUST NOT be DKIM signed. 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. Therefore, signing this
header is meaningless, and any messages with it signed are either coming from
malicious or misconfigured third parties.</t>
</section>
</section>

<section anchor="bimi-sender"><name>Domain Owner Actions</name>
<t>This section includes a walk through of the actions a Domain Owner takes when
setting up Assertion Records and sending email messages.</t>

<section anchor="determine-and-publish-indicator-s-for-use"><name>Determine and Publish Indicator(s) for Use</name>
<t>Domain Owners should consider which Indicator file formats to choose when
setting up their BIMI Assertion Records. For a Sender, BIMI provides control
over which Indicators are eligible and can be chosen for display, but not the
ultimate manner in which the MUA will display the Indicator.</t>
</section>

<section anchor="publish-assertion-records"><name>Publish Assertion Records</name>
<t>For each set of Indicators and domains, publish the appropriate Assertion
Record as either &quot;default&quot; or a named selector as a DNS TXT record within
the appropriate &quot;_bimi&quot; namespace.</t>
</section>

<section anchor="manage-multiple-uses-of-the-same-indicator-s-within-a-trust-boundary"><name>Manage multiple uses of the same Indicator(s) within a trust boundary</name>
<t>For Domain Owners with multiple domains that wish to share the same set
of Indicators within a trust boundary and only manage those Indicators
from a single DNS location, it is RECOMMENDED to use DNS CNAMEs.</t>
<t>Using a CNAME here is functionally similar to the SPF redirect modifier.
Since BIMI does not require l= tags to be aligned to the Author Domain,
CNAMEs present a cleaner solution than extending the protocol.</t>
</section>

<section anchor="set-the-headers-on-outgoing-email-as-appropriate"><name>Set the headers on outgoing email as appropriate</name>
<t>Once a default Assertion Record has been published for an Author Domain,
all emails from this domain should display the appropriate Indicator in
participating MUAs.</t>
<t>If a non-default Indicator is desired, the BIMI-Selector header should be
set appropriately. If for some reason this selector cannot be accessed by
the Protocol Client, the fallback is the default Assertion Record on the
Organization domain.</t>
<t>The BIMI-Location header MUST NOT be set by email senders, and Protocol
Clients MUST ignore it.</t>
</section>
</section>

<section anchor="receiver-actions"><name>Receiver Actions</name>
<t>This section includes a walk through of the actions a Protocol Client
takes when evaluating an email message for BIMI Assertion.</t>

<section anchor="authentication-requirements"><name>Authentication Requirements</name>
<t>Before applying BIMI processing for a message, a receiver MUST verify
that the message passed the following BIMI authentication requirements:</t>

<ol>
<li>If more than 1 RFC5322.From header is present in the message, or any
RFC5322.From header contains more than 1 email address then BIMI
processing MUST NOT be performed for this message.</li>
<li>Start with the DNS domain found in the RFC5322.From header in the
message.  Define this DNS domain as the Author Domain.</li>
<li>Find the Organizational Domain for the Author Domain. Define this
DNS domain as the Author Organizational Domain. If the Author Domain
is an Organizational Domain then this will be identical to the Author
Domain.</li>
<li>Evaluate the DMARC <xref target="RFC7489"></xref> result for the Author Domain.  Define
the result as the BIMI DMARC Result.</li>
<li>If the BIMI DMARC result is not 'pass', then the receiver MAY choose
to apply additional authentication methods, for example by evaluating
a trusted ARC <xref target="RFC8617"></xref> chain, a list of trusted forwarders, or by applying a
local policy. In this case the Receiver MAY choose to treat the message
as if the BIMI DMARC Result was 'pass'.</li>
<li>If the DMARC <xref target="RFC7489"></xref> result for the Author Domain is not 'pass', and the
message could not be authenticated by any additional authentication
method, then BIMI processing MUST NOT be performed for this message.</li>
<li>If the DMARC <xref target="RFC7489"></xref> policy for the Author Domain or Author Organizational
Domain is p=none then BIMI processing MUST NOT be performed for this
message.</li>
<li>If the DMARC <xref target="RFC7489"></xref> record for the Author Domain or Author Organizational
Domain includes a subdomain policy, and that subdomain policy is
sp=none then BIMI processing MUST NOT be performed for this message.</li>
<li>If the DMARC <xref target="RFC7489"></xref> policy for the Author Domain or Author Organizational
Domain is p=quarantine, and the DMARC <xref target="RFC7489"></xref> record defines a percentage
tag, then that tag MUST be pct=100, otherwise BIMI processing MUST
NOT be performed for this message.</li>
</ol>
</section>

<section anchor="assertion-record-discovery"><name>Assertion Record Discovery</name>
<t>Through the <eref target="#assertion-record-definition">BIMI Assertion Record</eref>, Domain
Owners use DNS TXT records to advertise their preferences.  Preference
discovery is accomplished via a method similar to the method used for
DMARC <xref target="RFC7489"></xref> records.  This method, and the important differences between
BIMI and DMARC <xref target="RFC7489"></xref> mechanisms, are discussed below.</t>
<t>Assertion Record Discovery MUST NOT be attempted if the message
authentication fails per Receiver policy.</t>
<t>To balance the conflicting requirements of supporting wildcarding, allowing
subdomain policy overrides, and limiting DNS query load, Protocol Clients
MUST employ the following lookup scheme for the appropriate BIMI record
for the message:</t>

<ol>
<li>Start with the DNS domain found in the RFC5322.From header in the message.
Define this DNS domain as the Author Domain.</li>
<li>If the message for which the Indicator is being determined specifies a
selector value in the <eref target="#bimi-selector">BIMI Selector Header</eref>, use this
value for the selector.  Otherwise the value 'default' MUST be used for
the selector.</li>
<li>Clients MUST query the DNS for a BIMI TXT record at the DNS domain constructed
by concatenating the selector, the string '_bimi', and the Author Domain.  A
possibly empty set of records is returned.</li>
<li>Records that do not start with a &quot;v=&quot; tag that identifies the current version
of BIMI MUST be discarded.</li>
<li>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 selector, the string '<em>bimi',
and the Organizational Domain (as defined in DMARC <xref target="RFC7489"></xref>) corresponding
to the Author Domain. A custom selector that does not exist falls back to
&lt;selector&gt;.</em>bimi.&lt;organizationalDomain&gt;.  A possibly empty set of records
is returned.</li>
<li>Records that do not start with a &quot;v=&quot; tag that identifies the current version
of BIMI MUST be discarded.</li>
<li>If the remaining set contains multiple records or no records, Assertion Record
Discovery terminates and BIMI processing MUST NOT be performed for this message.</li>
<li>If the remaining set contains only a single record, this record is used for BIMI
Assertion.</li>
</ol>
</section>

<section anchor="indicator-discovery"><name>Indicator Discovery.</name>

<ol>
<li>If the retrieved Assertion Record does not include a valid bimi-location in
the l= tag, then Indicator Discovery has failed, and the Indicator MUST NOT
be displayed. The bimi-location entry MUST be a URI with a HTTPS transport.</li>
<li>If the retrieved Assertion Record includes a bimi-evidence-location entry in
the a= tag, and the receiver supports BIMI Evidence Document validation, then
proceed to the
<eref target="#indicator-discovery-with-evidence">Indicator Discovery With Evidence</eref> step.</li>
<li>If the receiver does not support BIMI Evidence Document validation, or the
retrieved Assertion Record does not include a bimi-evidence-location entry,
then proceed to the
<eref target="#indicator-discovery-without-evidence">Indicator Discovery Without Evidence</eref> step.</li>
</ol>
</section>

<section anchor="indicator-discovery-with-evidence"><name>Indicator Discovery With Evidence.</name>
<t>Individual types of BIMI Evidence Document MAY specify extra discovery and
validation steps. These will be defined in separate documents.</t>
</section>

<section anchor="indicator-discovery-without-evidence"><name>Indicator Discovery Without Evidence.</name>
<t>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.</t>
<t>If an Assertion Record is found, and has an empty or missing bimi-evidence-location
entry then no evidence has is presented, and the Indicator MUST be retrieved from
the URI specified in the bimi-location entry using the following algorithm:</t>

<ol>
<li>Retrieve the SVG Indicator from the URI specified in the l= tag. This MUST be
a URI with a HTTPS transport.</li>
<li>If the TLS server identity certificate presented during the TLS session setup
does not chain-up to a root certificate the Client trusts then Indicator validation
has failed and the Indicator MUST NOT be displayed.</li>
<li>Proceed to the <eref target="#indicator-validation">Indicator Validation</eref> step.</li>
</ol>
</section>

<section anchor="indicator-validation"><name>Indicator Validation</name>

<ol>
<li>Check the file size of the retrieved Indicator against recommended maximum sizes
as defined in this document, and in the BIMI SVG document. A receiver MAY choose
to implement their own file size restrictions. If the Indicator is larger than
the maximum size the the receiver MAY choose not to display the Indicator. A
receiver MAY choose to implement the size limit as a retrieval limit rather than
retrieving the entire document and then checking the size.</li>
<li>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 displayed.</li>
<li>Check the retrieved Indicator against the SVG validation steps specified in this
document, and in the BIMI SVG document.
</li>
<li>If Indicator verification has passed, and the Indicator is from a trusted source,
then the Indicator MAY be displayed per receiver policy.
</li>
</ol>
</section>

<section anchor="bimi-results"><name>Affix BIMI Status to Authentication Results Header Field</name>
<t>Upon completion of Assertion Record Discovery, Indicator Discovery, and
Indicator Validation, an MTA SHOULD affix the result in the Authentication-Results
header using the following syntax, with the following key=value pairs:</t>
<t>bimi: Result of the bimi lookup (plain-text; REQUIRED). Range of values are
'pass' (BIMI successfully validated), 'none' (no BIMI record present),
'fail' (syntax error in the BIMI record, failure in Discovery or Validation
steps, or some other error), 'temperror' (DNS lookup problem), 'declined'
(The domain owner published an explicit declination record), or 'skipped'
(BIMI check was not performed, possibly because the message did not comply
with the minimum requirements such as passing DMARC, or the MTA does not
trust the sending domain). The MTA MAY put comments in parentheses after
bimi result, e.g., &quot;bimi=fail (Invalid SVG)&quot;, &quot;bimi=skipped (sender not
trusted)&quot; or &quot;bimi=skipped (message failed DMARC)&quot;.</t>
<t>header.d: Domain of the BIMI Assertion Record which was evaluated (plain-text;
REQUIRED if bimi=pass). For example, this will be the organizational domain
if the BIMI lookup used the fallback record, otherwise it will be the RFC5322.From domain.</t>
<t>header.selector: Selector of the BIMI Assertion Record which was evaluated
(plain-text; REQUIRED if bimi=pass). For example, if a BIMI-Selector Header
was present and used to discover a BIMI Assertion Record then this will be
the Selector used, otherwise this will be 'default'.</t>
<t>policy.authority: Authority verification status of the Brand Identifier
(plain-text; REQUIRED if the BIMI Evidence Document was checked). If the
Authority Evidence presented in the BIMI Assertion 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 Authority Evidence was presented, or
the MTA did not check the Authority Evidence then this SHOULD be set to none.</t>
<t>policy.authority-uri: The URI of the BIMI Evidence Document checked, as found
in the a= tag of the BIMI Assertion Record (plain-text; OPTIONAL).</t>
</section>

<section anchor="handle-existing-bimi-location-and-bimi-indicator-headers"><name>Handle Existing BIMI-Location and BIMI-Indicator Headers</name>
<t>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 either removed or renamed.
This is because the MTA performing BIMI-related processing immediately prior
to a Mail Delivery Agent (or within the same administrative realm) is the only
entity allowed to specify the BIMI-Location or BIMI-Indicator headers (e.g.
not the sending MTA, and not an intermediate MTA).  Allowing one or more
existing headers through to a MUA is a security risk.</t>
<t>If the original email message had a DKIM signature, it has already been evaluated.
Removing the BIMI-Location header at this point should not invalidate the signature
since it should not be included within it per this spec.</t>
</section>

<section anchor="construct-bimi-location-uri"><name>Construct BIMI-Location URI</name>
<t>This header MUST NOT be added if Discovery or Validation steps failed.</t>
<t>The URI used to retrieve the validated SVG Indicator. If the receiver extracted
the Indicator from the BIMI Evidence Document then 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 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 identical to the SVG Indicator extracted from the BIMI Evidence
Document.</t>
</section>

<section anchor="construct-bimi-indicator-header"><name>Construct BIMI-Indicator header</name>
<t>This header MUST NOT be added if Discovery or Validation steps failed.</t>
<t>Encode the SVG Indicator retrieved and validated during the Indicator
Discovery and Indicator Validation steps as base64 encoded data. If the
Indicator was compressed with gzip when retrieved then the data MUST be
uncompressed before being base64 encoded.</t>
<t>The MTA MUST fold the header to be within the line length limits of SMTP <xref target="RFC5321"></xref>.</t>
</section>
</section>

<section anchor="security-considerations"><name>Security Considerations</name>
<t>The consistent use of Brand Indicators is valuable for Domain Owners, Mail
Receivers, and End Users. However, the routine display of brand Indicators
represents an attractive target for abuse, especially for determined malicious
actors.  Great care is warranted.  The discussion following as an incomplete
list of considerations.</t>

<section anchor="indirect-mail-flows"><name>Indirect Mail Flows</name>
<t>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 already.  If the
receiving store trusts the other mail store, it may simply use existing headers.
Or, it may re-evaluate BIMI policy and requirements, and create or replace the
BIMI-Location header.</t>
</section>

<section anchor="lookalike-domains-and-copycat-indicators"><name>Lookalike Domains and Copycat Indicators</name>
<t>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 also need to have
a sufficiently strong reputation with the MTA.  The 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 apply its own reputation heuristics before deciding
whether or not to load the BIMI Indicator.  BIMI does not specify what MTAs may
bring to bear as additional factors.</t>
</section>

<section anchor="large-files-and-buffer-overflows"><name>Large files and buffer overflows</name>
<t>The MTA or MUA should perform some basic analysis and avoid loading 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 so it doesn't have to do it at
time-of-scan.</t>
</section>

<section anchor="slow-dns-queries"><name>Slow DNS queries</name>
<t>All email Receivers already have to query for DNS records, and all of them have
built-in timeouts when performing DNS queries.  Furthermore, the use of caching
when loading Indicators can help cut down on load time.  Virtually all email
clients have some sort of image-downloading built-in and make decisions when to
load or not load Indicators.</t>
</section>

<section anchor="unaligned-indicators-and-asserting-domains"><name>Unaligned Indicators and asserting domains</name>
<t>There is no guarantee that a group responsible for managing Brand Indicators will
have access to put these Indicators directly in any specific location of a domain,
and requiring that Indicators live on the asserted domain is too high a bar.
Additionally, letting a brand have Indicator locations outside its domain may be
desirable so that someone sending legitimate authenticated email on the Domain
Owner's behalf can manage and set selectors as an authorized third party without
requiring access to the Domain Owner's DNS or web services.</t>
</section>

<section anchor="unsigned-bimi-selector-header"><name>Unsigned BIMI-Selector Header</name>
<t>If a Domain Owner relies on SPF but not DKIM for email authentication, then adding
a requirement of DKIM may create too high of a bar for that sender.  On the other
hand, Receivers doing BIMI assertion may factor in the lack of DKIM signing when
deciding whether to add a BIMI-Location header.</t>
</section>

<section anchor="cgi-scripts-in-indicator-payload"><name>CGI scripts in Indicator payload</name>
<t>MTAs and MVAs should aggressively police Indicators to ensure they are the Indicators
they claim to be, are within appropriate size limits, and pass other sanity checks.
Additionally, MTAs might cache good Indicators and serve them directly to their MUAs,
which would in practice bypass any malicious dynamic payload set to trigger against
an end user but not an MTA.</t>
</section>

<section anchor="metadata-in-indicators"><name>Metadata in Indicators</name>
<t>Domain Owners should be careful to strip any metadata out of 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 data from Indicators before exposing them to end
users.</t>
</section>
</section>

<section anchor="iana"><name>IANA Considerations</name>
<t>IANA will need to reserve three new entries for the &quot;Permanent Message Header
Field Names&quot; registry and create a registry for support file formats for BIMI.</t>

<section anchor="permanent-header-field-updates"><name>Permanent Header Field Updates</name>
<t>Header field name: BIMI-Selector</t>
<t>Applicable protocol: mail</t>
<t>Status: standard</t>
<t>Author/Change controller: IETF</t>
<t>Specification document: This one</t>
<t>Header field name: BIMI-Location</t>
<t>Applicable protocol: mail</t>
<t>Status: standard</t>
<t>Author/Change controller: IETF</t>
<t>Specification document: This one</t>
<t>Header field name: BIMI-Indicator</t>
<t>Applicable protocol: mail</t>
<t>Status: standard</t>
<t>Author/Change controller: IETF</t>
<t>Specification document: This one</t>
</section>

<section anchor="registry-for-supported-bimi-formats"><name>Registry for Supported BIMI Formats</name>
<t>Names of support file types supported by BIMI must be registered by IANA.</t>
<t>New entries are assigned only for values that have been documented in a
published RFC that has had IETF Review, per [IANA-CONSIDERATIONS]. Each
method must register a name, the file extension, the specification that
defines it, and a description.</t>
</section>

<section anchor="other-iana-needs"><name>Other IANA needs</name>
</section>
</section>

</middle>

<back>
<references><name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5321.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5598.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6376.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7208.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7489.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8617.xml"/>
</references>
<references><name>Informative References</name>
<reference anchor="BIMI-OVERVIEW" target="http://tools.ietf.org/html/draft-bkl-bimi-overview-00.html">
  <front>
    <title>An Overview of the Design of BIMI</title>
    <author></author>
    <date></date>
  </front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>

<section anchor="bimi-header-examples"><name>Example Selector Discovery (INFORMATIVE)</name>
<t>This section shows several examples of how a receiving MTA should determine
which Assertion Record to use depending on the BIMI-Selector header.</t>

<section anchor="no-bimi-selector-header"><name>No BIMI-Selector Header</name>
<t>The domain example.com does not send with a BIMI-Selector header.</t>

<artwork>From: sender@example.com
</artwork>
<t>The MTA would lookup default._bimi.example.com for the BIMI DNS record.</t>
</section>

<section anchor="with-bimi-selector-header"><name>With BIMI-Selector Header</name>
<t>The domain example.com sends with a BIMI-Selector header:</t>

<artwork>From: sender@example.com
BIMI-Selector: v=BIMI1; s=selector;
</artwork>
<t>The MTA would lookup selector._bimi.example.com.</t>
</section>

<section anchor="without-bimi-selector-header-on-a-subdomain"><name>Without BIMI-Selector Header on a subdomain</name>
<t>The domain foo.example.com sends without a BIMI-Selector header:</t>

<artwork>From: sender@foo.example.com
</artwork>
<t>The MTA would lookup default.<em>bimi.foo.example.com for the BIMI DNS record.
If it did not exist, it would lookup default.</em>bimi.example.com.</t>
</section>

<section anchor="with-bimi-selector-header-on-a-subdomain"><name>With BIMI-Selector Header on a subdomain</name>
<t>The domain foo.example.com sends without a BIMI-Selector header:</t>

<artwork>From: sender@foo.example.com
BIMI-Selector: v=BIMI1; s=myselector;
</artwork>
<t>The MTA would lookup myselector.<em>bimi.foo.example.com for the BIMI DNS record.
If it did not exist, it would fall back to the lookup myselector.</em>bimi.example.com.</t>
</section>

<section anchor="invalid-bimi-selector-header"><name>Invalid BIMI-Selector Header</name>
<t>The domain example.com sends with a BIMI-Selector header, but does not include
the required field 'v=':</t>

<artwork>From: sender@example.com
BIMI-Selector: s=myselector;
</artwork>
<t>The MTA would ignore this header, and lookup default._bimi.example.com.</t>
</section>
</section>

<section anchor="ar-examples"><name>Example Authentication-Results entry (INFORMATIONAL)</name>
<t>This section shows example Authentication-Results stamps based on different
BIMI lookup statuses.</t>

<section anchor="successful-bimi-lookup"><name>Successful BIMI lookup</name>

<artwork>From: sender@example.com
BIMI-Selector: v=BIMI1; s=myselector;
Authentication-Results: bimi=pass header.d=example.com header.selector=myselector;
</artwork>
</section>

<section anchor="no-bimi-record"><name>No BIMI record</name>

<artwork>From: sender@sub.example.com
Authentication-Results: bimi=none;
</artwork>
<t>In this example, sub.example.com does not have a BIMI record at
default.<em>bimi.sub.example.com, nor does default.</em>bimi.example.com</t>
</section>

<section anchor="declination-to-publish-1"><name>Declination to Publish</name>

<artwork>From: sender@example.com
Authentication-Results: bimi=declined;
</artwork>
<t>In this example the record found at default._bimi.example.com was
&quot;v=BIMI1; l=; a=;&quot;, indicating a Declination to Publish a BIMI Assertion
Record, and so indicating that BIMI processing should not occur on this message.</t>
</section>

<section anchor="subdomain-has-no-default-record-but-organizational-domain-does"><name>Subdomain has no default record, but organizational domain does</name>

<artwork>From: sender@sub.example.com
Authentication-Results: bimi=pass header.d=example.com header.selector=default;
</artwork>
</section>

<section anchor="subdomain-and-orgznizational-domain-have-no-record-for-selector-but-organization"><name>Subdomain and orgznizational domain have no record for selector, but organization</name>
<t>domain has a default</t>

<artwork>From: sender@sub.example.com
BIMI-Selector: v=BIMI1; s=myselector;
Authentication-Results: bimi=none;
</artwork>
<t>In this example, the sender specified a DNS record at
myselector.<em>bimi.sub.example.com but it did not exist. The fallback is to
use myselector.</em>bimi.example.com, which also does not exist. 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.</t>
</section>

<section anchor="subdomain-has-no-record-for-selector-but-organization-domain-does"><name>Subdomain has no record for selector, but organization domain does</name>

<artwork>From: sender@sub.example.com
BIMI-Selector: v=BIMI1; s=myselector;
Authentication-Results: bimi=pass header.d=example.com header.selector=myselector;
</artwork>
<t>In this example, the sender specified a DNS record at myselector.<em>bimi.sub.example.com
but it did not exist. The fallback is to use myselector.</em>bimi.example.com.</t>
</section>
</section>

<section anchor="bimi-headers-example"><name>Example BIMI Headers Construction (INFORMATIONAL)</name>
<t>This section shows how an example MTA might evaluate an incoming email for BIMI
participation, and how it could share that determination with its MUA(s).</t>

<section anchor="mta-receives-an-email"><name>MTA Receives an email</name>
<t>The MTA receives the following DKIM signed message:</t>

<artwork>DKIM-Signature: v=1; s=myExample; d=example.com; h=From;BIMI-Selector;Date;bh=...;b=...
From: sender@example.com
BIMI-Selector: v=BIMI1; s=brand;
BIMI-Location: image.example.com/bimi/logo/example-bimi.svg
Subject: Hi, this is a message from the good folks at Example Learning
</artwork>
</section>

<section anchor="mta-does-its-authentication-checks"><name>MTA does its authentication checks</name>
<t>The receiving MTA receives the message and performs an SPF verification (which
fails), a DKIM verification (which passes), and a DMARC verification (which passes).
The domain is verified and has good reputation. The Receiver proceeds to perform a
BIMI lookup.</t>
</section>

<section anchor="mta-performs-bimi-assertion"><name>MTA performs BIMI Assertion</name>
<t>The MTA sees that the message has a BIMI-Selector header, and it is covered by
the DKIM-Signature, and the DKIM-Signature that passed DKIM is the one that covers
the BIMI-Selector header. The MTA sees the header validates and contains 'v=BIMI1',
and 's=brand'. It performs a DNS query for brand._bimi.example.com and retrieves:</t>

<artwork>brand._bimi.example.com IN TXT &quot;v=BIMI1; l=https://image.example.com/bimi/logo/&quot;
</artwork>
<t>The MTA verifies the syntax of the BIMI DNS record, and it, too passes.</t>
<t>The MTA knows it has previously retrieved the Indicator referenced by the BIMI DNS
record, and had already successfully checked this Indicator against the published
SVG profile. The MTA retrieves the Indicator from the cache.</t>
</section>

<section anchor="mta-appends-to-authentication-results"><name>MTA appends to Authentication-Results</name>
<t>The MTA computes and affixes the results of the BIMI to the Authentication-Results
header:</t>

<artwork>Authentication-Results: spf=fail smtp.mailfrom=example.com;
  dkim=pass (signature was verified) header.d=example.com;
  dmarc=pass header.from=example.com;
  bimi=pass header.d=example.com header.selector=brand;
</artwork>
</section>

<section anchor="mta-constructs-bimi-location-and-bimi-indicator-headers"><name>MTA Constructs BIMI-Location and BIMI-Indicator headers</name>
<t>The MTA base64 encodes the retrieved Indicator and constructs a new BIMI-Indicator
header.</t>
<t>The MTA constructs a BIMI-Location header with a version tag, and an l tag indicating
the URL from which the Indicator was retrieved.</t>
<t>Finally, the MTA removes any existing BIMI-Location and BIMI-Indicator headers, and
stamps the new ones:</t>

<artwork>BIMI-Location: v=BIMI1; l=https://image.example.com/bimi/logo/

BIMI-Indicator: PD94bW...8L3N2Zz4K
</artwork>
<t>That the original sender signed a BIMI-Location header against this spec is irrelevant.
It was used for DKIM validation and then thrown out by the MTA.</t>
</section>

<section anchor="the-mua-displays-the-indicator"><name>The MUA displays the Indicator</name>
<t>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-Indicator header. Finally, the MUA extracts the Indicator
from the BIMI-Indicator header and displays it to the user.</t>
</section>
</section>

<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>Many people have contributed to the development of BIMI.  Along with thanks to members of
the current AuthIndicators Working Group, the editors wish to acknowledge the efforts of
Sri Somanchi, Don Cardinal, Steve Jones, and John Levine.</t>
</section>

</back>

</rfc>