On -10.01.-28163 20:59, Alex wrote:
Why would someone choose one over the other?
There's no *global* reason to choose one over the other AFAIK, but I've seen individual projects find reasons ruling out the STARTTLS approach. Most of them were variations of "we want SSL and $INTERIOR_PROTOCOL provided by different, non-integrated solutions" - from crypto-enabling a legacy system (just slap socat/stunnel/whatever in front of it to provide the SSL) to inserting a content scanner of your choice to hardware crypto accelerators that literally aren't built to provide the SSL-wrapped service.
Then there's the occasional client that needs to be installed someplace where the network admins, CSO, company policy, ... just say "no" to connections that *possibly could* wind up being unencrypted.
I'm not aware of a case where STARTTLS was OK but native SSL got *firmly* ruled out (though I *do* know some organizations who pay their firewalling providers heftily per year *and rule*).
Can I ask the same question about SMTP and submission?
For areas where you control (directly, or per mutual agreement) both servers and clients, the situation's the same as for IMAP.
For MTAs exchanging e-mails with anywhere in the Internet the DNS points them to, anything not available via port 25 plain doesn't (yet?) exist, of course.
And then there's the occasional enabled-by-default Cisco SMTP Fixup getting in the way of STARTTLS ... :-C
Regards, J. Bern
*NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel