88 lines
3.5 KiB
Plaintext
88 lines
3.5 KiB
Plaintext
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>
|