mirror of
https://git.notmuchmail.org/git/notmuch
synced 2024-12-22 09:24:54 +01:00
notmuch clon
fd9a951249
These tests were an attempt to establish that the content of the "Legacy Display" part is the same as the actual protected headers of the message. But this is more conservative than we need to be. https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html section 5.3 makes clear that the Legacy Display part is purely decorative, and section 5.2.1 clarifies that the detection can be done purely by MIME structure and Content-Type alone. Furthermore, now that we're accepting text/plain Legacy Display parts, it's not clear the lines in the Legacy Display part should be interpreted as needing an exact string match (e.g. "real" headers are likely to be RFC 2047 encoded, but the text/plain Legacy Display part probably should not be). The concerns that motivated this test in the past were twofold: that we might accidentally hide some information from the reader of the message that they should have available to them, or that we could introduce a covert channel that would be invisible to other clients. I no longer think these are significant concerns: a) There will be no accidental misidentification of a Legacy Display part. The identification of the Legacy Display part is unambiguous due to MIME structure and Content-Type. MIME structure MUST be the first child part of a two-part multipart/mixed Cryptographic Payload. And the protected-headers=v1 content-type parameter must be present on both the cryptographic payload and the legacy display part, so no one would accidentally generate this structure and have it be accidentally matched. b) As for creating a covert channel, many such channels already exist. For example, non-standard e-mail headers, custom MIME types, unusual MIME structures, etc, all make it possible to ship some content in a message that will be visible in some MUAs but not in others. This doesn't make the situation demonstrably worse. Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net> |
||
---|---|---|
bindings | ||
compat | ||
completion | ||
contrib | ||
debian | ||
devel | ||
doc | ||
emacs | ||
lib | ||
packaging | ||
parse-time-string | ||
performance-test | ||
test | ||
util | ||
vim | ||
.dir-locals.el | ||
.gitignore | ||
.mailmap | ||
.travis.yml | ||
AUTHORS | ||
command-line-arguments.c | ||
command-line-arguments.h | ||
configure | ||
COPYING | ||
COPYING-GPL-3 | ||
debugger.c | ||
gmime-filter-reply.c | ||
gmime-filter-reply.h | ||
hooks.c | ||
INSTALL | ||
Makefile | ||
Makefile.global | ||
Makefile.local | ||
mime-node.c | ||
NEWS | ||
notmuch-client.h | ||
notmuch-compact.c | ||
notmuch-config.c | ||
notmuch-count.c | ||
notmuch-dump.c | ||
notmuch-insert.c | ||
notmuch-new.c | ||
notmuch-reindex.c | ||
notmuch-reply.c | ||
notmuch-restore.c | ||
notmuch-search.c | ||
notmuch-setup.c | ||
notmuch-show.c | ||
notmuch-tag.c | ||
notmuch-time.c | ||
notmuch.c | ||
query-string.c | ||
README | ||
README.rst | ||
sprinter-json.c | ||
sprinter-sexp.c | ||
sprinter-text.c | ||
sprinter.h | ||
status.c | ||
tag-util.c | ||
tag-util.h | ||
version |
Notmuch - thread-based email index, search and tagging. Notmuch is a system for indexing, searching, reading, and tagging large collections of email messages in maildir or mh format. It uses the Xapian library to provide fast, full-text search with a convenient search syntax. Notmuch is free software, released under the GNU General Public License version 3 (or later). Building notmuch ---------------- See the INSTALL file for notes on compiling and installing notmuch. Running notmuch --------------- After installing notmuch, start by running "notmuch setup" which will interactively prompt for configuration information such as your name, email address, and the directory which contains your mail archive to be indexed. You can change any answers later by running "notmuch setup" again or by editing the .notmuch-config file in your home directory. With notmuch configured you should next run "notmuch new" which will index all of your existing mail. This can take a long time, (several hours) if you have a lot of email, (hundreds of thousands of files). When new mail is delivered to your mail archive in the future, you will want to run "notmuch new" again. These runs will be much faster as they will only index new messages. Finally, you can prove to yourself that things are working by running some command-line searches such as "notmuch search from:someone@example.com" or "notmuch search subject:topic". See "notmuch help search-terms" for more details on the available search syntax. The command-line search output is not expected to be particularly friendly for day-to-day usage. Instead, it is expected that you will use an email interface that builds on the notmuch command-line tool or the libnotmuch library. Notmuch installs a full-featured email interface for use within emacs. To use this, first add the following line to your .emacs file: (autoload 'notmuch "notmuch" "Notmuch mail" t) Then, either run "emacs -f notmuch" or execute the command "M-x notmuch" from within a running emacs. If you're interested in a non-emacs-based interface to notmuch, then please join the notmuch community. Various other interfaces are already in progress, (an interface within vim, a curses interface, graphical interfaces based on evolution, and various web-based interfaces). The authors of these interfaces would love further testing or contribution. See contact information below. Contacting users and developers ------------------------------- The website for Notmuch is: https://notmuchmail.org The mailing list address for the notmuch community is: notmuch@notmuchmail.org We welcome any sort of questions, comments, kudos, or code there. Subscription is not required, (but if you do subscribe you'll avoid any delay due to moderation). See the website for subscription information. There is also an IRC channel dedicated to talk about using and developing notmuch: IRC server: irc.freenode.net Channel: #notmuch