https://bugs.exim.org/show_bug.cgi?id=3069
--- Comment #5 from Andrew Aitchison <[email protected]> --- 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): ## [email protected] ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
