On Mar 15, 2015, at 5:57 PM, John R Levine <[email protected]> wrote: > >> Fuzzy matching on "mailboxes" bites in several places, far beyond email. >> While way out of scope of everything being discussed here, I think the idea >> of having a cut point handoff from the domain certification, to the 'user' >> certification, is something we can't ignore. > > Right. As I said before, it's a big can of worms. If we think it needs to > be addressed at all, we need to pull it out of the current drafts (such as > section 3 of the openpgp draft) and deal with it directly. > >> Sendmail's plus-addressing scheme is a deployed example of that sort of >> usage. > > There's a huge list of them, case folding, ignoring some dots, ignoring all > dots, various sorts of LDAP things to match john.smith, johnsmith, jsmith, > and j.smith, often data dependent so jsmith only works if it only matches on > e address.
Historically, "the draft pretends the problem doesn't exist" causes ugly late surprises in the IESG, and then (often?) more convoluted RFCs. Having said that, John has a good point that the current wording sounds like it says "here are a few problems, and here is a potential solution". Section 3.1 would be better worded as: 3.1. Email address variants Some email service providers and email software perform automatic mappings of the LHS of email addresses based on special characters. This makes finding OPENPGPKEY record for a particular name that might be mapped impossible because there is no complete set of mappings and, worse, some common mappings conflict with each other. It might be tempting for software that implements DNS lookup for the OPENPGPKEY RRtype to try to perform similar mappings while trying to find a particular OPENPGPKEY record. This SHOULD NOT be done because some mapping attempts might retrieve the key for the wrong user, depending on the mapping rules of the service provider or software platform. --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
