Subject: [Bimi] What if DKIM doesn't validate the selector header.

From: Zack Aab <[email-masked]>
Date: Wed, 28 Apr 2021 16:06:39 -0400

I was reading section 5.4 of the document and it's pretty clear what to do
if the selector header (BIMI-selector) is not included in the DMARC-aligned
DKIM signature: treat it as if there is no selector header and move on to
default._bimi.
BUT
What if the DKIM signature includes the BIMI-selector header but doesn't
pass validation AND DMARC still passes via SPF?
It seems to me (given DKIM's normal use - a broken signature should be
treated as not having a signature) that the receiver should treat the
BIMI-selector header as unsigned and move on to default._bimi, but it's not
actually stated one way or the other, so the response from the receiver
could be to stop BIMI validation entirely.

*Zack Aab* (He/Him)
Senior Consultant, Trendline Interactive
*O* +1 (512) 717-4097 <+15127174097> | *C* +1 (404) 317-6729 <+14043176729>
| *W* trendlinei.com <https://www.trendlineinteractive.com/>

---

From: Jakub Olexa <[email-masked]>
Date: Thu, 29 Apr 2021 08:26:33 +0200

Hi,

In my opinion if DKIM fails to validate the message content the MBP 
should not display the BIMI at all (no matter why the DKIM failed). The 
reasoning for this is that SPFs validate shared infrastructures (OL365, 
GSuite, etc) and as such domains can be spoofed while DKIM authenticates 
the actual content. BIMI logos being displayed on the message list (see 
Yahoo mail app) they become sort of a "From" indicator from the users 
perspective and over time will become sort of a trust indicator. BIMI 
should make every effort on the standard level to discourage any use of 
BIMI that failed a critical validation of the message body as that alone 
could be an abuse vector.

If a phishing operation targets businesses that are using shared 
infrastructures and have BIMI, they could achieve quite a significant 
success if the messages get highlighted with a logo while failing DKIM. 
This would undermine BIMI in a major way and DKIM as well.

Jakub Olexa
Founder & CEO
E-mail: [email-masked] <mailto:[email-masked]>
Tel: +420 777 744 440 <tel:+420777744440>

Mailkit - Closing the circle between Deliverability and Engagement 
<https://www.mailkit.com>

On 28.04.2021 22:06, Zack Aab wrote:
> I was reading section 5.4 of the document and it's pretty clear what 
> to do if the selector header (BIMI-selector) is not included in the 
> DMARC-aligned DKIM signature: treat it as if there is no selector 
> header and move on to default._bimi.
> BUT
> What if the DKIM signature includes the BIMI-selector header but 
> doesn't pass validation AND DMARC still passes via SPF?
> BIMI-selector header as unsigned and move on to default._bimi, but 
> it's not actually stated one way or the other, so the response from 
> the receiver could be to stop BIMI validation entirely.
>
> *Zack Aab* (He/Him)
> *O* +1 (512) 717-4097 <tel:+15127174097> | *C* +1 (404) 317-6729 
> <tel:+14043176729> | *W* trendlinei.com 
> <https://www.trendlineinteractive.com/>
>

---

From: "Marc Bradshaw" <[email-masked]>
Date: Thu, 29 Apr 2021 16:55:57 +1000

Hi,

Opinion: This feels like a discussion outside the scope of BIMI, SPF forgery is a known issue ref the recent Multipass attack at a well known vendor. There is a related note in the "Unsigned BIMI-Selector Header" section of the spec.
We do see senders with p=reject who rely entirely on SPF and do not DKIM sign at all, I would argue that the problem being described here is more about vulnerabilities in some shared infrastructure platforms and not about how BIMI should be implemented. At the very least, I would expect that discussion to take place in the DMARC group, and that BIMI should take the DMARC result as is as much as is possible, without imposing additional constraints over what constitutes a valid DMARC pass or fail.
MBPs are, of course, free to implement whatever additional constraints they see fit, but I don't feel that this one belongs in BIMI.

