Subject: [Extra] Is this a plausible IMAP extension ?

From: "John R. Levine" <[email-masked]>
Date: 26 Feb 2019 22:06:36 -0500

There is this thing called BIMI that is being debated elsewhere in the 
IETF.  Leaving aside for the moment the issue of whether it's a good idea 
in the first place, it invents an IMAP feature that seems dodgy to me.

When an MTA that supports BIMI delivers a message into the mailstore, it 
adds a header that tells MUAs where to find a logo to show next to the 
message.  (Think of it as x-face for corporations.)  Since bad people 
could phish victims with their own header with a misleading image, BIMI 
invents a new IMAP flag that only the delivery MTA can set on messages 
where it has added a virtuous header.  An MUA can test it to decide 
whether to show the logo.  Other IMAP or POP clients can't set the flag, 
but it presumably stays with the message if it's moved from one folder to 
another.

Does existing IMAP software have this kind of privileged flag?  Is it 
something that would be reasonable to implement, e.g., is there already a 
concept of users at different privilege levels manipulating the same mail 
store beyond just R/W and R/O?  The IMAP software I use is Dovecot, where 
in the vast amount of badly organized documentation I don't see anything 
like this, but maybe it's hiding and I don't know where to look.

Advice from actual IMAP experts welcome.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

PS: If as I suspect this is unlikely to be implementable, I have an 
alternate approach that involves misusing DKIM.

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 26 Feb 2019 23:17:09 -0500

This isn't a standard feature on any IMAP server I'm aware of.

I can see how to implement it in Cyrus IMAPd. Add a custom numbered ACL to control a set of listed flags, and allow the delivery agent to have that ACL.

On the other hand...

We do something like this already at FastMail, and here's the thing.... the user should be allowed to add or clear this header to change the interpretation of the email in their mailbox. Once they have the message - they should be able to update the BIMI status.

This is particularly important when you're talking about importing and exporting email between systems. Having the flag to avoid phishing, sure. But restricting MUAs from setting that flag - that's bogus.

I guess I'm going to the BIMI session.

Bron.

On Wed, Feb 27, 2019, at 14:06, John R. Levine wrote:
> _______________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra
> 

--
 Bron Gondwana, CEO, FastMail Pty Ltd
 [email-masked]

---

From: "Bron Gondwana" <[email-masked]>
Date: Tue, 26 Feb 2019 23:17:34 -0500

Sorry, not add or clear header - add or clear keyword.

Bron.

---

From: Michael Peddemors <[email-masked]>
Date: Tue, 26 Feb 2019 20:45:52 -0800

Hmmmmm... idle thoughts..

Conceptually, I can see the problem it is trying to solve, but I don't 
think it is realistic.. And possibly even dangerous... The real problem 
still rests in letting the phishing email get into the mailbox in the 
first place, and/or identifying to the client that this is a phishing 
email, and not related to the purported sender..

Sounds like a better plan would be to have 'certified' logo available by 
some other mechanism if you are trying to tackle the problem of a visual 
cue to a reader ... hehe an MTA could attach a multi-part that would 
cause the rendering of a watermark.. 'This is NOT from PayPal'.

But if it could figure that out, why would it allow it to be delivered 
in the first place?

I can think of a raft of problems that would have to be overcome..
And still doesn't stop the 'phish', when it is sent with a non 'BIMI' 
(ex) format..

I see how it can be used to render an 'official' logo, (another 'tagged' 
element.. *sigh*) but don't see how it can stop forgeries.. And any form 
of remote image in emails can have it's own issues.  I think the idea is 
going too far afield.. at least from an IMAP perspective.

If I wanted to do that, it would be better if the SMTP server handled 
it, something like .. the message came from a source listed in the SPF 
record, so I will add a 'X-MTA-Source-Trusted' header.

(of course, you have to first convince every MTA in the world to strip 
that header first during receipt, before it too could be trusted)

