Re: [Imap-protocol] CLIENTID capability for IMAP (and SMTP)
"Bron Gondwana" <[email protected]> Mon, 01 Apr 2019 21:07:05 -0400
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <[email protected]> |
--===============4556930583047340979==
Content-Type: multipart/alternative;
boundary=14a03e1d7a484d9f8a0c67c97110e1fd
--14a03e1d7a484d9f8a0c67c97110e1fd
Content-Type: text/plain
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]
--14a03e1d7a484d9f8a0c67c97110e1fd
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}
p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div style=3D"f=
ont-family:Arial;">For what it's worth, this work was brought to the EXT=
RA working group at IETF at Montreal last year, and the group decided th=
at it wasn't the right level in the stack for this kind of ID - that it =
would be better placed in the SASL layer.<br></div><div style=3D"font-fa=
mily:Arial;"><br></div><div style=3D"font-family:Arial;">The OAUTH techn=
ique also strikes me as a better long-term solution, because it means th=
at users aren't entering their own selected password to be stored on dis=
k by clients.<br></div><div style=3D"font-family:Arial;"><br></div><div =
style=3D"font-family:Arial;">On the flip side, I'm sensitive to the argu=
ment from Linux Magic that this solves a problem RIGHT NOW which a perfe=
ct future solution might solve better, but a future solution doesn't fix=
anything for the current environment.<br></div><div style=3D"font-famil=
y:Arial;"><br></div><div style=3D"font-family:Arial;">Regarding the disc=
ussion on bugzilla - I would agree that it's quite important that the sa=
me ID MUST NOT be sent to different servers - the CLIENTID should be gen=
erated as a unique hash over ('deviceid', 'username', 'domain').<br></di=
v><div style=3D"font-family:Arial;"><br></div><div style=3D"font-family:=
Arial;">Bron.<br></div><div style=3D"font-family:Arial;"><br></div><div =
style=3D"font-family:Arial;">On Mon, Apr 1, 2019, at 03:51, Brandon Long=
wrote:<br></div><blockquote id=3D"fastmail-quoted" type=3D"cite"><div d=
ir=3D"auto"><div style=3D"font-family:Arial;">Although I don't work on t=
he 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.<br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">If this became standard, we could implement it, but I hav=
en't really seen consensus on it yet, or adoption by a working group.&nb=
sp; When it matures, we would need to look at how many 'legacy' auth use=
rs we have , and the benefits to that population.<br></div><div dir=3D"a=
uto"><br></div><div dir=3D"auto">Brandon<br></div></div><div style=3D"fo=
nt-family:Arial;"><br></div><div class=3D"fastmail-quoted-gmail_quote"><=
div dir=3D"ltr" class=3D"fastmail-quoted-gmail_attr">On Sat, Mar 30, 201=
9, 11:11 AM Gene Smith <<a href=3D"mailto:[email protected]">gds@char=
tertn.net</a>> wrote:<br></div><blockquote class=3D"fastmail-quoted-g=
mail_quote" style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;m=
argin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:=
solid;border-left-width:1px;padding-left:1ex;"><div style=3D"font-family=
:Arial;">Thunderbird has recently received a patch to add a CLIENTID cap=
ability <br></div><div style=3D"font-family:Arial;">which can be seen he=
re: <br></div><div style=3D"font-family:Arial;"><a href=3D"https://bugzi=
lla.mozilla.org/show_bug.cgi?id=3D1532388" rel=3D"noreferrer noreferrer"=
>https://bugzilla.mozilla.org/show_bug.cgi?id=3D1532388</a>.<br></div><d=
iv style=3D"font-family:Arial;"><br></div><div style=3D"font-family:Aria=
l;">This includes links to the draft RFCs for IMAP and SMTP. I have been=
<br></div><div style=3D"font-family:Arial;">unable to find any other in=
formation on this feature. Is it supported or <br></div><div style=3D"fo=
nt-family:Arial;">plaanned to be supported on any other IMAP or SMTP ser=
ver?<br></div><div style=3D"font-family: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-f=
amily:Arial;"><a href=3D"mailto:[email protected]" rel=3D"n=
oreferrer">[email protected]</a><br></div><div style=3D"fon=
t-family:Arial;"><a href=3D"http://mailman13.u.washington.edu/mailman/li=
stinfo/imap-protocol" rel=3D"noreferrer noreferrer">http://mailman13.u.w=
ashington.edu/mailman/listinfo/imap-protocol</a><br></div></blockquote><=
/div><div>_______________________________________________<br></div><div>=
Imap-protocol mailing list<br></div><div>[email protected]<=
br></div><div>http://mailman13.u.washington.edu/mailman/listinfo/imap-pr=
otocol<br></div></blockquote><div style=3D"font-family:Arial;"><br></div=
><div id=3D"sig567075"><div class=3D"signature">-- <br></div><div c=
lass=3D"signature"> Bron Gondwana<br></div><div class=3D"signature=
"> [email protected]<br></div><div class=3D"signature"><br></div><=
/div><div style=3D"font-family:Arial;"><br></div></body></html>
--14a03e1d7a484d9f8a0c67c97110e1fd--
--===============4556930583047340979==
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
--===============4556930583047340979==--