On Thu, 10 Sep 2015, John Levine wrote:
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.
I think the WG was fine with sticking to the currently defined
experimental now, and now delay another year before starting the
experiment. Such rewrite rules could be added later by those who
actually care and run this and write software, so they can come back
to us with a proposal.
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.
One would think a factor of 100x is something these super large
providers could deal with. That's less than say adding India or China
to their userbase. It's also unavoidable too. public keys are blobs of
a certain size that don't compress. It's fundamental to this document.
This document is not Mandatory To Implement. If a certain big provider
cannot implement this in their DNS, they should not deploy this
document. If your point is that this document should never be published
because some large providers might not be able to deploy it, please state
so clearly.
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?
The hash does not make it to the mail server. It is only used in DNS
to find the public key. The recipient name is NOT changed.
The SMTP server just sees the envelope address which is not hashed as
there are no modifications made to the SMTP protocol.
Paul