[Bimi] Thoughts about MUA/BIMI

["Brotman, Alex" <[e-mail]>]

In thinking more about the MUA proposal, we are trying to find a solution for the case where an unaffiliated[1] MUA would like to be able to either independently validate message authentication details (to support DMARC), or rely upon the validation process from the MBP.



Consider we have two primary goals (in short form):



  1.  Drive DMARC adoption
  2.  Associate an image with properly authenticated messages



Again, we also may need to define how independent an MUA can be in the situation when there is an unaffiliated MUA in use by the recipient.  We can attempt to have the MUA be completely independent as it relates to DMARC/BIMI, or we can use the hints the MBP may be able to provide.  If we don't feel that either can be done in a reasonable manner where authentication checks can be relied upon, I'm not sure it's ideal for the MUA to display these associated images.



If we look at the first, where the MUA acts independently, we have the potential for a few methods by which it may be able to validate the message authentication details.  I'm going to pretend that the current issue of DKIM Replay Attacks is not a factor here, though I realize that may impact any decisions we make.



  1.  DKIM - The MUA could attempt to validate the DKIM signature on its own.  Presuming nothing has altered the message in transit, this is plausible.  This is only half of DMARC, and I don't think it's ideal to try to allow the MUA to understand which IP/host delivered the message (via Received headers) to the provider to evaluate SPF.  This does require the MBP not mangle the message as it passes through.
  2.  ARC - This requires the participation of the receiving MBP, as well as any intermediary. This could allow the MUA to validate the chain, and use those details to determine if DMARC has passed.  This requires a much deeper adoption of ARC than currently exists.



If this were to happen, the MUA may (and probably should) choose to ignore any existing BIMI headers that are normally created by the MBP.  If the MBP is not BIMI-aware, and not removing existing BIMI-related headers, it should not be expected that the MUA could rely on them in the situations above.  Additionally, does something need to happen to "timebox" the MUA from trying to validate all messages, even those prior to the arrival of BIMI, and the publishing of the BIMI records for the associated sender?  Should a message from "example.com' from 2017 receive a logo (assuming all of other validation lines up)?



There are other options, though it will require more participation from the MBP.  It seems that we cannot expect the MBP to store information about the message in any metadata outside of the message itself.  If we consider the case of an unaffiliated MUA, it seems as though the MBP needs some way to convey information in a reasonable manner which can be reasonably trusted/verified.



  1.  Assume the MBP is DMARC-aware, but does not directly support BIMI evaluation.  Could the MBP sign (a la DKIM) the A-R header so that the MUA could utilize that header as its evaluation.  There may need to be some signal in the A-R header that demonstrates it was the final hop (or at least which hop it was?).  This could allow the MUA to utilize SPF/DKIM/(ARC)/DMARC results as provided by the MBP instead of performing its own validation. Though, the MUA will need to ensure the signed header is legitimate.
  2.  The MBP is BIMI-aware and wants to convey its results to an unaffiliated MUA.  The MBP does the required tests, and signs the BIMI-Location or BIMI-Indicator headers.  This would allow the MUA to utilize BIMI in an independent fashion.



In the cases above, the MUA is dependent on the MBP, though that is the best place to perform the message authentication.  In this case, the risk of a web bug is probably greater as the MUA will likely be directly fetching the SVG from the remote site.



Looking for thoughts from others.  Thanks for your time.





[1] Unaffiliated MUA in this case means one that is not tightly coupled to the MBP.  Examples of an "affiliated" client may be the Gmail or Yahoo web/mobile client that are used to attach to those respective mail systems.  The unaffiliated MUA would likely be the one that the user chooses on their own, and has no direct relationship with the MBP.



--

Alex Brotman

Sr. Engineer, Anti-Abuse & Messaging Policy

Comcast