This is notmuch-properties.info, produced by makeinfo version 7.2 from
notmuch-properties.texi.

     notmuch 0.39, Apr 17, 2025

     Carl Worth and many others

     Copyright © 2009-2025, Carl Worth and many others

INFO-DIR-SECTION Miscellaneous
START-INFO-DIR-ENTRY
* notmuch-properties: (notmuch-properties.info). notmuch message property conventions and documentation
END-INFO-DIR-ENTRY


   Generated by Sphinx 8.2.3.


File: notmuch-properties.info,  Node: Top,  Next: SYNOPSIS,  Up: (dir)

notmuch-properties documentation
********************************

     notmuch 0.39, Apr 17, 2025

     Carl Worth and many others

     Copyright © 2009-2025, Carl Worth and many others

* Menu:

* SYNOPSIS::
* DESCRIPTION::
* CONVENTIONS::
* MESSAGE PROPERTIES::
* SEE ALSO::


File: notmuch-properties.info,  Node: SYNOPSIS,  Next: DESCRIPTION,  Prev: Top,  Up: Top

1 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'


File: notmuch-properties.info,  Node: DESCRIPTION,  Next: CONVENTIONS,  Prev: SYNOPSIS,  Up: Top

2 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.


File: notmuch-properties.info,  Node: CONVENTIONS,  Next: MESSAGE PROPERTIES,  Prev: DESCRIPTION,  Up: Top

3 CONVENTIONS
*************

Any property with a key that starts with “index.” will be removed (and
possibly re-set) upon reindexing (see ‘notmuch-reindex(1)’).


File: notmuch-properties.info,  Node: MESSAGE PROPERTIES,  Next: SEE ALSO,  Prev: CONVENTIONS,  Up: Top

4 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 ‘notmuch-reply(1)’ 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 messages arrive in forms that are confusing to view; they can
     be mangled by mail transport agents, or the sending mail user agent
     may structure them in a way that is confusing.  If notmuch knows
     how to both detect and repair such a problematic message, it will
     do so during indexing.

     If it applies a message repair during indexing, it will use the
     ‘index.repaired’ property to note the type of repair(s) it
     performed.

     ‘index.repaired=skip-protected-headers-legacy-display’ indicates
     that when indexing the cleartext of an encrypted message, notmuch
     skipped over a “legacy-display” text/rfc822-headers part that it
     found in that message, since it was able to index the built-in
     protected headers directly.

     ‘index.repaired=mixedup’ indicates the repair of a “Mixed Up”
     encrypted PGP/MIME message, a mangling typically produced by
     Microsoft’s Exchange MTA. See
     ‘https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling’
     for more information.


File: notmuch-properties.info,  Node: SEE ALSO,  Prev: MESSAGE PROPERTIES,  Up: Top

5 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-search-terms(7)’,
‘notmuch-show(1)’


Tag Table:
Node: Top428
Ref: man7/notmuch-properties doc692
Ref: 0692
Node: SYNOPSIS783
Ref: man7/notmuch-properties notmuch-properties875
Ref: 1875
Ref: man7/notmuch-properties notmuch-properties-7875
Ref: 2875
Ref: man7/notmuch-properties synopsis875
Ref: 3875
Node: DESCRIPTION1234
Ref: man7/notmuch-properties description1334
Ref: 41334
Node: CONVENTIONS2129
Ref: man7/notmuch-properties conventions2239
Ref: 52239
Node: MESSAGE PROPERTIES2409
Ref: man7/notmuch-properties message-properties2516
Ref: 62516
Node: SEE ALSO6638
Ref: man7/notmuch-properties see-also6725
Ref: 76725

End Tag Table


Local Variables:
coding: utf-8
End:
