1 .. _notmuch-properties(7):
10 **notmuch** **count** **property:**\ <*key*>=<*value*>
12 **notmuch** **search** **property:**\ <*key*>=<*value*>
14 **notmuch** **show** **property:**\ <*key*>=<*value*>
16 **notmuch** **reindex** **property:**\ <*key*>=<*value*>
18 **notmuch** **tag** +<*tag*> **property:**\ <*key*>=<*value*>
21 **notmuch** **dump** **--include=properties**
23 **notmuch** **restore** **--include=properties**
28 Several notmuch commands can search for, modify, add or remove
29 properties associated with specific messages. Properties are
30 key/value pairs, and a message can have more than one key/value pair
33 While users can select based on a specific property in their search
34 terms with the prefix **property:**, the notmuch command-line
35 interface does not provide mechanisms for modifying properties
38 Instead, message properties are expected to be set and used
39 programmatically, according to logic in notmuch itself, or in
42 Extensions to notmuch which make use of properties are encouraged to
43 report the specific properties used to the upstream notmuch project,
44 as a way of avoiding collisions in the property namespace.
49 Any property with a key that starts with "index." will be removed (and
50 possibly re-set) upon reindexing (see :any:`notmuch-reindex(1)`).
55 The following properties are set by notmuch internally in the course
56 of its normal activity.
59 If a message contains encrypted content, and notmuch tries to
60 decrypt that content during indexing, it will add the property
61 ``index.decryption=success`` when the cleartext was successfully
62 indexed. If notmuch attempts to decrypt any part of a message
63 during indexing and that decryption attempt fails, it will add the
64 property ``index.decryption=failure`` to the message.
66 Note that it's possible for a single message to have both
67 ``index.decryption=success`` and ``index.decryption=failure``.
68 Consider an encrypted e-mail message that contains another
69 encrypted e-mail message as an attachment -- if the outer message
70 can be decrypted, but the attached part cannot, then both
71 properties will be set on the message as a whole.
73 If notmuch never tried to decrypt an encrypted message during
74 indexing (which is the default, see ``index.decrypt`` in
75 :any:`notmuch-config(1)`), then this property will not be set on that
80 When :any:`notmuch-show(1)` or :any:`notmuch-reply(1)` encounters
81 a message with an encrypted part, if notmuch finds a
82 ``session-key`` property associated with the message, it will try
83 that stashed session key for decryption.
85 If you do not want to use any stashed session keys that might be
86 present, you should pass those programs ``--decrypt=false``.
88 Using a stashed session key with "notmuch show" will speed up
89 rendering of long encrypted threads. It also allows the user to
90 destroy the secret part of any expired encryption-capable subkey
91 while still being able to read any retained messages for which
92 they have stashed the session key. This enables truly deletable
93 e-mail, since (once the session key and asymmetric subkey are both
94 destroyed) there are no keys left that can be used to decrypt any
95 copy of the original message previously stored by an adversary.
97 However, access to the stashed session key for an encrypted message
98 permits full byte-for-byte reconstruction of the cleartext
99 message. This includes attachments, cryptographic signatures, and
100 other material that cannot be reconstructed from the index alone.
102 See ``index.decrypt`` in :any:`notmuch-config(1)` for more
103 details about how to set notmuch's policy on when to store session
106 The session key should be in the ASCII text form produced by
107 GnuPG. For OpenPGP, that consists of a decimal representation of
108 the hash algorithm used (identified by number from RFC 4880,
109 e.g. 9 means AES-256) followed by a colon, followed by a
110 hexadecimal representation of the algorithm-specific key. For
111 example, an AES-128 key might be stashed in a notmuch property as:
112 ``session-key=7:14B16AF65536C28AF209828DFE34C9E0``.
116 Some messages arrive in forms that are confusing to view; they can
117 be mangled by mail transport agents, or the sending mail user
118 agent may structure them in a way that is confusing. If notmuch
119 knows how to both detect and repair such a problematic message, it
120 will do so during indexing.
122 If it applies a message repair during indexing, it will use the
123 ``index.repaired`` property to note the type of repair(s) it
126 ``index.repaired=skip-protected-headers-legacy-display`` indicates
127 that when indexing the cleartext of an encrypted message, notmuch
128 skipped over a "legacy-display" text/rfc822-headers part that it
129 found in that message, since it was able to index the built-in
130 protected headers directly.
132 ``index.repaired=mixedup`` indicates the repair of a "Mixed Up"
133 encrypted PGP/MIME message, a mangling typically produced by
134 Microsoft's Exchange MTA. See
135 https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling
136 for more information.
142 :any:`notmuch-config(1)`,
143 :any:`notmuch-dump(1)`,
144 :any:`notmuch-insert(1)`,
145 :any:`notmuch-new(1)`,
146 :any:`notmuch-reindex(1)`,
147 :any:`notmuch-reply(1)`,
148 :any:`notmuch-restore(1)`,
149 :any:`notmuch-search-terms(7)`,
150 :any:`notmuch-show(1)`