Re: [Bimi] Proposal to Clarify Role of MUA in BIMI Evaluation

[John C Klensin <[e-mail]>]

(Responding to Trent's note because I've been working on this on
and off for a few days but, to give a somewhat different answer
to the closing question in Todd's message today [1] and as will
be clear below, I have been struggling with it too and I think
it matters.   And, yes, I have read the subsequent notes -- up
to the time of mailing -- and I don't think any of them change
what follows other than one bit reflected below)



Trent,

While my concern that this is really about helping a small
cluster of collaborating companies share a marketing tool -- and
hence not something the IETF should be involved in no matter who
those companies are-- continues to exist, your suggestions seem
like improvements.   A few suggestions and comments inline
below.  (Material on which I have nothing to add elided.)

I want to stress that I am not opposed to the BIMI idea in
principle.  I just see many loose ends and have concerns about
how it would work in the real world, whether it would encourage
interoperability problems and/or fragmentation of the world of
interoperable email.    IANAL but it also seems to me to risk
raising some legal or regulatory problems from which I'd like to
be sure the IETF stays far away.

More inline.

--On Friday, July 15, 2022 23:17 +0000 Trent Adams
<tadams=[e-mail]> wrote:

> 
> All -
> 
> Based on the previous feedback, here's my latest draft for
> consideration.  It addresses the discussion so far but it
> still feels inelegant.  Even if we're heading in the right
> direction, I assume we'll need to go through a few more
> iterations until we get it right.
> 
> To summarize what's been considered since the last draft:
> 
> 
>   *   "MBP" vs "MSP" - The issue was raised that the term
> Mailbox Providers (MBP) hasn't been fully established within a
> referenceable RFC and that it may be useful to reference Mail
> Service Provider (MSP) as defined in RFC5598.  By my read,
> however, the term MSP is overly broad in this specific
> context, and I propose we stick with MBP (and define it as
> necessary).  The rationale is that an MUA evaluating BIMI
> specifically focuses on the role of an MSP which acts as a
> repository of post-processed email whereas an MSP can provide
> additional services that are outside the scope of BIMI.

I think this is a good idea although mostly for an entirely
different set of reasons.

>  * "Affiliated MUA" - There's also some concern with the term
> "affiliated".  I concur that this is problematic... though I
> continue to struggle to find a reasonable alternative.  To
> address the issue, I pulled in suggestions from the thread and
> propose adding them to the terms definitions so that we at
> least capture the meaning... and we can always swap out the
> terms later if a better term emerges.

FWIW, I think the problem lies somewhere else.  As I understand
the direction of the BIMI work (I have not read every message or
studied every update), you are rapidly sliding down the slippery
slope toward a scenario in which some hypothetical BigCo, which
runs (or contracts out) a mail service (MSP and MBP) tries to
convince its customers of the advantages of running BigCoMail,
using a BigCo-supplied mail client (aka MUA).  

I suggest we have been there and seen what results and should
not be taking actions that encourage it.   As the most obvious
example, until BigCo can convince its customers to deal with it
exclusively, that customer might be required to run multiple
MUAs, each for a different mailbox, to take full advantage of
these features.  FWIW, there is already a widely deployed
mechanism for doing just about the same thing with fewer bad
effects on mail interoperability.  That involves companies
sending out messages that, instead of containing important and
substantive content, say approximately "there is an important
message waiting for you at
https://messages.example.com/?YourUserID=...  Please go read
it.".  That can allow forcing user authentication if desired
and, assuming precautions are taken against spoofing or other
fakes of the URL, as much authentication and integrity-checking
of the message content as desired.   It is, of course, bad news
for people with intermittent or other problematic connections
but so are lots of other things.

>   *   MAY - SHOULD -
> MUST - SHOULD NOT - While I believe that this version gets us
> closer to a workable draft in the real world (given that there
> are currently unaffiliated MUAs evaluating BIMI... and more
> are coming), I'm not sure that we've settled on the final
> leaning on normative guidance.  The draft below reflects what
> I believe to be a reasonable balance between utility,
> implementability, and the reality we see coming down the road.
> 
> With that, here are the definitions I would suggest we add to
> "Section 3. Terminology and Definitions":
> 
> -----
> 
>   *   Mailbox Provider (MBP) - A subclass of Mail Service
> Provider (MSP) [RFC5598] that provides email storage and
> retrieval services to MUAs.  MBPs may operate their own
> MUA(s), be affiliated with MUAs developed and operated by
> other entities, or enable unaffiliated MUAs to access and
> retrieve email on behalf of their users.

