In message <500a9284-b549-460d-8207-f52534e09...@billmail.scconsult.com>
"Bill Cole" writes:
>
> 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.
Great anecdote of a really bad email setup but ...
For a lot of us missing out on Ditech, a specialist in preditory
lending, is not a compelling reason not to enable SPF, DKIM and DMARC.
For my domains (all automated DNS zone file generation) I publish SPF
and DKIM (and any relevant DNSSEC crud and TLSA) and was planning to
update the homegrown tool to add DMARC. By publishing those records,
you just avoid having someone forge mail as you (including to you, but
there are plenty of simpler ways to protect against that). I was also
planning to reject based on opendmarc at some point in the
not-so-distant future.
Curtis
