On Thu, Mar 26, 2015 at 3:37 PM, Osterweil, Eric <[email protected]> wrote: > On Mar 26, 2015, at 3:13 PM, Nico Williams <[email protected]> wrote: >> <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.
People who do this mostly want to filter into folders based on recipient address. They are able to magically create new sender addresses without doing anything special. >> 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. A lookup protocol does this, either by applying local rules such as s/[+].*$// or whatever they like. >> 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). ;) I don't remember it. Can you remind us? Debating the +list thing is more distracting, I think :) Nico -- _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
