X-Git-Url: https://git.cworth.org/git?a=blobdiff_plain;f=manpages%2Fnotmuch-properties-7.mdwn;h=8cfd7f6ab11f8f1dc310393cd8bd7356517492f4;hb=bbdcbf63583351af9c0954cb92316f5bb3a8509a;hp=b5d47a354a32c6bf652ec73258d531486675f097;hpb=0568dc66970180cbda48af10d27c49fb1a36805e;p=notmuch-wiki diff --git a/manpages/notmuch-properties-7.mdwn b/manpages/notmuch-properties-7.mdwn index b5d47a3..8cfd7f6 100644 --- a/manpages/notmuch-properties-7.mdwn +++ b/manpages/notmuch-properties-7.mdwn @@ -57,13 +57,13 @@ 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 + 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 - index.decryption=success and index.decryption=failure. Consider + 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 @@ -75,67 +75,70 @@ sage. session-key - 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‐ - tion. - - 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 - 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 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- - sion-key=7:14B16AF65536C28AF209828DFE34C9E0. + 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 + adversary. + + 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 + 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 hexa‐ + decimal representation of the algorithm-specific key. For exam‐ + ple, 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 Micro‐ - soft's - https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling - for more information. + 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‐ + formed. + + 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‐ + crosoft's + https://tools.ietf.org/html/draft-dkg-openpgp-pgpmime-message-mangling + for more information.

SEE ALSO

        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)
+       much-new(1), notmuch-reindex(1), notmuch-reply(1),  notmuch-restore(1),
+       notmuch-search-terms(7), notmuch-show(1)

AUTHOR

@@ -145,7 +148,7 @@

COPYRIGHT

-       2009-2020, Carl Worth and many others
+       2009-2022, Carl Worth and many others
-

0.30

+

0.35