wasm-demo/demo/ermis-f/imap-protocol/cur/1600094993.22538.mbox:2,S

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