MBOX-Line: From tjs at psaux.com  Tue Oct 31 19:04:36 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: <ae75defb-739d-e1e0-69d1-0a21c89efaf1@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>
Message-ID: <CAByav=hQJDvRjYtTDnU0+B5MfzbpLfhjAvCgxhCvDfjj9jeA3Q@mail.gmail.com>

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


On Tue, Oct 31, 2017 at 3:45 PM, Gene Smith <gds@chartertn.net> wrote:

> On 10/31/17 5:02 PM, ?ngel 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 line
>>>   begins with an R, and if the line begins with a Q or if end of file is
>>>   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 problem
> 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
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20171031/0a8011ee/attachment.html>
