If you've never received mail from somebody before you cannot rely on any aspect of lhs@rhs to inform their key. So the game is lost if anyone thinks proscriptive logic around lhs@ is going to be abided by.
The discussion in the room was about interpretation of lhs@ I think the sensible path out is to get people to send mail, and include PGP key in the envelope. Any recipient you see this for, you have their PGP ID as a proffer and its associated with their email identity. Which builds your set of recipients which have known PGP ID very quickly once you confirm it out of band. Likewise for lists. Your sender is exposed to the list mailer. Your PGP ID is scraped from Envelope. And, since Envelope is from MTA not MUA, it has some traction for being set by local admin so the local admin LDAP can populate the outbound PGP ID into the MAIL FROM No .sigs required. On Thu, Mar 26, 2015 at 3:54 PM, Nico Williams <[email protected]> wrote: > On Thu, Mar 26, 2015 at 3:50 PM, George Michaelson <[email protected]> > wrote: > > 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 > > What problem is this solving? >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