That might be something for an SMTP group to look at.. as a capability?
Maybe then it applies to IMAP, eg a capability saying it trusts the 
header the local MTA placed there..

The clients then could be responsible for showing 'source not trusted' 
unless the header was there..

But again, all very complex..

Encourage the ideal, but don't see it as the right approach, without 
more information.

Anyways.. too late at night to give any real meaningful input, sorry 
John, but for us the focus is making sure that email accounts are not 
compromised in the first place, because that's how the most of the 
phishing reaches inboxes.. (oh, yeah and bad hosters, and detecting bad 
guys)

Botnet phishing is easier to catch.. which is why we see all the botnets 
turning into brute force attacks against legitimate accounts instead..

I sure would like if more of this working group rallied around CLIENTID 
for IMAP as proposed, I sure enjoy the proven benefits here ..

It would give every user of email that ability to 'lock' their Inbox.

On 2019-02-26 7:06 p.m., John R. Levine wrote:
> IETF.  Leaving aside for the moment the issue of whether it's a good 
> idea in the first place, it invents an IMAP feature that seems dodgy to me.
> 
> but it presumably stays with the message if it's moved from one folder 
> to another.
> 
> something that would be reasonable to implement, e.g., is there already 
> a concept of users at different privilege levels manipulating the same 
> mail store beyond just R/W and R/O?  The IMAP software I use is Dovecot, 
> where in the vast amount of badly organized documentation I don't see 
> anything like this, but maybe it's hiding and I don't know where to look.
> 

-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 27 Feb 2019 07:32:24 +0100

On Wednesday 27 February 2019 04:06:36 CET, John R. Levine wrote:
> There is this thing called BIMI that is being debated elsewhere 
> in the IETF.  Leaving aside for the moment the issue of whether 
> it's a good idea in the first place, it invents an IMAP feature 
> that seems dodgy to me.
>
> When an MTA that supports BIMI delivers a message into the 
> mailstore, it adds a header that tells MUAs where to find a logo 
> to show next to the message.  (Think of it as x-face for 
> corporations.)  Since bad people could phish victims with their 
> own header with a misleading image, BIMI invents a new IMAP flag 
> that only the delivery MTA can set on messages where it has 
> added a virtuous header.  An MUA can test it to decide whether 
> to show the logo.  Other IMAP or POP clients can't set the flag, 
> but it presumably stays with the message if it's moved from one 
> folder to another.

There is a sort of expectation with IMAP that you can copy messages. That 
you can copy your entire mail archive from fastmail to gmail and the result 
will work as before. There are programs to do this, imapsync for example, 
and doesn't one of the big MUAs have this builtin, too?

BIMI wouldn't. With BIMI, the copy would be degraded, not complete.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 27 Feb 2019 14:07:44 +0000

On 27/02/2019 06:32, Arnt Gulbrandsen wrote:

>> There is this thing called BIMI that is being debated elsewhere in 
>> the IETF.  Leaving aside for the moment the issue of whether it's a 
>> good idea in the first place, it invents an IMAP feature that seems 
>> dodgy to me.
>>
>> When an MTA that supports BIMI delivers a message into the mailstore, 
>> it adds a header that tells MUAs where to find a logo to show next to 
>> the message.  (Think of it as x-face for corporations.)  Since bad 
>> people could phish victims with their own header with a misleading 
>> image, BIMI invents a new IMAP flag that only the delivery MTA can 
>> set on messages where it has added a virtuous header.  An MUA can 
>> test it to decide whether to show the logo.  Other IMAP or POP 
>> clients can't set the flag, but it presumably stays with the message 
>> if it's moved from one folder to another.
>
> There is a sort of expectation with IMAP that you can copy messages. 
> That you can copy your entire mail archive from fastmail to gmail and 
> the result will work as before. There are programs to do this, 
> imapsync for example, and doesn't one of the big MUAs have this 
> builtin, too?
>

