cpw.ivan: d849dc2a: This is kind of controversial, but appar...

[Ivan Komarov]

Hm, I'm sorry, I accidentally replied to Paul instead of replying to
everyone. It seems like we have already settled on a solution, but I'd
like to send a copy of my letter to Paul to the list just in case.

2010/11/2 Paul Aurich <paul at darkrain42.org>:
>>> Ah, that was a complete oversight on my part (mitigated by the fact the
>>> AOL servers behaved *properly* here ;) ).  Yeah, I think that should
>>> result in an error (if a strict TLS option is selected), or a refusal to
>>> initiate a connection to that server (which is a subtle error
>>> condition...and really user-unfriendly).
>>>
>>
>> I like the former option better. I propose we just
>> purple_connection_error_reason().
>> I'm not sure what the error message should contain, though.
>> "This server doesn't support encryption"?
>
> "One of the servers used for this account does not support encryption."
> (or similar).  Something that gives a hint as to why this would randomly
> pop up in the middle of a connection.
>
>>
>>> Except in the cases of SNAC_FAMILY_ADMIN and SNAC_FAMILY_BART (which are
>>> explicitly moved back to non-SSL currently), where I was never able to
>>> figure out how to get to work properly.  I even hacked in SSL session
>>> resumption support (since that appears to be how it's "supposed" to
>>> work, based on AOL's now-gone documentation), and even that failed.
>>
>> Yeah, I saw that in the code. Maybe Pavel from mail.ru can find out
>> why they don't work the way they're supposed to.
>
> If you get any insight from him, let me know.  I'd love to get that code
> fixed, or at least insight into what it's supposed to do...
>
> ~Paul
>
>



-- 
Ivan Komarov