Re: [Imap-protocol] authenticate LOGIN question
Tim Showalter <[email protected]> Tue, 31 Oct 2017 19:04:36 -0700
| Newsgroups | gmane.mail.imap.general |
|---|---|
| Message-ID | <CAByav=hQJDvRjYtTDnU0+B5MfzbpLfhjAvCgxhCvDfjj9jeA3Q@mail.gmail.com> |
--===============1000257852182048520== Content-Type: multipart/alternative; boundary="94eb2c0943ee2bf1dc055ce24bb2" --94eb2c0943ee2bf1dc055ce24bb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I haven't worked on the Y! IMAP server in several years at this point, and I can't speak for their current implementation. I know that they have rewritten a lot of it since I left. But it is quite possible that it's simply a bug. I don't know which clients would still support AUTH=3DLOGIN. I would not advise any client to use AUTH=3DLOGIN, particularly not if PLAIN is available. LOGIN is not a good mechanism, and is strictly worse than both basic LOGIN and PLAIN. It's just more round trips for what I recall to be a silly protocol. Tim On Tue, Oct 31, 2017 at 3:45 PM, Gene Smith <[email protected]> wrote: > On 10/31/17 5:02 PM, =C3=81ngel wrote: > >> Copying you in CC, Gene as the mailing list thinks this is spam... >> > > Thanks. > >> On 2017-10-27 at 01:23 -0400, Gene Smith wrote: >> >>> One that I did find that supports it, after providing the uid >>> and pwd, reports RENEGOTIATING and then openssl crashes. >>> >> >> You have entered in openssl a line beginning with uppercase R >> This made openssl to renegotiate the TLS connection, which many servers >> don't support. >> >> It is quite similar to that, but openssl s_client does not provide a >> transparent tunnel for tls connections. >> This is a common pitfall when testing smtp sending with starttls, as you >> can't issue "RCPT TO:" (the good news is that the protocol is case >> insensitive, so "rcpt to:" works). >> >> In IMAP the problematic letter will be at an identifier prefix, so the >> solution is simply to choose a different one. >> >> s_client(1) says about this: >> >>> When used interactively (which means neither -quiet nor >>> -ign_eof have been given), the session will be renegotiated if the li= ne >>> begins with an R, and if the line begins with a Q or if end of file i= s >>> reached, the connection will be closed down. >>> >> >> Best regards >> > > Thanks for the info on openssl/s_client. I did not know about this > behavior. You are right. The last thing I entered was the base64 encoded > password and it begins with R. That explains that. Just to be clear, this > is a different server that supports authenticate login and not the proble= m > yahoo server. > > So my question is still why yahoo (and possibly other servers that I > haven't encountered) won't accept the uid and password (both base64 > encoded) but claim to have authenticate login capability. This is using a > normal client or openssl and neither uid or password, after base64 > encoding, begin with R. > > -gene > > _______________________________________________ > Imap-protocol mailing list > [email protected] > http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol > --94eb2c0943ee2bf1dc055ce24bb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I haven't worked on the Y! IMAP server in several year= s at this point, and I can't speak for their current implementation. I = know that they have rewritten a lot of it since I left.<div><br></div><div>= But it is quite possible that it's simply a bug. I don't know which= clients would still support AUTH=3DLOGIN. I would not advise any client to= use AUTH=3DLOGIN, particularly not if PLAIN is available. LOGIN is not a g= ood mechanism, and is strictly worse than both basic LOGIN and PLAIN. It= 9;s just more round trips for what I recall to be a silly protocol.</div><d= iv><div><br></div><div>Tim</div><div><br></div></div></div><div class=3D"gm= ail_extra"><br><div class=3D"gmail_quote">On Tue, Oct 31, 2017 at 3:45 PM, = Gene Smith <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" targe= t=3D"_blank">[email protected]</a>></span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex">On 10/31/17 5:02 PM, =C3=81ngel wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Copying you in CC, Gene as the mailing list thinks this is spam...<br> </blockquote> <br> Thanks.<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><span class=3D""> On 2017-10-27 at 01:23 -0400, Gene Smith wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> One that I did find that supports it, after providing the uid<br> and pwd, reports RENEGOTIATING and then openssl crashes.<br> </blockquote> <br></span> You have entered in openssl a line beginning with uppercase R<br> This made openssl to renegotiate the TLS connection, which many servers<br> don't support.<br> <br> It is quite similar to that, but openssl s_client does not provide a<br> transparent tunnel for tls connections.<br> This is a common pitfall when testing smtp sending with starttls, as you<br= > can't issue "RCPT TO:" (the good news is that the protocol is= case<br> insensitive, so "rcpt to:" works).<br> <br> In IMAP the problematic letter will be at an identifier prefix, so the<br> solution is simply to choose a different one.<br> <br> s_client(1) says about this:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =C2=A0 When used interactively (which means neither -quiet nor<br> =C2=A0 -ign_eof have been given), the session will be renegotiated if the l= ine<br> =C2=A0 begins with an R, and if the line begins with a Q or if end of file = is<br> =C2=A0 reached, the connection will be closed down.<br> </blockquote> <br> Best regards<br> </blockquote> <br> Thanks for the info on openssl/s_client. I did not know about this behavior= . You are right. The last thing I entered was the base64 encoded password a= nd it begins with R. That explains that. Just to be clear, this is a differ= ent server that supports authenticate login and not the problem yahoo serve= r.<br> <br> So my question is still why yahoo (and possibly other servers that I haven&= #39;t encountered) won't accept the uid and password (both base64 encod= ed) but claim to have authenticate login capability. This is using a normal= client or openssl and neither uid or password, after base64 encoding, begi= n with R.<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br> -gene</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br> ______________________________<wbr>_________________<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.<wbr>e= du/mailman/listinfo/imap-prot<wbr>ocol</a><br> </div></div></blockquote></div><br></div> --94eb2c0943ee2bf1dc055ce24bb2-- --===============1000257852182048520== 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 --===============1000257852182048520==--