To expand on this: the answer would depend on whether a particular IMAP 
server supports a particular IMAP keyword or storage of arbitrary IMAP 
keywords. Support for arboitrary IMAP keywords is relatively widely 
implemented feature in IMAP servers, but unfortunately it is an optional 
feature.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 27 Feb 2019 15:35:40 +0100

Maybe I misunderstood.

I thought that BIMI said: If a message is delivered by the system and meets 
some other conditions, then it gets a reserved flag, which the user is 
unable to set (or clear). And my response to that is that people expect to 
be able to copy their mail from one server to another. When messages are 
migrated then they lose the magic BIMI flag, because the new server sees 
them being inserted by the user using IMAP APPEND.

This sounds to me as if it rather diminishes the point of BIMI...

That some servers don't support flags is okay. The servers that can't be 
extended don't get a lot of new extensions anyway.

(BTW, John, you reject my mail as spam. Even though I've been practically a 
hermit for a year now. I made this list-only on a whim.)

Arnt

---

From: Ned Freed <[email-masked]>
Date: Wed, 27 Feb 2019 06:45:44 -0800 (PST)

> We do something like this already at FastMail, and here's the thing.... the
> user should be allowed to add or clear this header to change the interpretation
> of the email in their mailbox. Once they have the message - they should be able
> to update the BIMI status.

This seems entirely reasonable to me, but now we're talking about updating the
message content. This pretty much pushes it out of the header space as 
far as I'm concerned.

> This is particularly important when you're talking about importing and
> exporting email between systems. Having the flag to avoid phishing, sure. But
> restricting MUAs from setting that flag - that's bogus.

Exactly.

> I guess I'm going to the BIMI session.

Sounds like a good idea.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Wed, 27 Feb 2019 06:32:27 -0800 (PST)

> in the first place, it invents an IMAP feature that seems dodgy to me.

That's not all that's dodgy here.

> but it presumably stays with the message if it's moved from one folder to

First, this sounds to me like a layering violation (addition of message content
after delivery) trying to sneak it's way in by pretending to be some sort of
trace information. And since we have the ability to annotate messages, the
first question that needs to be asked is why this isn't being done in the
obvious way by simply annotating the message?

My guess is the answer to that is something along the lines of, "Mumble mumble
not all servers/clients support mumble mumble headers are cheap to fetch
mumble", but really, we're in the process of launching a major new protocol in
the client access space, and surely if there ever was a time to get the
facilities people need in place, it's now.

Second, the issue of who gets to set this information exists independent
of how the information is stored or how access control to that information
is implemented - although I do note that annotations have a rich set of
access control features ready to hand that could be brought to bear here.

And that model seems a bit bizarre to me. Why is the MTA necessarily the agent
with the definitive take on the right logo to attach? Does the MTA never ever
ever make mistakes in selecting a logo? Is the MTA invulnerable to attack? Does
the logo never change after the fact? 

These questions, and many others, need to be answered before we even start
to talk about how to implement this.

				Ned

---

From: "John R. Levine" <[email-masked]>
Date: 27 Feb 2019 12:49:15 -0500

> And that model seems a bit bizarre to me. Why is the MTA necessarily the 
> agent with the definitive take on the right logo to attach? Does the MTA 
> never ever ever make mistakes in selecting a logo? Is the MTA 
> invulnerable to attack? Does the logo never change after the fact? These 
> questions, and many others, need to be answered before we even start to 
> talk about how to implement this.

I'm working on another draft that attempts to explain (not justify) it.

A lot of it boils down to the big gorillas are displaying logos now, so 
is there a way they can do so without inventing yet another club to which 
the rest of us are not invited.

Regards,

---

From: "Bron Gondwana" <[email-masked]>
Date: Wed, 27 Feb 2019 16:01:07 -0500

> message content. This pretty much pushes it out of the header space as 

I corrected that almost immediately - but, yay immutable emails. I meant a keyword that they could update, not a header. Sorry.

