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
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
| | ==================
notmuch-properties
==================
SYNOPSIS
========
**notmuch** **count** **property:**\ <*key*>=<*value*>
**notmuch** **search** **property:**\ <*key*>=<*value*>
**notmuch** **show** **property:**\ <*key*>=<*value*>
**notmuch** **reindex** **property:**\ <*key*>=<*value*>
**notmuch** **tag** +<*tag*> **property:**\ <*key*>=<*value*>
**notmuch** **dump** **--include=properties**
**notmuch** **restore** **--include=properties**
DESCRIPTION
===========
Several notmuch commands can search for, modify, add or remove
properties associated with specific messages. Properties are
key/value pairs, and a message can have more than one key/value pair
for the same key.
While users can select based on a specific property in their search
terms with the prefix **property:**, the notmuch command-line
interface does not provide mechanisms for modifying properties
directly to the user.
Instead, message properties are expected to be set and used
programmatically, according to logic in notmuch itself, or in
extensions to it.
Extensions to notmuch which make use of properties are encouraged to
report the specific properties used to the upstream notmuch project,
as a way of avoiding collisions in the property namespace.
CONVENTIONS
===========
Any property with a key that starts with "index." will be removed (and
possibly re-set) upon reindexing (see **notmuch-reindex(1)**).
MESSAGE PROPERTIES
==================
The following properties are set by notmuch internally in the course
of its normal activity.
**index.decryption**
If a message contains encrypted content, and notmuch tries to
decrypt that content during indexing, it will add the property
``index.decryption=success`` when the cleartext was successfully
indexed. If notmuch attempts to decrypt any part of a message
during indexing and that decryption attempt fails, it will add the
property ``index.decryption=failure`` to the message.
Note that it's possible for a single message to have both
``index.decryption=success`` and ``index.decryption=failure``.
Consider an encrypted e-mail message that contains another
encrypted e-mail message as an attachment -- if the outer message
can be decrypted, but the attached part cannot, then both
properties will be set on the message as a whole.
If notmuch never tried to decrypt an encrypted message during
indexing (which is the default, see ``index.decrypt`` in
**notmuch-config(1)**), then this property will not be set on that
message.
**session-key**
When **notmuch-show(1)** or **nomtuch-reply** encounters a message
with an encrypted part, if notmuch finds a ``session-key``
property associated with the message, it will try that stashed
session key for decryption.
If you do not want to use any stashed session keys that might be
present, you should pass those programs ``--decrypt=false``.
Using a stashed session key with "notmuch show" will speed up
rendering of long encrypted threads. It also allows the user to
destroy the secret part of any expired encryption-capable subkey
while still being able to read any retained messages for which
they have stashed the session key. This enables truly deletable
e-mail, since (once the session key and asymmetric subkey are both
destroyed) there are no keys left that can be used to decrypt any
copy of the original message previously stored by an adversary.
However, access to the stashed session key for an encrypted message
permits full byte-for-byte reconstruction of the cleartext
message. This includes attachments, cryptographic signatures, and
other material that cannot be reconstructed from the index alone.
See ``index.decrypt`` in **notmuch-config(1)** for more
details about how to set notmuch's policy on when to store session
keys.
The session key should be in the ASCII text form produced by
GnuPG. For OpenPGP, that consists of a decimal representation of
the hash algorithm used (identified by number from RFC 4880,
e.g. 9 means AES-256) followed by a colon, followed by a
hexadecimal representation of the algorithm-specific key. For
example, an AES-128 key might be stashed in a notmuch property as:
``session-key=7:14B16AF65536C28AF209828DFE34C9E0``.
**index.repaired**
Some mail transport agents mangle messages in transit in ways that
are both detectable and reversible. If notmuch encounters such a
mangling during indexing, it will try to index the repaired form
of the message (while still leaving the message on disk
untouched). If successful, it will use the ``index.repaired``
property to note the kind of mangling that was repaired.
Currently, only one form of repairable mangling is detected and
repaired, which is denoted with ``index.repaired=mixedup``. See
https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling
for more information.
SEE ALSO
========
**notmuch(1)**,
**notmuch-config(1)**,
**notmuch-dump(1)**,
**notmuch-insert(1)**,
**notmuch-new(1)**,
**notmuch-reindex(1)**,
**notmuch-reply(1)**,
**notmuch-restore(1)**,
**notmuch-show(1)**,
***notmuch-search-terms(7)**
|