On Sun, Dec 06, 2009 at 04:23:36PM +0000, Dick Middleton wrote:
I bring it up again because I've just been trying the release candidate for Thunderbird 3. This has a config wizard which derives from ones email address the mail server address etc. It doesn't handle SSL virtual mail servers very well because of this problem.
I'd consider that a bug in the wizard, wouldn't you?
I have encountered a web server called Cherokee (http://www.cherokee-project.com) which has virtual server capability that *demands* a different certificate for each virtual server. How can that be I thought?
This is what Cherokee documentation says: [snip] Cherokee supports the clean and standard method of dealing with this issue called Server Name Indication (SNI) that sends the name of the virtual host during the TLS negotiation.
If SNI is supported by your SSL/TLS library, the SSL layer does not need to be restarted. Since the host info can be put in the SSL handshake, things will simply work as long as there is a web browser with SNI support at the other side. Currently every modern web browser supports this, and Cherokee has TLS SNI support for the OpenSSL backends.
Note that for SNI to work, client support is required. Web browsers known to support it are Mozilla Firefox 2.0+, Opera 8.0+, Internet Explorer 7 (Vista, not XP) or later and Google Chrome. </QUOTE>
If Cherokee can do it why not dovecot? Is this something that is, or could be, being considered? It does assume that TB3 and other mail clients support SNI but whatever, I suspect that once TB3 is released the subject will pop-up more frequently.
It also assumes that the IMAP protocol has SNI support. IMAP != HTTP.
I don't know, but my thought is "don't hold your breath." Consider TLS in IMAP and SMTP. The protocols were years ahead of the clients. Even now we see lots of issues with MUAs with inadequate (or NO) TLS support.
Offlist mail to this address is discarded unless
"/dev/rob0" or "not-spam" is in Subject: header