> My idea of an ideal end-state for hop-by-hop security for e-mail is > that: > > a) *senders* should be able to specify in the envelope that they want > secure, encrypted, authenticated delivery of email at every hop, > > b) senders should get bounces when that cannot happen, > > c) *recipients* get an indication of the security of any given e-mail's > path to the recipient (perhaps we need a Transmitted: header by which > each sending hop MTA can record what it did to authenticate the next > hop), > > d) (a) and (c) get prominent UI indications in MUAs,
See, this is why we often say that IETF folks should not generally try to design UI things: There are plenty of studies that show that users -- apart from those of us on this discussion thread and our ilk -- don't understand these sorts of UI indications. General users grossly misunderstand the "lock" symbol that browsers use to tell us that HTTPS is in effect. I'm sure that any attempt to create some version of "this message was/wasn't sent in a way that the message content can't have been looked at in transit (well, except for someone looking at it while it was stored waiting to be relayed)" that's understandable to a typical user will be wildly unsuccessful. Barry _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
