Hey Nico, On Mar 26, 2015, at 3:13 PM, Nico Williams <[email protected]> wrote:
> On Thu, Mar 26, 2015 at 2:57 PM, Doug Montgomery <[email protected]> wrote: >> For any set of aliases that are manually configured, publishing a key, or >> CNAME for each of those is of the same order of complexity as establishing >> the alias itself. >> >> When I try to validate the sig for [email protected] I will look that up. > > <name>+<list> is not configured. They're magic... if your MTAs are > configured so anyways. These uses exist precisely because they were > a) permitted, b) handy. So now we have to deal with them. Indeed, but I think this a powerful feature that lets users advertise their intent. If someone wants to add protections to their list subscriptions, or wants to add different crypto to different email aliases, then configuring the encr/signing behavior independently is a feature, not a bug, me thinks. > I still fail to see what inbound fuzzy match of local parts has to do with >> the problem. > > It's true that we don't have to specify a lookup service to deal with > fuzzy matching. However, the <name>+<list> users will have start > manually publishing those. That seems like a pain. Again, if someone wants to receive encrypted email or have their signatures verified, it seems reasonable to advertise their intentions explicitly. I really think this is a feature, not a bug. > Also, using DNS for this opens mail domains to zone walking to find > mailboxes, whereas a proper lookup service wouldn't (it would still be > an oracle, but there would be no NSEC* to facilitate discovery of all > email addresses at the domain). I mentioned a candidate approach to dealing with this at the mic yesterday. I think this could easily be a domain and MUA configurable option with some of the proposed enhancements we’ve coded into SMIMEA, but I don’t want to distract this thread too much. Maybe we can start a new thread for that (over beer, perhaps). ;) Eric
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
