Re: [Classpath-inetlib] imap and ssl, again

[Ruben Malchow]

hello

thanks for adding the non-negotiated stuff.

> The most restrictive would reject all certificates. The starttls method 
> with no arguments would be redundant; you couldn't use it.

i had the impressoion that the 1.0 code would accept all certificates.
maybe i was wrong. what i meant by "most restrictive" is that it should
accept certs based on the vm-wide, default key/cert store.

> We could provide the ability to specify a KeyManager as well. This would 
> only be useful, though, if the server used SSL authentication to 
> authenticate the user. In my experience that hasn't been the case, 
> although perhaps it's a feature server vendors are starting to 
> implement? However, the IMAPConnection would need to intercept that 
> exchange in order to determine whether authentication had taken place, 
> so you couldn't simply provide a configured SSLContext.

true. so i guess there's no way to do this in a simple way. client 
certificates are not really required in my opinion. there still are 
others mechanisms for authenticating the client. when i was talking 
about keys, i was really talking about certificates, anyway. sorry for 
being unclear about that.

> The real problem is that Session only deals with string properties. 
> Otherwise you could bind a fully-configured TrustManager into the 
> session. Having mail.trustmanager.XXX properties sounds like a feasible 
> workaround.

unless we introduce a hook for subclassing i would still have to change 
the source. i could do that, but maybe one of you guys has a better idea.

> Are there use cases for this (tunnelling other inetlib protocols over SSL)?

pop3-over-ssl (on port 995) is the only thing i can think of right now. 
same thing, basically. is there an rfc on that?

.rm