On Wed, Apr 01, 2015 at 01:17:15AM -0000, John Levine wrote: > >An alternative is to go back to the original base32 encoding, which > >is lossless, and thus can allow the remote DNS server (a special-purpose > >DNS lookup engine serving a zone with per-user information) to > >decode the local-part and perform whatever fuzzy matching may be > >appropriate. > > > >The lossless encoding can support longer names by breaking them up > >into multiple labels. > > > >This allows static DNS to be published where desired, and custom > >code to produce dynamic results when appropriate. > > I wrote up a draft summarizing the ways one might do mailbox > name lookups in the DNS with something close to the local-part > rules that MTAs have: > > http://datatracker.ietf.org/doc/draft-levine-dns-mailbox/
The All Names Valid approach has a problem: we're looking for S/MIME or OPENPGP public keys, so that's what needs to be found. For any public key algorithms where not every possible bit string is a possible public key, and where clients can figure that out, the server would have to generate distinct plausible public keys, otherwise clients could still enumerate the set of plausible mailboxes. I would still prefer to require MUAs to implement the DNS (base32-encoded) LHS lookup and the pointer-to-HTTPS-server lookup. Whether mail domains choose to implement static or dynamic DNS lookups, or the pointer-to-HTTPS-server, should be up to them. That said, I really don't mind living with users having to type in peers' e-mail addresses correctly. Forcing users to either have easy-to-enter email addresses on their business cards (and/or QR codes) or publish all reasonable variants of their e-mail addresses, seems perfectly reasonable -if annoying, for the +list use case- to me. The choice should be the mail domain admins'. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
