On 9 Apr 2016, at 12:45, jaso...@mail-central.com wrote:
I block on strict FAILs of any if SPF, DKIM or DMARC. *missing*
support for those is logged, but not - yet - acted on.
This is dangerous, as is raising the bar too high on ciphersuites.
Case in point: Ditech is one of the largest mortgage servicing companies
in the US, servicing millions of loans ultimately held by the federal
government. They send email responses to customer service inquiries out
via Microsoft's Office365 service, which signs it for the
"gtservicing.onmicrosoft.com" domain, but has it routed through Cisco
(formerly Ironport's) "iphmx.com" infrastructure for no visible reason,
where the From header is apparently re-written to
<donotre...@ditech.com>, breaking the DKIM signature. While the
iphmx.com machines accept mail from Microsoft using the suboptimal
AES256-SHA ciphersuite, they inexplicably use the affirmatively weak
TLSv1/RC4-SHA to pass it along. Because of this arcane routing, the
envelope sender (donotre...@gtservicing.com) has a domain with an SPF
record that is invalid due to its excessive complexity. Topping this
off, their messages consistently contain nothing but a bunch of
disclaimer boilerplate plus a link to the REAL message (which thankfully
is also usually low-content boilerplate) in a .doc file on the
sharefile.com service, with no authentication required to access the
link.
This is how security-competent a significant US financial services
company is regarding email: broken DKIM signatures, invalid SPF records,
and confidential information regarding mortgage accounts sitting at URLs
accessible by anyone who can intercept a piece of email which AT BEST is
transported using encryption which may be crackable in reasonable time
by entities much weaker than the NSA.
BUT: People *REALLY* want their customer service email from Ditech. If
you block invalid SPF, it fails. If you block invalid DKIM signatures,
it fails. If you require strong encryption, it fails. It is possible (I
have not tested...) that if you require strong encryption or none ("may"
with a restrictive cipherlist) they may deliver potentially critically
private information in the clear.
Welcome to 2016: Sturgeon's Law remains in effect.
