On Sun, Jul 26, 2015 at 08:58:52AM +0200, Moritz Schmitt wrote:
> Thanks a lot for your very helpful reply!
>
> I implemented all the changes you suggested and now it works. My late
> reply is due to the fact that I needed to wait for another mail from
> outlook.com to see if everything works.
>
> What I find a little odd about outlook.com's behavior is that if it
> isn't able to establish a TLS connection to my server, that it doesn't
> retry an unencrypted connection. So in a sense they are treating my
> 'opportunistic TLS' as 'mandatory TLS'.
I am glad to hear that the recommended configuration tweaks worked.
This suggests that the problem analysis was very likely correct.
According to my outlook.com/microsoft contacts [Bcc'd], the expected
behaviour is cleartext retries. I don't know why that did not
happen for your domain.
In any case, I am still optimistic that it will be possible to
improve the opportunistic TLS support on the outlook.com side. I
don't think it makes sense to switch from TLS to cleartext just
becase the TLS crypto parameters were not "secure enough". Surely
cleartext is not more secure than somewhat dated crypto algorithms!
That said, dated algorithms need not be supported in perpetuity,
rather with opportunistic TLS we support them while they are still
required for interoperability with a sufficient number of peers.
Once better options are nearly universally available, and disabling
the deprecated algorithms causes no significant uptick in cleartext
use, then the deprecated algorithms can be disabled.
In the case of "export" ciphersuites, as a result of "logjam" it
is possible to downgrade security even for clients that don't
support "export" ciphers. Thus, just recently, Postfix 3.0.2 and
the other supported stable releases were all updated to by default
no longer use "export" ciphers, SSLv2, SSLv3, or single-DES. None
of these are believed to be needed to interoperate with a non-negligible
number of mail servers on the public Internet. Sites that still
need (say SSLv3) can reenable that as needed.
On the other hand, systems that only support RC4 are still somewhat
common. Though RC4 is deprecated, it is (for now) premature to
refuse TLS with such systems.
Not that when using unauthenticated opportunistic TLS, SMTP clients
ignore inability to authenticate server certificates (untrusted
chains and "wrong" subject names are tolerated). It then makes
little sense to insist that no deprecated algorithms are used in
the ignored certificates.
Therefore, in unauthenticated opportunistic TLS, *all* certificate
"problems" should be ignored. The threat model is passive-monitoring
not active attack. Encrypt if at all possible, regardless of any
certificate chain defects.
https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-19#section-1.3
If for a particular destination, authentication is employed, *then*
make sure the certificate can be adequately trusted (but signature
algorithms in self-signed "root" certificates should still be
ignored).
Thanks for the follow-up message, good luck.
--
Viktor.
