This repository has been archived by the owner on Jun 11, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathinbome_sending_defaults.html
119 lines (116 loc) · 4.16 KB
/
inbome_sending_defaults.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
<!-- see with:
http://htmlpreview.github.io/?https://github.com/mailencrypt/ame2016/blob/master/inbome_sending_defaults.html -->
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<h1>Use-Cases for Sending Emails in Convenience Mode</h1>
<h3>Terminology: </h3>
<ul>
<li>Encryption of the content:
<ul>
<li>"open": Content is not encrypted</li>
<li>"encrypted"</li>
</ul>
</li>
<li>Transport of the encryption preference/information (INBOME headers)
<ul>
<li>"enc-requested": INBOME infos are sent signaling that encryption
is preferred</li>
<li> "enc-agnostic": INBOME infos are not sent or are not signaling
that encryption is preferred</li>
</ul>
</li>
</ul>
<h3>General rules:</h3>
<ul>
<li>Default is always open if keys are missing</li>
<li>When sending to multiple recipients, the defaulkt is always the weakest
of the individual defaults</li>
</ul>
<h3>Individual rules:</h3>
<table width="100%" border="1">
<tr>
<td bgcolor="#CCCCCC"><b><font color="#333333">Trigger</font></b></td>
<td bgcolor="#CCCCCC"><b><font color="#333333">Last Email</font></b></td>
<td bgcolor="#CCCCCC"><b><font color="#333333">Default</font></b></td>
</tr>
<tr>
<td>send new email (start new thread)</td>
<td>none</td>
<td>??? (there should probably be a default depending on whether
we have the key)</td>
</tr>
<tr>
<td> </td>
<td>enc-agnostic</td>
<td>open</td>
</tr>
<tr>
<td> </td>
<td>enc-requested</td>
<td>encrypted</td>
</tr>
<tr>
<td>reply to email</td>
<td>open & enc-agnostic</td>
<td>open</td>
</tr>
<tr>
<td> </td>
<td>open & enc-requested</td>
<td>encrypted</td>
</tr>
<tr>
<td> </td>
<td>encrypted & enc-agnostic</td>
<td><b>encrypted !</b></td>
</tr>
<tr>
<td> </td>
<td>encrypted & enc-requested</td>
<td>encrypted</td>
</tr>
</table>
<h3><b>Remarks & Consequences:</b></h3>
<ul>
<li>encrypted & enc-agnostic might happen if
<ul>
<li>emails are encrypted without using INBOME</li>
<li>sender explicitly want to send the key but still prefers not to encrypt</li>
</ul>
</li>
<li>If a sender has different clients, one might send enc-requested, one might
send enc-agnostic (web client, not supporting INBOME yet), then there is no
perfect solution for always doing things right. The current approach is that
the default for a new email would simply depend on the header of the last
email, which might mean that whether encryption is used might change with
each message
<ul>
<li>As then the default might constantly change, users might have a problem,
because people often hate situations that are hard to predict.</li>
<li>At least the default must be visible and easily modifyable.</li>
<li>Another approach might be to check the past emails (plural). E.g. if
one of the past emails was enc-requested, then to encrypt. But then the
question is how long to look back and whether users will hat that the
default is "always" wrong after giving up encryption.</li>
</ul>
</li>
<li>The case "reply to encrypted & enc-agnostic => encrypted"
is there for a couple of reasons
<ul>
<li>There might be a good reason that the last mail was encrypted, so this
shouldn't not change without interaction/confirmation</li>
<li>When there are multiple recipients one enc-agnostic would then result
into "open" (or the rule that we always take the weakest becomes
more complicated)</li>
<li>The case that somebody lost a key, should anyway lead to a effect that
the recipient replaced the key, but not suddenly switched to enc-agnostic.</li>
</ul>
<p> </p>
</li>
</ul>
</body>
</html>