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. 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. I just don't understand the use case for thinking the key retrieval function needs to support all such vendor specific transformations that I don't use. 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. dougm On Thu, Mar 26, 2015 at 3:02 PM, John R Levine <[email protected]> wrote: > I guess I am confused as to why I would want to support either key >> discovery or distribution for the (500million - 1) versions of my email >> address that I don't use. >> > > You may know exactly want versions of your address that you use, but in > general, mail systems don't. Google doesn't know whether you spell your > address dougmwork or dougm.work or DougmWork or Dougm.work. They might be > able to guess based on the incoming mail they've seen, but as we've said > over and over, guessing isn't on the table. > > If you're suggested that every mail user will manually identify which > versions of his or her mail address the mail provider should publish, that > doesn't seem to scale very well. > > > Regards, > John Levine, [email protected], Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. > -- DougM at Work
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
