notmuch-properties  - notmuch message property conventions and documen‐


       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


       Several notmuch commands can search for, modify, add or remove  proper‐
       ties  associated  with  specific  messages.   Properties  are key/value
       pairs, and a message can have more than one key/value pair for the same

       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

       Instead, message properties are expected to be set and used programmat‐
       ically, 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.


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


       The following properties are set by notmuch internally in the course of
       its normal activity.

              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 in‐
              dexed.  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  in-
              dex.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  not‐
              much-config(1)), then this property will not be set on that mes‐

              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  de‐
              crypt  any  copy of the original message previously stored by an

              However, access to the stashed session key for an encrypted mes‐
              sage  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

              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  hexa‐
              decimal representation of the algorithm-specific key.  For exam‐
              ple, an AES-128 key might be stashed in a notmuch  property  as:

              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  per‐

              index.repaired=skip-protected-headers-legacy-display   indicates
              that when indexing the cleartext of an encrypted  message,  not‐
              much  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" en‐
              crypted PGP/MIME message, a mangling typically produced  by  Mi‐
              for more information.


       notmuch(1), notmuch-config(1), notmuch-dump(1), notmuch-insert(1), not‐
       much-new(1), notmuch-reindex(1), notmuch-reply(1),  notmuch-restore(1),
       notmuch-search-terms(7), notmuch-show(1)


       Carl Worth and many others


       2009-2022, Carl Worth and many others