On Tue, Jan 09, 2007 at 01:31:42PM -0700, Jackie Hunt wrote:
But just stripping the STARTTLS from the CAPABILITY like this:
...
(watch wrapping) should be sufficient.
Of course, if the real issue is that the users are frightened by the unsigned certificate message, he could pony up the $100 for a cert signed by a trusted authority and the clients won't even bleat...
Thanks much for the feedback John & Timo. I hope you do add ssl_disable_tls as an option in v 2.0 Timo. That's be great.
Our users run a wide variety of clients, so it'd be difficult to confirm that we wouldn't affect someone with the TLS capability, even with a trusted authority. Changing source is an option, true. The other option is sslwrap, which we use with UofW. We could disable ssl on Dovecot and use sslwrap for 993. I just wanted to use Timo's code where possible.
STARTTLS is a newer standard than allocating separate ports for the SSL-equivalents. Note that IMAP, POP, and SMTP protocols all support this (it is called STLS in POP) and it is generally preferred over the SSL-at-connect ports (465, 993, 995). If we turned one or the other one off, it would certainly not be the STARTTLS-enabled ports (110, 143, 587). Note, however, that we still require STARTTLS (we don't allow plain-text connections due to the lack of password security it would imply.)
If I were you, I'd add another IP alias on the host (an additional IP address) in which you could run Dovecot on, so as not to interfere with your existing software listening on the existing IP address. This may or may not work for you, depending on how you are transitioning, but I just wanted to make that suggestion.
Jackie
Jackie Hunt
ACNS Voice: (970) 663-3789
Colorado State University FAX: (970) 491-1958 Fort Collins, CO 80523 Email: jackie.hunt@colostate.edu
--
Steven F. Siirila Office: Lind Hall, Room 130B Internet Services E-mail: sfs@umn.edu Office of Information Technology Voice: (612) 626-0244 University of Minnesota Fax: (612) 626-7593