So the header gets added at delivery time, the same way an Authentication-Results header gets added, saying that DKIM / SPF passed or didn't pass. Fine.

A keyword gets added to the message on delivery if that header is present. Fine.

The keyword has a restricted ACL such that the user can't modify it afterwards. Not OK. Dislike. Unnecessary and likely to cause many issues. The "users could be phished to change the keyword" is an implausible argument in any mass market client that I've seen, and the side effects of trying to make read-only keywords are significant.

> > I guess I'm going to the BIMI session.

Fun times :)

I've been tracking BIMI for a couple of years anyway, so it's not like I was ever NOT going to go.

Bron.

---

From: "John Levine" <[email-masked]>
Date: 27 Feb 2019 20:57:01 -0500

In article <[email-masked]> you write:
>The keyword has a restricted ACL such that the user can't modify it afterwards. Not OK. Dislike. Unnecessary and likely
>to cause many issues.

I had a chat with some of the BIMI people and pointed out that
privileged IMAP flags are unlikely to work well, and in any event, if
you have IMAP clients that can put malicious stuff into your
mailstore, you've got worse problems than what logo appears next to
the phish.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 28 Feb 2019 10:33:55 +0100

> mailstore, you've got worse problems than what logo appears next to

You're proposing something more like... x-face meets dkim? Good.

If you do it by adding a field to either content-type or 
content-disposition, a bit like 3676, then it's easy for imap clients to do 
what gmail does, oops, I meant behave in a user-friendly manner. No new 
protocol is needed in that case.

Arnt

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2019 11:12:13 -0500

>You're proposing something more like... x-face meets dkim? Good.

More or less. 

>content-disposition, a bit like 3676, then it's easy ...

Urrgh.  Most of the mail that's likely to have a logo is multipart/alternative
and I'm not interested in wrapping contents in yet more MIME layers, which would
among other things break any existing DKIM signatures.

It's more like you add the x-face header, then add a new DKIM signature that includes
the x-face along with the usual stuff, and the MUA decides to believe it because the
signature is from its imap provider.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 28 Feb 2019 19:08:04 +0100

> among other things break any existing DKIM signatures.

You don't need that. Look at 3676. It doesn't wrap, it marks. In this case, 
either mark the top-level multipart with the content-id of the logo

  content-type: multipart/mixed; boundary=foo; logo=bar

(the logo will mostly have a content-id because the html refers to it) or 
mark the bodypart with the logo

  content-type: image/jpeg; content-id=bar; logo

or mark the logo's disposition

  content-disposition: attachment; logo

It's not obvious to me which way is the best. Is being a logo part of the 
type or rather part of the disposition? I don't even want o discuss that.

All are immutable though, since they're part of the message, and the info 
is returned as part of the FETCH BODYSTRUCTURE command most/all clients 
use. Very easy to implement in typical clients, and zero work for the 
server.

Arnt

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2019 16:11:22 -0500

>  content-type: multipart/mixed; boundary=foo; logo=bar

Breaks DKIM signatures.

>  content-type: image/jpeg; content-id=bar; logo

Breaks DKIM signatures.

>  content-disposition: attachment; logo

Breaks DKIM signatures.

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 28 Feb 2019 23:14:59 +0100

I suppose I misunderstood. You are saying that the sender cannot supply 
the logo, right? The recipient decided whether to display AND procures 
a logo?

Arnt

---

From: "John Levine" <[email-masked]>
Date: 28 Feb 2019 19:15:48 -0500

>the logo, right? The recipient decided whether to display AND procures 

The sender supplies the logo (through a process that's currently
baroquely indirect, but the recipient MTA decides whether to display
it and puts something in a header to indicate that.

Without some sort of validation, this screams PHISH ME NOW!

R's,
John

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 1 Mar 2019 08:30:34 +0100

So why not let the sender supply the logo by marking a body part, and 
then specifying when and whether to use it? Why must the logo be 
marked/inserted/supplied after the DKIM signature?

Arnt