BIMI on an Independent MUA

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 22 December 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Brand Indicators for Message Identification (BIMI) describes a method to enable Domain Owners to coordinate with Mailbox Providers (MBPs), Mail Transfer Agents (MTAs), and Mail User Agents (MUAs) in the display of brand-specific Indicators (e.g., logos) next to properly authenticated messages.¶

BIMI relies on DMARC, which in turn relies on one of SPF or DKIM validation for the message in question, and it is generally accepted that an MTA is best positioned to do the SPF and DKIM validation that underpin DMARC since it has the access to the data necessary for such validation. An MUA almost certainly cannot perform SPF validation on a message, as it will not know the sending IP of the message (short of attempting to interpret Received headers), and an MUA could only perform DKIM validation on a message if the MTA has not altered the DKIM-protected parts of the message. This makes the simplest path to the display of a BIMI Indicator one where the MTA performs the required checks for DMARC and BIMI and records the results of those checks in a way that can be accessed by the MUA.¶

BIMI makes no requirement that the MTA handling a message and the MUA reading and displaying it are operated by the same entity. In cases where a mailbox holder uses their MBP's MUA to read the contents of their mailbox, it is a relatively simple matter for the MTA and MUA to interoperate in a way in which the display of the BIMI Indicator can be controlled by the MBP.¶

What is less simple is the interoperability between an MBP's MTAs and message stores and an independent, or third-party, MUA. In this scenario, there must exist a standard way for an MTA to communicate BIMI and DMARC validation results to the MUA in a way that can be verified by the MUA. In addition, the MBP through its message store may desire to be able to indicate that a BIMI Indicator and/or its Evidence Document has been revoked if circumstances require.¶

This document describes a method for achieving interoperability between a MBP's MTAs and message stores, and a third-party MUA. Without this link, an attacker could potentially insert messages with existing headers through some other means, SMTP and IMAP are examples here. Using this verifiable method allows for the MUA to understand the validation at the MTA layer.¶

2. Validation Information

The receiving entity may add two headers, BIMI-Location and BIMI-Indicator. These two headers are meant to aid the MUA with the location of the BIMI-related information, as well as base64-encoded SVG image data. They could also insert an Authentication-Results header at this stage.¶

Additionally, a receiver employing this method MUST add another header to the message, BIMI-Receiver-Information. This will contain a date-time (from [RFC5322]), and sha256-encoded hash from the local part of the recipient, and then the domain (From the RFC5321 RCPT TO command):¶

BIMI-Receiver-Information: date: date-time ; rcpt: sha256-local @ domain¶

date-time: RFC5322¶

domain: RFC5321¶

sha256-local: 64( HEXDIG )¶

An example might be:¶

BIMI-Receiver-Information: date: Tue, 25 Feb 2023 01:05:55 +0000 ;
rcpt: 6d9010b2b7a1483b256ae7477738dba7c530bd9ba53db1d6691441e74b83608a@isp.net¶

A MBP may choose to add this data without the signature specified below. However, as the data cannot be verified via the signature, the MUA may find the data within the header unsatisfactory to be used.¶

NOTE: Changed to 5321, instead of 5322¶

3. BIMI-Receiver-Signature

The MTA or other entity that performed the BIMI validation of the message MUST, if the message passed all BIMI validation checks, insert a BIMI-Receiver-Signature header constructed in a manner consistent with the creation of a DKIM-Signature header as defined in [RFC6376]. This header MUST include all the BIMI-Location, BIMI-Selector, and BIMI-Receiver-Information headers as headers that were signed by this signature. Additionally, the signer should oversign the headers included as part of this signature as defined in [RFC6376].¶

CLARIFICATION: Is this Receiver-Signature header useful without the other headers? Today, not all MBPs insert these headers. Can this still be useful?¶

This signature will be validated by the MUA in the same manner that a DKIM-Signature header is validated, and successful validation of this header will indicate that the receiving domain inserted the signed headers.¶

The public key to support this signing activity will be published in the DNS at a location one or more levels below the name "_bimi.signingDomain", where "signingDomain" is the domain associated with the address in the RCPT TO command. By utilizing a different "namespace", this prevents this particular key from being used in DKIM Replay attacks. For example, an MBP named "isp.net" might publish its public key at "sel_sign._local._bimi.isp.net". For the purposes of this document, we will refer to "sel_sign" as the "True Selector".¶

The selector specified in the s= tag of this signature will be a pseudo-selector constructed by prepending the FQDN domain from the the BIMI discovery to the "True Selector". In the INFORMATIVE EXAMPLE of a BIMI-Receiver-Signature header shown below, the s= tag is assigned the value "marketing.example.org.sel_sign", which means that the BIMI information for the message was found at the domain "marketing.example.org".¶

DISCUSS: Terminology around which domain is used above, and how we reference it.¶

DISCUSS: Other headers? Other information?¶

BIMI-Receiver-Signature: v=BIMI1; d=isp.net; s=marketing.example.org.sel_sign; c=canonicalization; h=BIMI-Location:BIMI-Selector:BIMI-Receiver-Information; b=<SIGNATURE_BLOB>; t=timestamp¶

The public key used for validation by the MUA would be:¶

marketing.example.org.sel_sign._local._bimi.isp.net¶

The mechanics of the public key publishing are covered in sections below.¶

4. MUA Validation

NOTE: Stub, needs elaboration¶

As with DKIM, the MUA will use the cryptographic signature to validate the protected contents. Additionally, the MUA may use a sha-256 hash to validate the message and signature are meant for the recipient using the MUA. By validating the recipient, this could aid with replay protection.¶

5. Revocation

There could exist any number of reasons for a receiving entity to no longer desire to display iconography related to a given sending domain. This could include certificate revocation from the CA, diminished local reputation, extensive abuse reports, certificate expiration, or anything else.¶

In the case where this happens, the MBP (again, isp.net) can publish a NULL record at the location where the domain would normally match a wildcard. The MBP may optionally choose to include a string as to the reason for revocation by utilizing the r tag in the record. If we also use marketing.example.org with a selector of "foo", this MUST appear as:¶

foo._s.marketing.example.org.sel_sign._local._bimi.isp.net TXT 'v=BIMI1;' foo._s.marketing.example.org.sel_sign._local._bimi.isp.net TXT 'v=BIMI1;"r=Reason String;"'¶

The DNS response MUST not include a functional public key that could be used to validate the signature. If compared to the wildcard DNS entry defined earlier, there will no longer be a public key that can be used for validation. The DNS record MUST contain only a v tag, MAY contain an optional r tag, and MUST NOT contain a p (public key) tag.¶

This should ensure the MUA is no longer able to retrieve the public keys necessary to validate the signature. In this case, the MUA MUST NOT utilize the headers, even though they do still exist in the stored message.¶

See the Appendix for how revocation would look in practice.¶

6. Security Considerations

7. Other Considerations

8. Appendix A

For purposes below, sending is marketing.example.org, MBP is isp.net, and selector is sel_sign.¶

9. Contributors

10. Notes

11. TODO

• Cleanup notes¶
• Missing a number of references¶
• Enhance MUA Validation stub¶

12. References

Author's Address