In late 2015, 15 million T-Mobile customers learned that they had been victims of a two-year security breach at Experian. Since then, the 150-million victim Equifax breach has made the Experian breach look kind of puny, but at the time it became public it was a Big [expletive] Deal.
Of course, a class-action lawsuit was filed against Experian shortly after the breach became public. In late 2018, a settlement was announced. The court gave final approval to the settlement in May 2019, and the administrators have recently begun notifying class members by email about how to claim the two years of free credit monitoring and identity theft insurance provided for in the settlement.
Unfortunately, most of the victims will never see those emails because of gross incompetence and malfeasance by the people sending them.
The emails are being sent with this From line:
From: "In re Experian Data Breach Litigation Settlement Administrator" <donotreply@classact.com>
The domain “classact.com” shown in the From line is protected by this DMARC policy:
$ host -t txt _dmarc.classact.com _dmarc.classact.com descriptive text "v=DMARC1; pct=100; p=reject; sp=reject; adkim=r; aspf=r"
DMARC is an email authentication policy protocol. It tells servers that receive email from a domain what to do if they’re unable to verify from the headers that the email actually comes from that domain. The policy shown above says to reject (“p=reject“) all (“pct=100“) messages that can’t be verified.
Unfortunately, that includes the email messages from the settlement administrators, because the domain in the from line (“classact.com”) doesn’t match the domain of the servers sending the message (“bluehornet.com”).
As of 2017, 76% of email accounts in the world were on servers that enforce DMARC (ref). That number is even higher now. That means that the vast majority of victims who were sent this email are never going to see it, because their servers are going to reject it.
The incompetence displayed here is truly staggering.
I will be sending email to the settlement administrators (Robinson Calcagnie, Inc. and Ahdoot & Wolfson, PC) asking them to address this, but they will probably ignore me. After all, why should they care? They get their money whether or not the victims receive what they were promised. The only people who come out ahead in class-action lawsuits are the lawyers.
UPDATE: When I attempted to email the settlement administrators about this problem, my email bounced from two of the people on the list, because the list (info@expdatabreachsettlement.com) is hosted on outlook.com, which regularly modifies email messages when forwarding them and breaks DKIM signatures (ref), despite the fact that the people at Microsoft who run outlook.com have known about this problem for years.
Don’t believe it’s gross incompetence and malfeasance.
It’s pure Genius. Make it look like you are responsible and following the judge’s order. I am a TMO customer and I haven’t seen this email. Yes they successfully send all their marketing crap….
Great article, we should probably build and maintain a “DMARC test failures Hall Of Shame”, featuring the likes of Oracle, Trendmicro or Vodafone 🙂
Few examples:
1. Trendmicro headers:
—CUT HERE—
Authentication-Results: mx1/3B2A4E4549; dmarc=fail (p=reject dis=none) header.from=edmapac.trendmicro.com
Authentication-Results: mx1; spf=pass (mailfrom) smtp.mailfrom=envfrm.rsys2.com (client-ip=12.130.136.122; helo=omp.newsletters.trendmicro.com; envelope-from=tne.8780@envfrm.rsys2.com; receiver=)
From: =?ISO-8859-1?B?VHJlbmQgTWljcm8gQXVzdHJhbGlh?=
—CUT HERE—
Misconfiguration: domain alignment
header.from=edmapac.trendmicro.com
smtp.mailfrom=envfrm.rsys2.com
DNS: _dmarc.edmapac.trendmicro.com TXT “v=DMARC1; p=reject; pct=100”
2. Vodafone headers:
—CUT HERE—
Authentication-Results: mx1/45FB2E4AF4; dmarc=fail (p=reject dis=none) header.from=email.vodafone.com.au
Authentication-Results: mx1; spf=pass (mailfrom) smtp.mailfrom=envfrm.rsys5.com (client-ip=199.7.203.99; helo=omptrans.e.myvha.com.au; envelope-from=vha.51508@envfrm.rsys5.com; receiver=)
From: =?UTF-8?B?Vm9kYWZvbmU=?=
—CUT HERE—
Same misconfiguration – domain alignment:
header.from=email.vodafone.com.au
smtp.mailfrom=envfrm.rsys5.com
DNS: _dmarc.email.vodafone.com.au TXT “v=DMARC1; p=reject; pct=100”
How do such big guns get away with such crass incompetence?
Tell me about it. I also run DMARC on my inbound mail server, and I generate and send daily aggregate reports for any domains that request them in their DMARC records. I use a one-strike-you’re-out rule: if my aggregate report email bounces even once from any domain, I block that domain from any future aggregate reports. So far I’m blocking aggregate reports for 329 domains. Now, many of those are just spam domains which create bogus DMARC records to make their spam look more legitimate, but some of them are surprising.
Here are some of the domains which have bounced aggregate DMARC reports from me:
youtube.com
google.com
e.mikasa.com
lookout.com (security company!)
googlegroups.com
accounts.google.com
flattr.com
trendmicro.com (security company!)
factsmgmt.com
gmail.com
itcodecamp.com
mail.malwarebytes.com (security company!)
samsung.com
yahoo.com
julianforthefuture.com (Julian Castro’s campaign)
service.alibaba.com
mail.vresp.com (a large bulk email provider!)
lastpass.com (security company!)
emailalerts.cnn.com
tufts-health.com