debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-23 11:28:13 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/doc/man7/notmuch-properties.rst

88 lines
2.7 KiB
ReStructuredText
Raw Normal View History

doc: add notmuch-properties(7) We will want a user-facing place to record details about the use of notmuch properties shortly. This establishes a new manual page for that purpose.
2017-10-21 04:25:39 +02:00
==================
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.
reindex: drop all properties named with prefix "index." This allows us to create new properties that will be automatically set during indexing, and cleared during re-indexing, just by choice of property name.
2017-10-21 04:25:40 +02:00
CONVENTIONS
===========
Any property with a key that starts with "index." will be removed (and
possibly re-set) upon reindexing (see **notmuch-reindex(1)**).
crypto: index encrypted parts when indexopts try_decrypt is set. If we see index options that ask us to decrypt when indexing a message, and we encounter an encrypted part, we'll try to descend into it. If we can decrypt, we add the property index.decryption=success. If we can't decrypt (or recognize the encrypted type of mail), we add the property index.decryption=failure. Note that a single message may have both values of the "index.decryption" property: "success" and "failure". For example, consider a message that includes multiple layers of encryption. If we manage to decrypt the outer layer ("index.decryption=success"), but fail on the inner layer ("index.decryption=failure"). Because of the property name, this will be automatically cleared (and possibly re-set) during re-indexing. This means it will subsequently correspond to the actual semantics of the stored index.
2017-10-21 04:25:41 +02:00
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
config: define new option index.try_decrypt By default, notmuch won't try to decrypt on indexing. With this patch, we make it possible to indicate a per-database preference using the config variable "index.try_decrypt", which by default will be false. At indexing time, the database needs some way to know its internal defaults for how to index encrypted parts. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself), so we store it in the database. This behaves similarly to the query.* configurations, which are also stored in the database itself, so we're not introducing any new dependencies by requiring that it be stored in the database.
2017-10-21 04:25:43 +02:00
indexing (which is the default, see ``index.try_decrypt`` in
**notmuch-config(1)**), then this property will not be set on that
message.
crypto: index encrypted parts when indexopts try_decrypt is set. If we see index options that ask us to decrypt when indexing a message, and we encounter an encrypted part, we'll try to descend into it. If we can decrypt, we add the property index.decryption=success. If we can't decrypt (or recognize the encrypted type of mail), we add the property index.decryption=failure. Note that a single message may have both values of the "index.decryption" property: "success" and "failure". For example, consider a message that includes multiple layers of encryption. If we manage to decrypt the outer layer ("index.decryption=success"), but fail on the inner layer ("index.decryption=failure"). Because of the property name, this will be automatically cleared (and possibly re-set) during re-indexing. This means it will subsequently correspond to the actual semantics of the stored index.
2017-10-21 04:25:41 +02:00
doc: add notmuch-properties(7) We will want a user-facing place to record details about the use of notmuch properties shortly. This establishes a new manual page for that purpose.
2017-10-21 04:25:39 +02:00
SEE ALSO
========
**notmuch(1)**,
config: define new option index.try_decrypt By default, notmuch won't try to decrypt on indexing. With this patch, we make it possible to indicate a per-database preference using the config variable "index.try_decrypt", which by default will be false. At indexing time, the database needs some way to know its internal defaults for how to index encrypted parts. It shouldn't be contingent on an external config file (since that can't be retrieved from the database object itself), so we store it in the database. This behaves similarly to the query.* configurations, which are also stored in the database itself, so we're not introducing any new dependencies by requiring that it be stored in the database.
2017-10-21 04:25:43 +02:00
**notmuch-config(1)**,
doc: add notmuch-properties(7) We will want a user-facing place to record details about the use of notmuch properties shortly. This establishes a new manual page for that purpose.
2017-10-21 04:25:39 +02:00
**notmuch-dump(1)**,
**notmuch-insert(1)**,
**notmuch-new(1)**,
**notmuch-reindex(1)**,
**notmuch-restore(1)**,
***notmuch-search-terms(7)**
Reference in a new issue Copy permalink