Re: [Imap-protocol] CLIENTID capability for IMAP (and SMTP)

--===============7153904050216617456==
Content-Type: multipart/alternative; boundary="000000000000eeb8eb05858de1f4"

--000000000000eeb8eb05858de1f4
Content-Type: text/plain; charset="UTF-8"

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 <[email protected]> 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 <[email protected]> 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
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
> _______________________________________________
> Imap-protocol mailing list
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
>
> --
>   Bron Gondwana
>   [email protected]
>
>
> _______________________________________________
> Imap-protocol mailing list
> [email protected]
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

--000000000000eeb8eb05858de1f4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">See also:=C2=A0<a href=3D"https://tools.ietf.org/html/draf=
t-cridland-kitten-clientkey-00">https://tools.ietf.org/html/draft-cridland-=
kitten-clientkey-00</a><div><br></div><div>I implemented this in XMPP for v=
arious reasons, but there&#39;s no particular reason it couldn&#39;t be use=
d for IMAP et al.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Tue, 2 Apr 2019 at 02:08, Bron Gondwana &lt;<a hr=
ef=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div style=3D"=
font-family:Arial">For what it&#39;s worth, this work was brought to the EX=
TRA working group at IETF at Montreal last year, and the group decided that=
 it wasn&#39;t the right level in the stack for this kind of ID - that it w=
ould be better placed in the SASL layer.<br></div><div style=3D"font-family=
:Arial"><br></div><div style=3D"font-family:Arial">The OAUTH technique also=
 strikes me as a better long-term solution, because it means that users are=
n&#39;t entering their own selected password to be stored on disk by client=
s.<br></div><div style=3D"font-family:Arial"><br></div><div style=3D"font-f=
amily:Arial">On the flip side, I&#39;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&#39;t fix anything for the=
 current environment.<br></div><div style=3D"font-family:Arial"><br></div><=
div style=3D"font-family:Arial">Regarding the discussion on bugzilla - I wo=
uld agree that it&#39;s quite important that the same ID MUST NOT be sent t=
o different servers - the CLIENTID should be generated as a unique hash ove=
r (&#39;deviceid&#39;, &#39;username&#39;, &#39;domain&#39;).<br></div><div=
 style=3D"font-family:Arial"><br></div><div style=3D"font-family:Arial">Bro=
n.<br></div><div style=3D"font-family:Arial"><br></div><div style=3D"font-f=
amily:Arial">On Mon, Apr 1, 2019, at 03:51, Brandon Long wrote:<br></div><b=
lockquote id=3D"gmail-m_-5653341517354459613fastmail-quoted" type=3D"cite">=
<div dir=3D"auto"><div style=3D"font-family:Arial">Although I don&#39;t wor=
k on the Gmail imap anymore, I will say that we implemented a competing ide=
a (AUTH LOGIN-CLIENTTOKEN), though we eventually decided to concentrate on =
OAUTHBEARER.=C2=A0 OAUTH authorizes each client separately, so provides the=
 same client based benefits.<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">If this became standard, we could implement it, but I haven&#39;t=
 really seen consensus on it yet, or adoption by a working group.=C2=A0 Whe=
n it matures, we would need to look at how many &#39;legacy&#39; auth users=
 we have , and the benefits to that population.<br></div><div dir=3D"auto">=
<br></div><div dir=3D"auto">Brandon<br></div></div><div style=3D"font-famil=
y:Arial"><br></div><div class=3D"gmail-m_-5653341517354459613fastmail-quote=
d-gmail_quote"><div dir=3D"ltr" class=3D"gmail-m_-5653341517354459613fastma=
il-quoted-gmail_attr">On Sat, Mar 30, 2019, 11:11 AM Gene Smith &lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt; w=
rote:<br></div><blockquote class=3D"gmail-m_-5653341517354459613fastmail-qu=
oted-gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial">Thunderb=
ird has recently received a patch to add a CLIENTID capability <br></div><d=
iv style=3D"font-family:Arial">which can be seen here: <br></div><div style=
=3D"font-family:Arial"><a href=3D"https://bugzilla.mozilla.org/show_bug.cgi=
?id=3D1532388" rel=3D"noreferrer noreferrer" target=3D"_blank">https://bugz=
illa.mozilla.org/show_bug.cgi?id=3D1532388</a>.<br></div><div style=3D"font=
-family:Arial"><br></div><div style=3D"font-family:Arial">This includes lin=
ks to the draft RFCs for IMAP and SMTP. I have been <br></div><div style=3D=
"font-family:Arial">unable to find any other information on this feature. I=
s it supported or <br></div><div style=3D"font-family:Arial">plaanned to be=
 supported on any other IMAP or SMTP server?<br></div><div style=3D"font-fa=
mily:Arial"><br></div><div style=3D"font-family:Arial">-gene<br></div><div =
style=3D"font-family:Arial">_______________________________________________=
<br></div><div style=3D"font-family:Arial">Imap-protocol mailing list<br></=
div><div style=3D"font-family:Arial"><a href=3D"mailto:[email protected]=
ington.edu" rel=3D"noreferrer" target=3D"_blank">[email protected]=
.edu</a><br></div><div style=3D"font-family:Arial"><a href=3D"http://mailma=
n13.u.washington.edu/mailman/listinfo/imap-protocol" rel=3D"noreferrer nore=
ferrer" target=3D"_blank">http://mailman13.u.washington.edu/mailman/listinf=
o/imap-protocol</a><br></div></blockquote></div><div>______________________=
_________________________<br></div><div>Imap-protocol mailing list<br></div=
><div><a href=3D"mailto:[email protected]" target=3D"_blank">I=
[email protected]</a><br></div><div><a href=3D"http://mailman13=
.u.washington.edu/mailman/listinfo/imap-protocol" target=3D"_blank">http://=
mailman13.u.washington.edu/mailman/listinfo/imap-protocol</a><br></div></bl=
ockquote><div style=3D"font-family:Arial"><br></div><div id=3D"gmail-m_-565=
3341517354459613sig567075"><div class=3D"gmail-m_-5653341517354459613signat=
ure">--=C2=A0<br></div><div class=3D"gmail-m_-5653341517354459613signature"=
>=C2=A0 Bron Gondwana<br></div><div class=3D"gmail-m_-5653341517354459613si=
gnature">=C2=A0 <a href=3D"mailto:[email protected]" target=3D"_blank">bron=
[email protected]</a><br></div><div class=3D"gmail-m_-5653341517354459613signat=
ure"><br></div></div><div style=3D"font-family:Arial"><br></div></div>_____=
__________________________________________<br>
Imap-protocol mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">Imap-pr=
[email protected]</a><br>
<a href=3D"http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol=
" rel=3D"noreferrer" target=3D"_blank">http://mailman13.u.washington.edu/ma=
ilman/listinfo/imap-protocol</a></blockquote></div>

--000000000000eeb8eb05858de1f4--

--===============7153904050216617456==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
--===============7153904050216617456==--