Mail systems are exposed to the entire header. The Envelope isn't neccessarily the same as the header (this we know)
So absent a wilingness to add a magic third field to the Mail From: field which would be [....hash of PGP] How about we have X- behiour explored in the mail header, which is all safe for now and MUA exposed? When we know how that works, we can move on what we really need, which is envelope level: MAIL FROM: "George is Nuts" <[email protected]> PGP-KEY-HASH-HERE -G On Thu, Mar 26, 2015 at 3:37 PM, Osterweil, Eric <[email protected]> wrote: > 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 > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane > >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