First, if we still believe there is such a thing as an MUA that
sits on user machines as a standalone application (rather than
being, e.g., a web service), you should say "operate or supply
their own MUAs".  Your terminology should be very careful here
for another reason, which is that there is a long tradition of
thinking about a setup using IMAP or POP to allow a user to
retrieve messages as a "split MUA" arrangement in which the IMAP
or POP server is, conceptually, part of the MUA even though
operationally its code is part of what you are calling an MBP.  

Second (Dave, please check me on this) it sounds to me as if you
are talking about, not a Mail Service Provider (a very general
function if I understand the definition in RFC 5598), but a MDA
and rMDA functions.  Otherwise, I'm not quite sure where MUAs
fit in the picture.

In any event, such an MUA (the traditional kind) should, at
least in principle, be able to access substantially any mailbox
from any general-purpose mailbox provider using POP or IMAP.


>   *   Affiliated MUA
> - An MUA that has an operational relationship with an MBP.
> The MUA may be directly developed and operated by the MBP such
> that it may be considered an extension of the MBP itself, or
> the MUA may be operated by another entity that has can
> definitively rely on the validity of the BIMI valuation
> provided by the MBP from which the MUA retrieves email on
> behalf of the user.

That explanation reinforces my comments above.  But I think
there are actually three types of [recipient] MUAs for BIMI
purposes: (i) An Affiliated MUA, more or less as defined above,
(ii) An Unaffiliated MUA that still knows enough about BIMI to
recognize the header fields and do something with the
information in them (whether verified (and how) or unverified is
another question), (iii) An MUA that has no idea what any of the
BIMI header fields are about and consequently, given other specs
and very broad practice, will ignore them.  That third type of
MUA is, by definition, Unaffiliated, but there are huge
differences between it and the second type.

>   *   Unaffiliated MUA - An MUA that is
> not directly controlled, operated, or otherwise has a
> relationship with the MBP from which the MUA retrieves email
> on behalf of the user.  Some Affiliated MUAs may also retrieve
> email from MBPs with which they have no relationship, and in
> such instances may operate as Unaffiliated MUAs to those MBPs.

And that is, at least approximately, what has been considered
the normal case since the email-over-FTP period of the 1970s
except for one thing.  Given the split-UA model, a MUA that uses
an IMAP client on the user's machine, has, almost by definition,
a "relationship with the MBP" because the IMAP server will be
part of that MBP (or MDA).   So, AFAICT, by the definition in
the first sentence above, there is probably no such thing as an
Unaffiliated MUA.  And that is certainly not what you intend.
Hence, see below about "two classes".

> -----
> 
> And here's the latest suggested update to "Section 4.1 MUA
> Obligations" (renaming it "Role of the MUA in BIMI
> Evaluation"):
> 
> -----
> Section 4.1. Role of the MUA in BIMI Evaluation
> 
> There are two classes of MUAs: those operated directly or in
> close collaboration with an MBP, and those that are not
> directly controlled, operated, or otherwise affiliated with
> the MBP from which the MUA retrieves email on behalf of the
> user.   For the purpose of this specification, the first class
> may be considered "Affiliated", while the second may be
> considered "Unaffiliated."  For example, an MUA affiliated
> with an MBP may employ mechanisms (standardized and/or
> proprietary) that ensure the MUA can rely upon the validity of
> the BIMI evaluation provided by the MBP.  These mechanisms
> employed by MUAs affiliated with MBPs may be unique to the
> relationship, relying upon information beyond BIMI, and are
> thus outside the scope of this specification.
> 
> An MUA displaying BIMI indicators SHOULD rely on the
> authentication and BIMI evaluation performed by an Affiliated
> MBP, or the MUA MAY perform the required verification using
> the information contained within the email.  MUAs Affiliated
> with an MBP SHOULD rely upon the evaluation performed by the
> email evaluated by MBP by using the inserted BIMI-Location or
> BIMI-Indicator headers inserted by the MTA.  MUAs not
> affiliated with the MBP from which they retrieve the email
> MUST perform their own evaluation.  For example, the
> Unaffiliated MUA MAY verify an intact DKIM signature and use
> the result to validate DMARC alignment prior to evaluating
> BIMI.  An Unaffiliated MUA SHOULD NOT rely on the
> Authentication-Results, BIMI-Location, or BIMI-Indicator
> headers inserted into the email by MTAs that the MUA cannot
> verify to be authentic.

