Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help

       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 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  decryp-

	  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  ren-
	  dering  of  long  encrypted threads.	It also	allows the user	to de-
	  stroy	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 mate-
	  rial 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  representa-
	  tion	of  the	 algorithm-specific  key.  For example,	an AES-128 key
	  might	  be   stashed	 in    a    notmuch    property	   as:	  ses-

	  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 in-
	  dex.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"  en-
	  crypted  PGP/MIME  message,  a mangling typically produced by	Micro-
	  soft's	       Exchange		      MTA.		   See
	  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-show(1),	*notmuch-search-terms(7)

       Carl Worth and many others

       2009-2021, Carl Worth and many others

0.32.2				 Sep 21, 2021		 NOTMUCH-PROPERTIES(7)


Want to link to this manual page? Use this URL:

home | help