MBOX-Line: From dave at cridland.net  Tue Apr  2 08:35:00 2019
To: imap-protocol@u.washington.edu
From: Dave Cridland <dave@cridland.net>
Date: Tue Apr  2 08:35:44 2019
Subject: [Imap-protocol] CLIENTID capability for IMAP (and SMTP)
In-Reply-To: <fd8e452a-a4e9-4123-aa54-e026735269d6@www.fastmail.com>
References: <8cade395-864a-9039-6bfa-874c26e5967e@chartertn.net>
	<CABa8R6ufcJ9GimEoLrFkKnMCh14n5+VK3uN-++f4tE-qfPW-7g@mail.gmail.com>
	<fd8e452a-a4e9-4123-aa54-e026735269d6@www.fastmail.com>
Message-ID: <CAKHUCzyjLH2NmaLY=XyRAiuVTce7+D8Rfmh3pqN4O-UQmBrO6w@mail.gmail.com>

See also: https://tools.ietf.org/html/draft-cridland-kitten-clientkey-00

I implemented this in XMPP for various reasons, but there's no particular
reason it couldn't be used for IMAP et al.

On Tue, 2 Apr 2019 at 02:08, Bron Gondwana <brong@fastmail.fm> wrote:

> For what it's worth, this work was brought to the EXTRA working group at
> IETF at Montreal last year, and the group decided that it wasn't the right
> level in the stack for this kind of ID - that it would be better placed in
> the SASL layer.
>
> The OAUTH technique also strikes me as a better long-term solution,
> because it means that users aren't entering their own selected password to
> be stored on disk by clients.
>
> On the flip side, I'm sensitive to the argument from Linux Magic that this
> solves a problem RIGHT NOW which a perfect future solution might solve
> better, but a future solution doesn't fix anything for the current
> environment.
>
> Regarding the discussion on bugzilla - I would agree that it's quite
> important that the same ID MUST NOT be sent to different servers - the
> CLIENTID should be generated as a unique hash over ('deviceid', 'username',
> 'domain').
>
> Bron.
>
> On Mon, Apr 1, 2019, at 03:51, Brandon Long wrote:
>
> Although I don't work on the Gmail imap anymore, I will say that we
> implemented a competing idea (AUTH LOGIN-CLIENTTOKEN), though we eventually
> decided to concentrate on OAUTHBEARER.  OAUTH authorizes each client
> separately, so provides the same client based benefits.
>
> If this became standard, we could implement it, but I haven't really seen
> consensus on it yet, or adoption by a working group.  When it matures, we
> would need to look at how many 'legacy' auth users we have , and the
> benefits to that population.
>
> Brandon
>
> On Sat, Mar 30, 2019, 11:11 AM Gene Smith <gds@chartertn.net> wrote:
>
> Thunderbird has recently received a patch to add a CLIENTID capability
> which can be seen here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1532388.
>
> This includes links to the draft RFCs for IMAP and SMTP. I have been
> unable to find any other information on this feature. Is it supported or
> plaanned to be supported on any other IMAP or SMTP server?
>
> -gene
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
> --
>   Bron Gondwana
>   brong@fastmail.fm
>
>
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20190402/10ab392f/attachment.html>
