Mailing List Archive

https://bugs.exim.org/show_bug.cgi?id=3069

Jeremy Harris <jgh146exb@wizmail.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|Exim 4.97 |Exim 4.98
Version|4.98 |4.97

--- Comment #2 from Jeremy Harris <jgh146exb@wizmail.org> ---
I'm not sure whether this really belongs as part of exim, beyond possibly
being documented somewhere.

If it's only stripping a specific few headers, by name, we surely already test
for that elsewhere in the testsuite.

So possibly moot:

I'm unclear how much the patch here is dependent on dkim and dmarc.
The testcase seems to assume them but I suspect the patch is entirely
independent. That could be tidied up.

Also, the testcase log seems to accept a message but never deliver it,
yet one appears in the test/mail/ dir.

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3069

--- Comment #3 from Andrew Aitchison <exim@aitchison.me.uk> ---
(In reply to Jeremy Harris from comment #2)
> I'm not sure whether this really belongs as part of exim, beyond possibly
> being documented somewhere.

The test is real, but everything else is just documentation.
The action is in the sample config, but commented out.

In theory these headers are only added on final delivery when the final MTA
calculates and verifies them (using DMARC and more DNS and https
so I don't envisage we will ever do this).
The attack is to set them maliciously and have the MUA display the icon.
The draft requests that MTAs remove the headers to protect against this.
Since Google and Yahoo! now support BIMI, if, say Thunderbird, implements
it too it would be nice to protect our users.

> If it's only stripping a specific few headers, by name, we surely already
> test for that elsewhere in the testsuite.

The draft says that these headers should *not* be signed.
I wanted to test that we don't break DKIM by removing them,
thus losing messages.

I don't really have a problem if you think the existing tests are
sufficient. I put this one in for completeness and practice.

> So possibly moot:
>
> I'm unclear how much the patch here is dependent on dkim and dmarc.
> The testcase seems to assume them but I suspect the patch is entirely
> independent. That could be tidied up.

BIMI requires dmarc, but you are right we could remove dmarc from the test.

I'd like to use dkim in the test if it is available, but still test
if it is not. Is that possible ?

> Also, the testcase log seems to accept a message but never deliver it,
> yet one appears in the test/mail/ dir.

If I change the file test/mail/4640 then
runtest 4640
complains. I thought that was the delivery.
What have I missed ?

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3069

--- Comment #4 from Andreas Metzler <eximusers@bebt.de> ---
Hello,

I would argue against including this. There is considerable cost on both
exim-user's (doc size decreases accessibility) and developer's side for size
increase. (maintainance).

OTOH the whole thing's the benefit seems to be non-existent to negligible. 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.

cu Andreas

--
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

https://bugs.exim.org/show_bug.cgi?id=3069

--- Comment #5 from Andrew Aitchison <exim@aitchison.me.uk> ---
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@lists.exim.org
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/