88 lines
3.4 KiB
Plaintext
88 lines
3.4 KiB
Plaintext
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>
|