I'm vastly amused by this.
When businesses want to communicate with their customers via e-mail, many send messages with a bogus return address, e.g. "somethinghere@donotreply.com." The practice is meant to communicate to recipients that any replies will go unread.
But when those messages are sent to an inactive e-mail address or the recipient ignores the instruction and replies anyway, the missives don't just disappear into the digital ether.
Instead, they land in Chet Faliszek's e-mail box.
There's a lesson here for protocol architects.
Some people will rely on the system your protocol enables without really understanding how it all works. Their ignorance can make it surprisingly easy for them to do things by mistake that have very serious security consequences for themselves and, potentially, for everyone.
Other people, who understand how the system works, and the protocols that enable it, will discovery these interesting vulnerabilities. They will then exploit them with varying degrees of malice aforethought.
Now, imagine for a moment that Chet Faliszek were one of
these people, i.e. someone who does business with phishers and spam gangs, or who
is a spammer or a phisher, instead of someone who seems to have taken an interest in trying to educate people who are otherwise dangerously ignorant. In a way, that would make it easier to rip the domain away from him by force and hand it over to some kind of regulated public entity. But, Chet Faliszek isn't doing anything wrong— yet— and, as a result, there is a continuing risk to the system posed by the dumbass convention of using donotreply.com as if it were a reserved domain name.
I don't know how to design protocols that don't have this kind of weakness in them. It seems like a real problem. Maybe, an intractable one. I wish there were a good system for minimizing the system risks inherent in a protocol architecture prior to its widespread adoption. I don't think there is one.
I think it's just a matter of making sure your architects aren't treated like dog-crap.