Pointer to article:
Talk about identity aggregation! Every mail server’s directory is a juicy identity-aggregation point there for the harvesting. And the spammers are plucking this low-hanging fruit through brute-force attacks everywhere, all the time. Invalid address lookups—and the concomitant mail-server CPU hits, mail-queue clogs, and mail-delivery delays--are the overhead we have to endure from the spammer’s relentless penetration testing. But, of course, mail server directories aren’t centralized identity aggregators—the inherently decentralized, federated nature of the worldwide SMTP e-mail utility has scattered these sweet little identity honeypots all over creation.
Yes, I said “federated.” Internet e-mail has been a federated messaging environment for quite some time: that’s been key to its success. I define “federated messaging” as “messaging domains that establish trust relationships under which they can choose to accept each other’s messaging assertions and honor each other’s messaging decisions--or reject them--subject to local policies.” Notice the parallel with my discussion of “federated identity” in the previous blog posting. Federated messaging depends on a constrained variety of federated identity—in this case, each mail domain being able to register, vouch for, and manage its own mail identities (e.g., firstname.lastname@example.org).
Messaging federation, it seems, hasn’t deterred identity thieves in their efforts to grab identities scattered all over kingdom come. Instead, it’s made them more ingenious, creating a widespread directory-harvest-attack infrastructure. Lots of machines throughout the cybershmear are trained to raid the many mail-directory honeypots for unprotected spammunition.
Can a federated IdM infrastructure withstand the inevitable directory harvest attacks? What form will they take? How can we nip them in the bud?