Re: [Bimi] Alternate proposal

[Ken O'Driscoll <[e-mail]>]

+1

I would also like an open discussion on this list about why BIMI requires DMARC with an enforcing policy at all. What is the user benefit or what risk does it mitigates etc. Because, to me personally, it just seems like a mechanism for transferring the cost of implementing/maintaining DMARC for large organisations. And VMCs seem conceptually similar to the ill-fated EV certificates.

I have project managed DMARC deployments in the financial services sector. I appreciate what it does and why it's desirable for organisations with similar compliance needs and risk profiles.

However, I actively advise regular clients not to enforce a restrictive DMARC policy on their marketing message streams because of the risk that legitimate messages will not reach the inbox. A forward between MTAs and a subject rewrite (eg., "External" tag) can cause a legitimate message to fail a DMARC test by design. If there's a revenue generating CTA in that message, then DMARC on that stream becomes problematic. ARC does not (yet) solve the forwarding problem because of the trust communication issue and lack of widespread deployment.

So, integrating BIMI with a PKI or web-of-trust seems like an idea at least worth discussing.

Ken.
________________________________
From: bimi <[e-mail]> on behalf of Trent Adams <tadams=[e-mail]>
Sent: Thursday, July 21, 2022 7:43:36 PM
To: John C Klensin <[e-mail]>; Todd Herr <todd.herr=[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [Bimi] Alternate proposal




For what it's worth - I agree with John's assessment.  And that's precisely why I think we need to have all conversations about BIMI on this open discussion list.  We need the visibility and input from all stakeholders in order to have a truly effective discussion.



So... that being said... I'd suggest that we redouble our efforts to review the feedback so far and discuss what's next.  I know that I sparked the most recent conversational thread with questions about the MUA role in BIMI evaluation (a known trouble point)... and I honestly think that the conversation has been a productive one.  It's not always smooth sailing, but that's to be expected.



In short... I'd like to avoid unnecessary balkanization of the effort.  For my part, I'd like to see if we can address the suggestions of John and others so far and see where it can lead the work.



My $0.02,

Trent





From: bimi <[e-mail]> on behalf of John C Klensin <[e-mail]>
Date: Thursday, July 21, 2022 at 12:10 PM
To: Todd Herr <todd.herr=[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [Bimi] Alternate proposal



--On Thursday, July 21, 2022 11:39 -0400 Todd Herr <todd.herr=[e-mail]> wrote: > On Wed, Jul 20, 2022 at 10:16 PM John C Klensin > <[e-mail]> wrote: > >> As promised in my recent "Radical





--On Thursday, July 21, 2022 11:39 -0400 Todd Herr

<todd.herr=[e-mail]> wrote:



> On Wed, Jul 20, 2022 at 10:16 PM John C Klensin

> <[e-mail]> wrote:

>

>> As promised in my recent "Radical critique" note, a suggestion

>> about a completely different way to approach the BIMI problem,

>> one that would be far less complex and problematic.  This is

>> just an outline with many details left to be filled in -- my

>> purpose in sending the note is to encourage people to think

>> differently about the issues and see if there is interest in

>> further discussion.

>>

>> [snip]

>>

>> Would something along those lines make any sense at all?

>>

>

> I can't answer your question, but I do know that there is

> already running code for BIMI, written against the draft spec

> as it currently exists.

>

> It would be up to the implementers to decide if they're

> willing to scrap their currently running code and start over

> with something new.



Todd,



<rant>

My very first task when I became Apps AD a very long time ago

was to explain to what were, then, some very significant

implementers that, while the IETF could not prevent them from

implementing on the basis of an I-D, they had no right to

complain if the IETF's work evolved in a different direction.

Many things have changed in the last (nearly) 30 years, but I

think that, if the IETF is going to remain meaningful as a

standards body, the underlying theme has to be preserved.

Nothing prevents a group of implementers from getting together,

doing whatever they want to do, writing a description of it up,

and posting that as an I-D.  However, if they want IETF

endorsement for what they are doing (or have done), that implies

seeking community consensus that what they are doing is worth

doing, that it is the right way to do it and, presumably, a good

faith intent to accept that consensus, whatever it might turn

out to be.



The oft-cited "running code" principle was never intended to

imply "we did this together, we implemented it, it works in our

controlled and cooperating environments, so the IETF has to

accept and standardize it".  If things ever reach that point,

one has to wonder what the point of the IETF would be: the ISE

is perfectly capable of publishing documents of the flavor of

"ABC Company's Way To Do X" and "XYZ Consortium's Way to Do Y"

documents and has a long history of doing so.  Because those

documents are explanatory and descriptive, not normative and

with claims of community consensus, getting them published is

normally much quicker and far less painful than getting the IETF

to agree.

</rant>



So, what I have seen here, in addition to many suggestions about

improving editorial and terminology quality, are multiple

concerns about functionality and interoperability.  Many of them

have been raised by people with several decades of experience

trying to make email work in an interoperable way, a few of whom

even having had reputations of having almost never agreed about

anything over that period.  Nothing makes them (us)

authoritative but the concerns, especially those based on prior

bad experiences, should probably be taken seriously.



And not only have those concerns been raised, but I believe I

have seen several exchanges in which someone (other than me) has

made a point, gotten a message in response, and pointed out that

the message did not respond to the original point  (sometimes

with more than one iteration on the same point/issue).



With the understanding that I believe the authors and

implementers are sincerely interested in moving this work

through the IETF and getting IETF input and consensus and have

seen no evidence to the contrary so far (even though I think

there have been some communications difficulties), my two notes

were prompted by a pair of questions: (1) whether there is

actually growing agreement that hard questions (not just

questions about fine-tuning) are being asked, and should be

asked, about the proposals and their operation and

applicability, and (2) whether, if and when we reach the point

that a radically different approach == perhaps one based on MIME

facilities rather than mail header fields-- seems to be in

order, that is possible to consider going in that direction?  If

the answer to the first question is "no", then I hope someone

will help persuade me, possibly offline so as to not waste time

on the list.   If the answer to the second is "no", then I

suggest starting to recast the documents as "this is what it is

and how we do it" descriptions rather than specifications to be

processed in the IETF.



Those, of course, are just personal suggestions: I claim no

authority here, just that I think it has gotten to be time to

ask the questions.



   best,

     john





--

bimi mailing list

[e-mail]

https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bimi__;!!ORgEfCBsr282Fw!uuANg5bLiKQquUjZ55P1eDJEyycLqGfcKNV9peswRJBw9pfpstRCSPQoF08oGvTR-4hdCeG3K6i64zmKyA$