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