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

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

Dave,

Thanks for an excellent explanation.  I was working on a
somewhat similar note, but your explanation is better.

Ken, Trent, and Alex,

This set of proposals are all feeling, to me, very complex, with
a large (and maybe growing) collection of characteristics that
are either not being explained clearly enough, that make
assumptions or requirements that could lead to the creation of
mail islands, or that violate rather basic principles of how
Internet mail works in the general case.   I hope I -- and Dave
and others-- just don't understand how all of this fits
together.  If we do understand, then taking a few steps back and
rethinking the objectives and mechanisms (rather than trying to
fine-tune) may be in order.  If not, there may be some basic
issues with how the documents are constructed editorially:
historically, at least Dave and I, whether we agree or not, are
rarely obtuse about such things.

As a further observation, it is usually very easy to get a
protocol working among parties who are actively collaborating
(or between a client and server designed or configured and
operated by the same party).  The devil is in the details of
interoperability among completely independent (more than just
"Unaffiliated" if I understand the terminology of the draft)
implementations and that is where I think this design may be
problematic.

best,
   john


It seems to that this is getting very complex 

--On Tuesday, July 19, 2022 06:20 -0700 Dave Crocker
<[e-mail]> wrote:

> On 7/18/2022 9:23 AM, Ken O'Driscoll wrote:
>> Non-affiliated MUAs already trust the MTA to deliver
>> messages. Many  also trust the MTA to filter spam, virus,
>> phishing etc. The MTA  authenticates the MUA. Why does BIMI
>> require an additional MUA-level  check at all? What specific
>> risk is it supposed to mitigate?
> 
> 
> The concept of end-to-end distinguishes end points from
> transport infrastructure.  There should always be careful
> consideration of where to provide functionality -- endpoint
> vs. infrastructure. (*)
> 
> "Trust" of the infrastructure is not monolithic.  The fact
> that an MTA is trusted to move a message correctly does not
> mean that it is trusted to evaluate and vet the contents of
> the message. The fact that it is assigned some trust for
> assessing spaminess does not mean it is assigned complete
> trust for all aspects of the content or even all aspects of
> spaminess.
> 
> If a design essentially requires an MUA to impart complete
> trust for mail content validity to the platform provider,
> that's quite a substantial departure from historical
> distributed system design choices, even though it is a common
> implementation choice for some popular services.
> 
> At the very least, a specification should explicate its trust
> choices carefully and thoroughly.
> 
> d/
> 
> 
> 
> (*) The seminal paper on this architectural design issue is:
> 
> End-to-end Arguments in System Design
> http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.
> pdf
> 
> This topic is often referred to as the End-to-End Principle
> and taken as a mandate, but the wording of the title is more
> nuanced, choosing 'arguments' rather than 'principle'. What it
> really requires is considering tradeoffs in the choices for
> placement.