<div dir="ltr"><div> >I'd be more worried about usability and what problem it's actually solving. Forget about encryption and think people. Magic, wondrous email enables anybody - worldwide - to email you! Let's divide all the people on planet earth into three sets: {1} people you know; {2} people you don't know but who know [something about] you which makes them think that you would be interested in getting to know them/talk to them about something of mutual interest; {3} people who don't know you -> some of these write botnets that spam you because of an x% chance to make some money. For most of us, the cardinality of sets {1} and {2} is small enough that we _want_ to _see_ all email messages sent by people in {1} and {2}. We might not want to _reply_ to messages in {2}, but we want to read them to decide. (For the Paul Grahams of this world where this is not true, there is no solution but to pay for extra eyeballs to help process their email stream.) Unfortunately, for all of us, most emails received are from {3}. This is the least important stuff (or if it is a notification from a shop you just bought from the first time, you will know to go and look for it the minute after you purchased or when you need it). A good email client must be able to divide received emails into {1}, {2} and {3} because emails from {3} dominate and would otherwise visually obscure the good stuff. Also note that anything in {2} cannot be auto-replied-to by the email client, you have to read and evaluate the pitch yourself. I don't think this is easy to do: {1} is nearly trivial, but distinguishing between {2} and {3} is very hard (if you think that is what current ESP spam filters do, simply pretend you are solving for the "first email contact with new email address should already be e2e encrypted" case where you cannot rely on ESP help). Unfortunately is is essential from a "delight the user" point of view to distinguish between {2} and {3} because emails from {3} fully dominate emails from {2}, and it is very undelightful to have to filter them out oneself. ==> Usecase (the problem it is trying to solve): 1. The [politely] protocol is meant to trivially help your email client distinguish between {2} and {3} (ideally even without the help of your ESP's spam filter if for example you run </div><div>it over an encrypted channel). 2. Since only you can be the final judge of whether a "pitch for attention" is valid or not, the protocol is further designed (text-only one-paragraph) to help you process these pitches as quickly as possible (in case you are a half-graham and get loads of them, or in case some people in {3} abuse it): -> a twitter-like stream of short one-paragraph pitches does not take long to skimread/scroll through (and it is ok to not reply, people in {2} know they might have to and are allowed to retry again later). 3. The protocol must successfully discourage abuse by 99.999007% of people in {3} or we are back to commingled {2} and {3}. (Getting there without ESP help might be tricky.) So the protocol is orthogonal to encryption. It's just that if you only want to accept encrypted email from {1} then you need a "safe and delightful enough" way to process emails from {2} and decide which ones are allowed into {1} Encryption: ------------------------------------------------------------ For now just two observations: 1. Usefulness/Sacrifice of a cleartext opening message: a. If it is a politely handshake ({2}), it is only a pitch for attention written to convince you that the person is indeed in {2}, ie mainly that he knows (sth about) you. The real-life equivalent: at a conference, with lots of people around overhearing you, you approach the speaker and ask him if you could talk about your secret idea directly relevant to his field of expertise somewhere quiet. b. If it is another email in {3} which you choose to reply to (and for some reason the sender is e2e enabled but did not use the politely protocol): better now than never. c. All your current conversations with your friends {1} are probably in the clear at your ESP. This is worse than just a first message, yet I guess you would still switch to e2e encrypted with them asap? 2. Metadata in the clear: Here's my pessimistic threat model: - a big brother active(*) global adversary, - interested in eavesdropping and metadata (who with whom when), - everything that goes over the wire is monitored in realtime, - and persisted somewhere (for eventual later use). (*) "active" only as needed to hide MITM attacks, not to impersonate or semantically modify content, the aim is "undetected passive listening in" and "network analysis". In this model I just assume the adversary knows/can infer the metadata, whether I encrypt it or not (TOR is assumed crackable in my model). In case it isn't obvious, IANAC (I am not a cryptographer), so simplifying to pessimist. I also assume that a real solution which enables secure _anonymous_ communication [over email] with this kind of adversary is not going to be deployed (to millions of users) anytime soon. So for now: big brother does have the metadata (who with whom when).</div></div>