+ Default: empty list.
+
+**search.exclude\_tags**
+ A list of tags that will be excluded from search results by
+ default. Using an excluded tag in a query will override that
+ exclusion.
+
+ Default: empty list. Note that :any:`notmuch-setup(1)` puts
+ ``deleted;spam`` here when creating new configuration file.
+
+**maildir.synchronize\_flags**
+ If true, then the following maildir flags (in message filenames)
+ will be synchronized with the corresponding notmuch tags:
+
+ +--------+-----------------------------------------------+
+ | Flag | Tag |
+ +========+===============================================+
+ | D | draft |
+ +--------+-----------------------------------------------+
+ | F | flagged |
+ +--------+-----------------------------------------------+
+ | P | passed |
+ +--------+-----------------------------------------------+
+ | R | replied |
+ +--------+-----------------------------------------------+
+ | S | unread (added when 'S' flag is not present) |
+ +--------+-----------------------------------------------+
+
+ The :any:`notmuch-new(1)` command will notice flag changes in
+ filenames and update tags, while the :any:`notmuch-tag(1)` and
+ :any:`notmuch-restore(1)` commands will notice tag changes and
+ update flags in filenames.
+
+ If there have been any changes in the maildir (new messages added,
+ old ones removed or renamed, maildir flags changed, etc.), it is
+ advisable to run :any:`notmuch-new(1)` before
+ :any:`notmuch-tag(1)` or :any:`notmuch-restore(1)` commands to
+ ensure the tag changes are properly synchronized to the maildir
+ flags, as the commands expect the database and maildir to be in
+ sync.
+
+ Default: ``true``.
+
+**index.decrypt**
+ Policy for decrypting encrypted messages during indexing. Must be
+ one of: ``false``, ``auto``, ``nostash``, or ``true``.
+
+ When indexing an encrypted e-mail message, if this variable is set
+ to ``true``, notmuch will try to decrypt the message and index the
+ cleartext, stashing a copy of any discovered session keys for the
+ message. If ``auto``, it will try to index the cleartext if a
+ stashed session key is already known for the message (e.g. from a
+ previous copy), but will not try to access your secret keys. Use
+ ``false`` to avoid decrypting even when a stashed session key is
+ already present.
+
+ ``nostash`` is the same as ``true`` except that it will not stash
+ newly-discovered session keys in the database.