https://bugs.exim.org/show_bug.cgi?id=3069
--- Comment #5 from Andrew Aitchison <exim@???> ---
Andreas:
> BIMI is supposed to be a modern invention that relies on DMARC
> and digital certificates for proof brand ownership.
> If it could be broken by including an arbitrary header
> it would be useless.
I could agree, but the one-line change to the Exim config (which is commented
out in the patch) is something which the draft standard says MUST be done
https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/
7.8. Handle Existing BIMI-Location and BIMI-Indicator Headers
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.
This standard is in use by some big players who think in terms of in-house web
mail user agents tied into their back-ends. Standalone MUAs are not at the
front of their thinking. The standard envisages the MTA doing all the verifying
and the MUA being able to trust it. Privacy is suggested as one reason for the
MUA not to make the checks itself.
If we don't at least document this option, once an MUA like Thunderbird
supports BIMI, I see a real risk to our users. This patch could head the risk
off before it comes.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## subscription configuration (requires account):
##
https://lists.exim.org/mailman3/postorius/lists/exim-dev.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-dev-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
