56 lines
2.3 KiB
Plaintext
56 lines
2.3 KiB
Plaintext
MBOX-Line: From gds at chartertn.net Tue Oct 31 15:45:05 2017
|
|
To: imap-protocol@u.washington.edu
|
|
From: Gene Smith <gds@chartertn.net>
|
|
Date: Fri Jun 8 12:34:55 2018
|
|
Subject: [Imap-protocol] authenticate LOGIN question
|
|
In-Reply-To: <1509483762.929.2.camel@16bits.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>
|
|
Message-ID: <ae75defb-739d-e1e0-69d1-0a21c89efaf1@chartertn.net>
|
|
|
|
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
|
|
|