MBOX-Line: From tjs at psaux.com  Tue Oct 31 21:43:16 2017
To: imap-protocol@u.washington.edu
From: Tim Showalter <tjs@psaux.com>
Date: Fri Jun  8 12:34:55 2018
Subject: [Imap-protocol] authenticate LOGIN question
In-Reply-To: <ba8ab6ae-7ef4-be62-6411-73f66e7e531b@chartertn.net>
References: <38137c2b-f1f1-2bed-e22f-2aea7fa50ac3@chartertn.net>
	<CAByav=gBnVkLg+4z90ewBvKRVtOrEQ7XESfirEQ1dyx=Sb0MXw@mail.gmail.com>
	<8204fbd1-3679-c8cc-7f92-d4307867ece0@chartertn.net>
	<1509483762.929.2.camel@16bits.net>
	<ae75defb-739d-e1e0-69d1-0a21c89efaf1@chartertn.net>
	<CAByav=hQJDvRjYtTDnU0+B5MfzbpLfhjAvCgxhCvDfjj9jeA3Q@mail.gmail.com>
	<ba8ab6ae-7ef4-be62-6411-73f66e7e531b@chartertn.net>
Message-ID: <CAByav=gs8qHW9WKvRR2J0MYHpLQ_GBpYesxGZo7oGNb+ae6axw@mail.gmail.com>

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 <gds@chartertn.net> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171031/9d001b6e/attachment.html>
