On Wed, 25 Feb 2015, Brian Dickson wrote:
To use the gmail example, I just did a test.
I was previously unaware of the "s/\.//g" behavior. But, it is real.
So, I sent mail to a never-before-used variant of my name, "br.i.an" instead of
"brian".
Lo and behold, it was delivered to my mailbox.
If the goal was to preserve this behavior, while having MUAs look up keys,
without a policy mechanism, it would be necessary to publish
2^(N-1) records for every name of length N.
If the average length of a name were 11 characters, then 2^10 = 1024 records
would be needed per user.
This takes O(10e9) and turns it into O(10e12), of thing which have to be
hashed, signed, and then NSEC/NSEC3-ified.
So, the publishing side takes a disproportionate hit.
Have the client understand a very limited set of case-folding rules, which
could be used universally, is clearly preferable, even to the
client, IMHO.
Agreed. I think the document(s) should stay away from interpreting the
LHS. But it would be worth adding a subsection into the Location
section. How about:
3.1 Email address variants
Most SMTP servers treat the user part of the email address as case
insensitive. This means that "[email protected]" could be different email
address from "[email protected]" but both email addresses would end up at
the same enduser. The OPENPGPKEY lookup for both addresses would result
in a different SHA-224 value. As some input methods to email clients
auto-correct to using an uppercase for a first name, an email client
supporting this document might want to interact with the user and try
a lower-cased username for an OPENPGPKEY lookup. Other mail servers
allow other kind of email translation rules, such as automatically
matching "[email protected]" to "[email protected]",
or allowing "." characters to be placed anywhere in the address so
"[email protected]" matches "[email protected]". While
publishers
can add duplicate or CNAME entries for the OPENPGPKEY records to match
these variants, email clients might want to try some (obvious)
variations.
I think this would also apply to the SMIMEA document.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