I think the above is a significant improvement over the earlier
text, but my concerns above, primarily with the whole idea of
where "Affiliated" takes us, still stand as does the issue or
what "Unaffiliated" really means.
 
> When evaluating BIMI, the MUA SHOULD make a best-effort
> attempt to adhere to the Domain Owner's published BIMI policy.
> It is understood, however, that MUAs have final control over
> the user interface published to their end users, and MAY use
> alternate Indicators than those specified in the BIMI
> Assertion Record or display no Indicator at all.

But, for a non-Affiliated MUA, this is handwaving.  And, for one
that falls into my third category, it is completely meaningless.
You hope such MUAs will decide to support this in some way but,
unless the relevant companies are, e.g., going to offer cash (or
similar) incentives to any Unaffiliated MUA who signs up and
supports the concept (with or without the DNS records), I don't
see the incentives for the MUA provider.  If they do accept such
incentives, they are not really "unaffiliated" any more even if
they still don't meet your definition of "Unaffiliated".  And,
AFAICT, the relevant company would, in most cases, have stronger
incentives to promote use of their own ("Affiliated") MUA rather
than underwriting other ones.  The obvious exception is when
Company1 has a captive (aka "Affiliated") MUA1 and Company2 has
a captive MUA2.  Company1 might then have an incentive to go to
Company2 and say "if you support our BIMI rituals, we will
support yours".   Of course, and Company1 and Company2 are
competitors, assorted competitiveness regulators and antitrust
authorities may take a dim view of that sort of collaboration,
even if the offer were extended to everyone in the relevant
industry that supported a Affiliated MUA.

Even for an Affiliated one but especially for the Unaffiliated,
messages may be retrieved from a mail store, as Todd pointed
out, months or even years after they are deposited there.
Unless the BIMI header fields/images/data come with timeouts,
there will be a reasonable expectation that users will see the
same thing, with equivalent assertions authenticity, any time
(and each time) the message is retrieved.  For data kept as part
of an MDA (MBP, I think) controlled by the organization
supporting the BIMI and their Affiliated MUA, perhaps that is
plausible, but the concern gives way to questions about
long-term stability of data stored in the DNS, whether those
records need time stamps different from, e.g., that associated
with the zone or DNS TTLs, and so on -- other complexities that
should be addressed if this mechanism is going to be, even in a
small measure, robust.

> ----
> 
> While I believe we're getting closer to fleshing out what
> needs to be said about how MUAs evaluating BIMI... I've become
> keenly aware that the specification is much more useful to
> MUAs affiliated with MBPs and quickly becomes problematic when
> considering how unaffiliated MUAs can participate in the model.

Exactly.   But, if it is really only for Affiliated MUAs that
the spec is clear and useful, my comments above apply and I
wonder about whether the IETF should have a role (any role at
all) in fostering non-interoperability (or interoperability only
with captive clients).

>...

best,
   john

p.s.  Stylistic comment: As some of you may know, my very
high/abstract model of how email works and the associated
terminology differs somewhat from that described in RFC 5598
and, for that reason and a few others, I'm not the world's
biggest fan of that specification.   However, if you are going
to cite it normatively and say "Readers are encouraged to be
familiar with the contents of [RFC5598]" [1], then I think the
principle sometimes described as "in for an inch, in for a mile"
applies.   In particular, first, your terminology should be
absolutely consistent with the terminology of 5598.  If you need
to differ from it, you should explain why.   Second, you should
use that terminology whenever possible (and use it correctly)
rather than inventing new terms of your own.  As part of that,
tell your readers that understanding 5598 is actually a
prerequisite, not just "encouraged".  And, third, go ahead and
use the more precise terminology of 5598 where it is applicable.
For example, at least AFAICT, every time you use "MUA" you are
talking about an "rMUA" and not a "aMUA" or a combination of the
two.



[1] draft-brand-indicators-for-message-identification-01 Section
3.