Hi,

I have a postfix+dovecot-2.2.13 system and have configured it to support IMAPS on 993 with SSL/TLS. I'm noticing with users using Thunderbird, the autodetect defaults to IMAPS on 143 with STARTTLS.

Which is preferred? Which is more secure? Which is more common?

Why would someone choose one over the other?

Can I ask the same question about SMTP and submission? Why would one choose 587 with STARTTLS versus 465 with SSL/TLS?

Thanks, Alex Implicit SSL ports were specified before STARTTLS was specified,

On 08/17/2014 10:45 PM, Alex wrote: therefore they are considered deprecated. There is no major difference between the two in terms of security or functionality. Ultimately they both just work. And ultimately you probably want to simply support both for maximum compatibility. (For older versions of Microsoft Outlook you _must_ support port 465 because they didn't support STARTTLS, although I don't know how many of these are still out there.) Technically one can argue that STARTTLS is less secure because it starts off in plaintext (there even was an exploit recently against STARTTLS in nginx's SMTP proxy [1]) but that's anecdotal in my opinion, and the general opinion seems to be in favor of deprecating 993/995/465. A man-in-the-middle can very easily filter out STARTTLS from the conversation and this would be effective against _opportunistic_ STARTTLS, but the equivalent of port 993 is a client that requires STARTTLS and refuses to log in otherwise. From an admin's point of view, you would prefer to support just one port per service, and 110/143/25 are the "real" standard ports and people seem to lean towards that.

Whatever anyone says about this topic will start a flamewar.

[1] http://nginx.org/en/CHANGES-1.6

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