The concept is very interesting - apparently, each "doll" or layer is encrypted, and only the target can decode the message - so I guess the equivalent of the MX would be the outmost doll, while the equivalent of a To: field would be the innermost doll.<p>This reminds me of something else I've found quite interesting - the idea of publishing pubkeys or at least their hashes as DNS records (yes, unsafe unless there is DNSSEC etc, but that would be much better than now), so that the sender could encrypt the message automatically, without requiring the user to select say GPG target keys.<p>I wonder if that's what they will be using. Do they have technical documents or RFCs?<p>A new and non backward compatible email system using that (say even running on a different port) would indeed be quite interesting, but I wonder if there wouldn't be weaknesses that would make spam a problem as serious as in 2004/2005 (or maybe SPF is yet another of their "dolls"?)<p>Edit: about anonymous remailer and tor, it doesn't look the same to me. Say I publish 2 keys, one for my domain, one for my user. Everything one wishes to send to my domain is encrypted first with my key, then with my domain key, and then signed with the sender domain key (to add equivalent of SPF). Once it arrives, the equivalent of an MTA can try and decrypt that - if it suceeds, it can then put it in a spool of mail "not fetched yet" (so to as add a layer of protection against a malveolent sysadmin - the user could download all the encrypted mails in the spool and try to decrypt them itself)<p>The only thing that would be seen (besides the DNS lookups, but they could be cached by the client with a TTL) would be that domain A is sending a message to domain B.