> In my opinion if DKIM fails to validate the message content the MBP should not display the BIMI at all (no matter why the DKIM failed). The reasoning for this is that SPFs validate shared infrastructures (OL365, GSuite, etc) and as such domains can be spoofed while DKIM authenticates the actual content. BIMI logos being displayed on the message list (see Yahoo mail app) they become sort of a "From" indicator from the users perspective and over time will become sort of a trust indicator. BIMI should make every effort on the standard level to discourage any use of BIMI that failed a critical validation of the message body as that alone could be an abuse vector.

> If a phishing operation targets businesses that are using shared infrastructures and have BIMI, they could achieve quite a significant success if the messages get highlighted with a logo while failing DKIM. This would undermine BIMI in a major way and DKIM as well.

> Jakub Olexa
> Founder & CEO
> E-mail: [email-masked]
> Mailkit - Closing the circle between Deliverability and Engagement <https://www.mailkit.com/>

>> I was reading section 5.4 of the document and it's pretty clear what to do if the selector header (BIMI-selector) is not included in the DMARC-aligned DKIM signature: treat it as if there is no selector header and move on to default._bimi.
>> BUT
>> What if the DKIM signature includes the BIMI-selector header but doesn't pass validation AND DMARC still passes via SPF?
>> It seems to me (given DKIM's normal use - a broken signature should be treated as not having a signature) that the receiver should treat the BIMI-selector header as unsigned and move on to default._bimi, but it's not actually stated one way or the other, so the response from the receiver could be to stop BIMI validation entirely.
>> 
>> 
>> *Zack Aab* (He/Him)
>> *O* +1 (512) 717-4097 <tel:+15127174097> | *C* +1 (404) 317-6729 <tel:+14043176729> | *W* trendlinei.com <https://www.trendlineinteractive.com/>
> -- 
> bimi mailing list
> [email-masked] <mailto:bimi%40ietf.org>
> https://www.ietf.org/mailman/listinfo/bimi
> 

--

  Marc Bradshaw
  marcbradshaw.net | @marcbradshaw <https://twitter.com/marcbradshaw>

---

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 29 Apr 2021 15:19:28 +0000

I'm not entirely sure that answers the original question.  I don't think the OP is an attempt to second guess DMARC. Seems more a question about should a receiver go to default._bimi (or something else) if the selector is specified but seems unusable (either not signed or signature fails).  If we believe the sections A.1/A.5 covers this scenario, perhaps we just need a little embellishment on this scenario below to be more explicit.  And yes, local policy can impact this.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: bimi <[email-masked]> On Behalf Of Marc Bradshaw
Sent: Thursday, April 29, 2021 2:56 AM
To: [email-masked]
Subject: Re: [Bimi] What if DKIM doesn't validate the selector header.

Hi,

Hi,

If a phishing operation targets businesses that are using shared infrastructures and have BIMI, they could achieve quite a significant success if the messages get highlighted with a logo while failing DKIM. This would undermine BIMI in a major way and DKIM as well.
Jakub Olexa
Founder & CEO
E-mail: [email-masked]<mailto:[email-masked]>
Tel: +420 777 744 440<tel:+420777744440>

Mailkit - Closing the circle between Deliverability and Engagement<https://urldefense.com/v3/__https:/www.mailkit.com__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A1DGUptw$>

Zack Aab (He/Him)
Senior Consultant, Trendline Interactive
O +1 (512) 717-4097<tel:+15127174097> | C +1 (404) 317-6729<tel:+14043176729> | W trendlinei.com<https://urldefense.com/v3/__https:/www.trendlineinteractive.com/__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A2tiXW_Y$>
--
bimi mailing list
[email-masked]<mailto:bimi%40ietf.org>
https://www.ietf.org/mailman/listinfo/bimi<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A3P4VcGQ$>

--
[https://secure.gravatar.com/avatar/b214a020f4eb135ce2a6901d7540bdb1?s=44&d=404]

  Marc Bradshaw
  marcbradshaw.net<https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3Ajv1deoc$> | @marcbradshaw<https://urldefense.com/v3/__https:/twitter.com/marcbradshaw__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3AYnziQXA$>

---

From: Zack Aab <[email-masked]>
Date: Thu, 29 Apr 2021 11:45:51 -0400

Hi,
>Seems more a question about should a receiver go to default._bimi (or
something else) if the selector is specified but seems unusable (either not
signed or signature fails).
This is it exactly.  Maybe I missed something, but as written there is no
suggested or required action if the receiver sees that the BIMI-selector is
DKIM signed but that DKIM fails to validate.  This can probably be covered
with one line in section 5.4, it's just a question of "should the receiver
skip to default._bimi. or skip BIMI entirely?"
Thanks!
*Zack Aab* (He/Him)
Senior Consultant, Trendline Interactive
*O* +1 (512) 717-4097 <+15127174097> | *C* +1 (404) 317-6729 <+14043176729>
| *W* trendlinei.com <https://www.trendlineinteractive.com/>

On Thu, Apr 29, 2021 at 11:19 AM Brotman, Alex <Alex_Brotman=
[email-masked]> wrote:

> I’m not entirely sure that answers the original question.  I don’t think
> the OP is an attempt to second guess DMARC. Seems more a question about
> should a receiver go to default._bimi (or something else) if the selector
> is specified but seems unusable (either not signed or signature fails).  If
> we believe the sections A.1/A.5 covers this scenario, perhaps we just need
> a little embellishment on this scenario below to be more explicit.  And
> yes, local policy can impact this.
>
>
>
> --
>
> Alex Brotman
>
> *From:* bimi <[email-masked]> *On Behalf Of * Marc Bradshaw
> *Sent:* Thursday, April 29, 2021 2:56 AM
> *To:* [email-masked]
> *Subject:* Re: [Bimi] What if DKIM doesn't validate the selector header.
>
>
>
> Hi,
>
>
>
> Opinion: This feels like a discussion outside the scope of BIMI, SPF
> forgery is a known issue ref the recent Multipass attack at a well known
> vendor. There is a related note in the "Unsigned BIMI-Selector Header"
> section of the spec.
>
> We do see senders with p=reject who rely entirely on SPF and do not DKIM
> sign at all, I would argue that the problem being described here is more
> about vulnerabilities in some shared infrastructure platforms and not about
> how BIMI should be implemented. At the very least, I would expect that
> discussion to take place in the DMARC group, and that BIMI should take the
> DMARC result as is as much as is possible, without imposing additional
> constraints over what constitutes a valid DMARC pass or fail.
>
> MBPs are, of course, free to implement whatever additional constraints
> they see fit, but I don't feel that this one belongs in BIMI.
>
>
>
> In my opinion if DKIM fails to validate the message content the MBP should
> not display the BIMI at all (no matter why the DKIM failed). The reasoning
> for this is that SPFs validate shared infrastructures (OL365, GSuite, etc)
> and as such domains can be spoofed while DKIM authenticates the actual
> content. BIMI logos being displayed on the message list (see Yahoo mail
> app) they become sort of a "From" indicator from the users perspective and
> over time will become sort of a trust indicator. BIMI should make every
> effort on the standard level to discourage any use of BIMI that failed a
> critical validation of the message body as that alone could be an abuse
> vector.
>
> Tel: +420 777 744 440 <+420777744440>
>
>
>
> *Mailkit - *Closing the circle between Deliverability and Engagement
> <https://urldefense.com/v3/__https:/www.mailkit.com__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A1DGUptw$>
>
> *O* +1 (512) 717-4097 <+15127174097> | *C* +1 (404) 317-6729
> <+14043176729> | *W* trendlinei.com
> <https://urldefense.com/v3/__https:/www.trendlineinteractive.com/__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A2tiXW_Y$>
>
> --
>
> bimi mailing list
>
> [email-masked]
>
> <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A3P4VcGQ$>
>
>
>
>
>
> --
>
>   Marc Bradshaw
>
>   marcbradshaw.net
> <https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3Ajv1deoc$>
> | @marcbradshaw
> <https://urldefense.com/v3/__https:/twitter.com/marcbradshaw__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3AYnziQXA$>
>
>
>
>
> --
> bimi mailing list
> [email-masked]

---

From: "Marc Bradshaw" <[email-masked]>
Date: Fri, 30 Apr 2021 11:33:59 +1000

Hi,

I see what you are saying, this is the section...

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.

In the absence of a clear statement of what should happen if the BIMI-Selector is included in a failing DKIM signature I had read (and implemented) this as ignoring this header unless it has a valid DKIM signature, but not considering a failed signature as a blocker if DMARC passes for some other reason, either SPF, or the presence of a second passing DKIM signature for the same domain.

I propose the modification of this section to state that failing DKIM signatures SHOULD be ignored, but BIMI processing SHOULD continue.
The use of SHOULD in this section was intended to cover the cases where MBPs did not implement this check, however I would be happy to make these checks a MUST, what is the opinion of the group?

On Fri, 30 Apr 2021, at 1:45 AM, Zack Aab wrote:
> Hi,
> >Seems more a question about should a receiver go to default._bimi (or something else) if the selector is specified but seems unusable (either not signed or signature fails).
> This is it exactly.  Maybe I missed something, but as written there is no suggested or required action if the receiver sees that the BIMI-selector is DKIM signed but that DKIM fails to validate.  This can probably be covered with one line in section 5.4, it's just a question of "should the receiver skip to default._bimi. or skip BIMI entirely?"
> Thanks!
> *Zack Aab* (He/Him)
> On Thu, Apr 29, 2021 at 11:19 AM Brotman, Alex <Alex_Brotman=[email-masked]> wrote:
>> I’m not entirely sure that answers the original question.  I don’t think the OP is an attempt to second guess DMARC. Seems more a question about should a receiver go to default._bimi (or something else) if the selector is specified but seems unusable (either not signed or signature fails).  If we believe the sections A.1/A.5 covers this scenario, perhaps we just need a little embellishment on this scenario below to be more explicit.  And yes, local policy can impact this.____

>> __ __

>> --____

>> Alex Brotman____

>> Sr. Engineer, Anti-Abuse & Messaging Policy____

>> Comcast____

>> __ __

>> *Subject:* Re: [Bimi] What if DKIM doesn't validate the selector header.____

>> __ __

>> Hi,____

>> __ __

>> Opinion: This feels like a discussion outside the scope of BIMI, SPF forgery is a known issue ref the recent Multipass attack at a well known vendor. There is a related note in the "Unsigned BIMI-Selector Header" section of the spec.____

>> We do see senders with p=reject who rely entirely on SPF and do not DKIM sign at all, I would argue that the problem being described here is more about vulnerabilities in some shared infrastructure platforms and not about how BIMI should be implemented. At the very least, I would expect that discussion to take place in the DMARC group, and that BIMI should take the DMARC result as is as much as is possible, without imposing additional constraints over what constitutes a valid DMARC pass or fail.____

>> MBPs are, of course, free to implement whatever additional constraints they see fit, but I don't feel that this one belongs in BIMI.____

>> __ __

>> On Thu, 29 Apr 2021, at 4:26 PM, Jakub Olexa wrote:____

>>> Hi,____

>>> In my opinion if DKIM fails to validate the message content the MBP should not display the BIMI at all (no matter why the DKIM failed). The reasoning for this is that SPFs validate shared infrastructures (OL365, GSuite, etc) and as such domains can be spoofed while DKIM authenticates the actual content. BIMI logos being displayed on the message list (see Yahoo mail app) they become sort of a "From" indicator from the users perspective and over time will become sort of a trust indicator. BIMI should make every effort on the standard level to discourage any use of BIMI that failed a critical validation of the message body as that alone could be an abuse vector.____

>>> If a phishing operation targets businesses that are using shared infrastructures and have BIMI, they could achieve quite a significant success if the messages get highlighted with a logo while failing DKIM. This would undermine BIMI in a major way and DKIM as well.____

>>> Jakub Olexa____

>>> Founder & CEO____

>>> E-mail: [email-masked]

>>> Tel: +420 777 744 440 <tel:+420777744440> __ __

>>> __ __

>>> *Mailkit - *Closing the circle between Deliverability and Engagement <https://urldefense.com/v3/__https:/www.mailkit.com__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A1DGUptw$>____

>>> On 28.04.2021 22:06, Zack Aab wrote:____

>>>> I was reading section 5.4 of the document and it's pretty clear what to do if the selector header (BIMI-selector) is not included in the DMARC-aligned DKIM signature: treat it as if there is no selector header and move on to default._bimi.____

>>>> BUT____

>>>> What if the DKIM signature includes the BIMI-selector header but doesn't pass validation AND DMARC still passes via SPF?____

>>>> It seems to me (given DKIM's normal use - a broken signature should be treated as not having a signature) that the receiver should treat the BIMI-selector header as unsigned and move on to default._bimi, but it's not actually stated one way or the other, so the response from the receiver could be to stop BIMI validation entirely.____

>>>> __ __

>>>> __ __

>>>> *O* +1 (512) 717-4097 <tel:+15127174097> | *C* +1 (404) 317-6729 <tel:+14043176729> | *W* trendlinei.com <https://urldefense.com/v3/__https:/www.trendlineinteractive.com/__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A2tiXW_Y$>____

>>> -- ____

>>> bimi mailing list____

>>> [email-masked] <mailto:bimi%40ietf.org>____

>>> https://www.ietf.org/mailman/listinfo/bimi <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/bimi__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3A3P4VcGQ$>____

>>> __ __

>> __ __

>> --____

>> ____

>>   Marc Bradshaw____

>>   marcbradshaw.net <https://urldefense.com/v3/__http:/marcbradshaw.net/__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3Ajv1deoc$> | @marcbradshaw <https://urldefense.com/v3/__https:/twitter.com/marcbradshaw__;!!CQl3mcHX2A!WQ-21HMjp9kg9GakwBT_pAPcHXM38K2yUd_r1iIZYfE97a34wAqfUMixJXuGcn3AYnziQXA$>____

>> __ __

>> __ __

--

  Marc Bradshaw

---

From: Jakub Olexa <[email-masked]>
Date: Fri, 30 Apr 2021 08:44:20 +0200

If the logic relies only on DMARC authenticating rather than DKIM pass 
then what is the abuse risk if the BIMI-Selector header is unsigned? You 
trust the source domain, the BIMI record comes from that "trusted 
source" and there was a clear intent from the sender for a specific 
selector. I'd suggest a binary choice here - either MUST or no signature 
requirement for the selector at all.

Jakub Olexa
Founder & CEO

On 30.04.2021 3:33, Marc Bradshaw wrote:
> In the absence of a clear statement of what should happen if the 
> BIMI-Selector is included in a failing DKIM signature I had read (and 
> implemented) this as ignoring this header unless it has a valid DKIM 
> signature, but not considering a failed signature as a blocker if 
> DMARC passes for some other reason, either SPF, or the presence of a 
> second passing DKIM signature for the same domain.
>
> I propose the modification of this section to state that failing DKIM 
> signatures SHOULD be ignored, but BIMI processing SHOULD continue.
> The use of SHOULD in this section was intended to cover the cases 
> where MBPs did not implement this check, however I would be happy to 
> make these checks a MUST, what is the opinion of the group?
>
>> >Seems more a question about should a receiver go to default._bimi 
>> (or something else) if the selector is specified but seems unusable 
>> (either not signed or signature fails).
>> This is it exactly.  Maybe I missed something, but as written there 
>> is no suggested or required action if the receiver sees that the 
>> BIMI-selector is DKIM signed but that DKIM fails to validate.  This 
>> can probably be covered with one line in section 5.4, it's just a 
>> question of "should the receiver skip to default._bimi. or skip BIMI 
>> entirely?"
>> Thanks!
>> *Zack Aab* (He/Him)
>> On Thu, Apr 29, 2021 at 11:19 AM Brotman, Alex 
>> <Alex_Brotman=[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     I’m not entirely sure that answers the original question.  I
>>     don’t think the OP is an attempt to second guess DMARC. Seems
>>     more a question about should a receiver go to default._bimi (or
>>     something else) if the selector is specified but seems unusable
>>     (either not signed or signature fails).  If we believe the
>>     sections A.1/A.5 covers this scenario, perhaps we just need a
>>     little embellishment on this scenario below to be more explicit. 
>>     And yes, local policy can impact this.
>>
>>
>>     --
>>
>>     Alex Brotman
>>
>>     *From:* bimi <[email-masked]
>>     <mailto:[email-masked]>> *On Behalf Of * Marc Bradshaw
>>     *To:* [email-masked] <mailto:[email-masked]>
>>     Opinion: This feels like a discussion outside the scope of BIMI,
>>     SPF forgery is a known issue ref the recent Multipass attack at a
>>     well known vendor. There is a related note in the "Unsigned
>>     BIMI-Selector Header" section of the spec.
>>
>>     We do see senders with p=reject who rely entirely on SPF and do
>>     not DKIM sign at all, I would argue that the problem being
>>     described here is more about vulnerabilities in some shared
>>     infrastructure platforms and not about how BIMI should be
>>     implemented. At the very least, I would expect that discussion to
>>     take place in the DMARC group, and that BIMI should take the
>>     DMARC result as is as much as is possible, without imposing
>>     additional constraints over what constitutes a valid DMARC pass
>>     or fail.
>>
>>     MBPs are, of course, free to implement whatever additional
>>     constraints they see fit, but I don't feel that this one belongs
>>     in BIMI.
>>
>>
>>         In my opinion if DKIM fails to validate the message content
>>         the MBP should not display the BIMI at all (no matter why the
>>         DKIM failed). The reasoning for this is that SPFs validate
>>         shared infrastructures (OL365, GSuite, etc) and as such
>>         domains can be spoofed while DKIM authenticates the actual
>>         content. BIMI logos being displayed on the message list (see
>>         Yahoo mail app) they become sort of a "From" indicator from
>>         the users perspective and over time will become sort of a
>>         trust indicator. BIMI should make every effort on the
>>         standard level to discourage any use of BIMI that failed a
>>         critical validation of the message body as that alone could
>>         be an abuse vector.
>>
>>         If a phishing operation targets businesses that are using
>>         shared infrastructures and have BIMI, they could achieve
>>         quite a significant success if the messages get highlighted
>>         with a logo while failing DKIM. This would undermine BIMI in
>>         a major way and DKIM as well.
>>
>>         Jakub Olexa
>>
>>         Founder & CEO
>>
>>             I was reading section 5.4 of the document and it's pretty
>>             clear what to do if the selector header (BIMI-selector)
>>             is not included in the DMARC-aligned DKIM signature:
>>             treat it as if there is no selector header and move on to
>>             default._bimi.
>>
>>             BUT
>>
>>             What if the DKIM signature includes the BIMI-selector
>>             header but doesn't pass validation AND DMARC still passes
>>             via SPF?
>>
>>             It seems to me (given DKIM's normal use - a broken
>>             signature should be treated as not having a signature)
>>             that the receiver should treat the BIMI-selector header
>>             as unsigned and move on to default._bimi, but it's not
>>             actually stated one way or the other, so the response
>>             from the receiver could be to stop BIMI validation entirely.
>>
>>
>>
>>             *Zack Aab*(He/Him)
>>             *O* +1 (512) 717-4097 <tel:+15127174097> | *C* +1 (404)
>>             317-6729 <tel:+14043176729> | *W* trendlinei.com
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/bimi>
>>
>> -- 
>> bimi mailing list
>> <https://www.ietf.org/mailman/listinfo/bimi>
>>
>
> --
>
> 	
>   Marc Bradshaw
> marcbradshaw.net <http://marcbradshaw.net/> | @marcbradshaw 
> <https://twitter.com/marcbradshaw>
>
>
>
>