On Thu, Mar 26, 2015 at 2:20 PM, Doug Montgomery <[email protected]> wrote: > That problem seems to be O(1). As you noted, I did it once, when I created > the address. My mail provider may choose to support all kinds of inbound > variants (UID@domain) that I don't even know about. > > I transmit, document, and exchange exactly 1 version of my address. I > would like to publish a key for [email protected]. This seems to scale > quite well.
You do. Others use aliases for all sorts of reasons. E.g., joe+dane (some joe's address for posting to this list, say). > I consider it undesirable to publish keys for whatever variants my provider > chooses to support for their own reasons. Tomorrow they might decide (for > their own reasons) to equate other transformations of the string. If you were the sort who likes to use a different sender address (typically an alias of your primary address) for each list, then you would consider it desirable. > Google never has to figure out the problem you propose. I set my from: > address. I would like to publish a key for that. Users trying to validate > my signed email will look up the from address I used. If their user agent > sees [email protected] and chooses to lookup [email protected] > .... well, I am more than happy to have that validation fail. Google does too have to figure out how to canonicalize your aliases: because they chose to apply a fuzzy matching rule of their own design. Google did that because they could. Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
