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

Michael Peddemors <michael@linuxmagic.com> Wed, 27 February 2019 04:45 UTC

Return-Path: <michael@linuxmagic.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0AD130E11 for <extra@ietfa.amsl.com>; Tue, 26 Feb 2019 20:45:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWeQ0FiFuner for <extra@ietfa.amsl.com>; Tue, 26 Feb 2019 20:45:53 -0800 (PST)
Received: from fe1.cityemail.com (mail-ob1.cityemail.com [104.128.152.18]) by ietfa.amsl.com (Postfix) with ESMTP id 61390130E16 for <extra@ietf.org>; Tue, 26 Feb 2019 20:45:53 -0800 (PST)
Received: (qmail 14355 invoked from network); 27 Feb 2019 04:45:52 -0000
Received: from riddle.wizard.ca (HELO [192.168.1.55]) (michael@wizard.ca@104.128.144.8) by fe1.cityemail.com with (AES128-SHA encrypted) SMTP (8f908fea-3a4a-11e9-b703-972fa33d793c); Tue, 26 Feb 2019 20:45:52 -0800
To: extra@ietf.org
References: <alpine.OSX.2.21.1902262150050.14048@ary.local>
From: Michael Peddemors <michael@linuxmagic.com>
Organization: LinuxMagic Inc.
Message-ID: <1fefbedf-944b-2226-373b-118a15a4b2f6@linuxmagic.com>
Date: Tue, 26 Feb 2019 20:45:52 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <alpine.OSX.2.21.1902262150050.14048@ary.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 8bit
X-MagicMail-OS: Linux 3.11 and newer
X-MagicMail-UUID: 8f908fea-3a4a-11e9-b703-972fa33d793c
X-MagicMail-Authenticated: michael@wizard.ca
X-MagicMail-SourceIP: 104.128.144.8
X-MagicMail-RegexMatch: 0
X-MagicMail-EnvelopeFrom: <michael@linuxmagic.com>
X-Archive: Yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/yPm5IUoL4l23Tvh8rjeRc1l2pNQ>
Subject: Re: [Extra] Is this a plausible IMAP extension ?
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Feb 2019 04:45:56 -0000

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:
> 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, johnl@iecc.com, 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.
> 
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra



-- 
"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.