>For the internet scale domains, the local part rules are well known and >can be implemented by clients doing a lookup. They could even decide to >do based on the identity of the MX server (eg google domains). A few >people strongly objected to even hinting at common rewrite rules, so >that information was removed from the draft (not so much by consensus >but for conflict avoidance). Re-adding this advise would resolve this. Well, OK. Then put it in the draft, create a rewrite rule registry, and see if we get consensus. >Another suggested method has been the addition of a domain-wide special >TXT record that describes the domain rewriting rules. Ditto, write it up. >However, the WG >was ready to start an experimental deployment and use the results of >those experiments to write a bis document, possible promoting such a >bis document from Experimental to Standards Track. If you're saying that this draft is experimental, please adjust its status to say so, since it's currently proposed standard. On the other hand, if it really is standards track, you need to flesh out the magic that you're assuming people will use. If everyone invents their own magic, that's hardly interoperating. >> Hashed names require that all of the keys for a domain be served in one flat >> zone. > >As far as I'm aware, some of these 10^8 or 10^9 actually don't use flat >zone files but use online DNSSEC signing with database backends. These systems have 10^8 e-mail addresses, not 10^8 DNS records. The .COM zone has about 2.8x10^8 records, but the unsigned records average only 35 characters. I am under the impression that they do static signing. 10^8 records at 3K apiece really is a lot bigger. >> Large mail systems typically partition the users based on the local >> part, but since the hashes aren't reversible, there's no way to tell what >> partition would handle what hashed name. ... >I'm not sure how local part partitions for mailboxes are affected at >all. The name space is partitioned. As an oversimplified example, one might divide the mail system into 26 partitions, one for addresses that start with "A", through the 26th for addresses that start with "Z". So in a setup like that, when you get this hash: 401f1721a42a814961323c460dd7d2036231ddf590b5d898c9cd086a which partition handles it? R's, John