Re: [Imap-protocol] authenticate LOGIN question

--===============6607010197433115463==
Content-Type: multipart/alternative; boundary="001a113ce9469ab654055ce482bb"

--001a113ce9469ab654055ce482bb
Content-Type: text/plain; charset="UTF-8"

No clue -- sorry. I am not even sure if any code I worked on is still being
used there.

Tim

On Tue, Oct 31, 2017 at 9:35 PM, Gene Smith <[email protected]> wrote:

> On 10/31/17 10:04 PM, Tim Showalter wrote:
>
>> 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=LOGIN. I would not advise any client to
>> use AUTH=LOGIN, 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
>>
>
> Ok, thanks for the input. It does seem like a bug in that auth LOGIN
> doesn't work for yahoo at all. Also, in thunderbird, it only uses auth
> LOGIN if PLAIN fails for some reason. Then it sends the uid/pwd using auth
> LOGIN (that always fails for yahoo) finally it tries imap login.
>
> I also notice an anomaly with yahoo's authenticate PLAIN that maybe you
> can explain. If you give it a bad auth string after the + response it tells
> you the credentials are bad with another + prompt. If I respond with a good
> auth string it still fails. Apparently the 2nd + prompt is not really
> requesting a corrected auth string. If so, what is the 2nd prompt for? I
> have seen no other imap servers doing this double prompting when a bad auth
> string is sent.
>
> Here's what happens when tb talks to yahoo (yh) doing auth PLAIN when a
> bad auth string is provided followed by a good one:
>
> tb:  1 authenticate PLAIN
> yh:  +
> tb:  <BAD encoded auth string> <--- changed the 5th char to 'z', was 'd'
> yh:  + <encode string saying auth string is bad>
> tb:  <GOOD encoded auth string> <--- I returned the 5th char back to 'd'
> yh:  1 NO [AUTHENTICATIONFAILED] AUTHENTICATE Invalid credentials
>
> -gene
>

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

<div dir=3D"ltr">No clue -- sorry. I am not even sure if any code I worked =
on is still being used there.<div><div><div><div><br></div><div>Tim</div></=
div></div></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On Tue, Oct 31, 2017 at 9:35 PM, Gene Smith <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt=
;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 10/31=
/17 10:04 PM, Tim Showalter wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I haven&#39;t worked on the Y! IMAP server in several years at this point, =
and I can&#39;t speak for their current implementation. I know that they ha=
ve rewritten a lot of it since I left.<br>
<br>
But it is quite possible that it&#39;s simply a bug. I don&#39;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&#3=
9;s just more round trips for what I recall to be a silly protocol.<br>
<br>
Tim<br>
</blockquote>
<br></span>
Ok, thanks for the input. It does seem like a bug in that auth LOGIN doesn&=
#39;t work for yahoo at all. Also, in thunderbird, it only uses auth LOGIN =
if PLAIN fails for some reason. Then it sends the uid/pwd using auth LOGIN =
(that always fails for yahoo) finally it tries imap login.<br>
<br>
I also notice an anomaly with yahoo&#39;s authenticate PLAIN that maybe you=
 can explain. If you give it a bad auth string after the + response it tell=
s you the credentials are bad with another + prompt. If I respond with a go=
od auth string it still fails. Apparently the 2nd + prompt is not really re=
questing a corrected auth string. If so, what is the 2nd prompt for? I have=
 seen no other imap servers doing this double prompting when a bad auth str=
ing is sent.<br>
<br>
Here&#39;s what happens when tb talks to yahoo (yh) doing auth PLAIN when a=
 bad auth string is provided followed by a good one:<br>
<br>
tb:=C2=A0 1 authenticate PLAIN<br>
yh:=C2=A0 +<br>
tb:=C2=A0 &lt;BAD encoded auth string&gt; &lt;--- changed the 5th char to &=
#39;z&#39;, was &#39;d&#39;<br>
yh:=C2=A0 + &lt;encode string saying auth string is bad&gt;<br>
tb:=C2=A0 &lt;GOOD encoded auth string&gt; &lt;--- I returned the 5th char =
back to &#39;d&#39;<br>
yh:=C2=A0 1 NO [AUTHENTICATIONFAILED] AUTHENTICATE Invalid credentials<span=
 class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
-gene<br>
</font></span></blockquote></div><br></div>

--001a113ce9469ab654055ce482bb--

--===============6607010197433115463==
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
--===============6607010197433115463==--