debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-21 18:38:08 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/test/T510-thread-replies.sh

237 lines
10 KiB
Bash
Raw Normal View History

test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
#!/usr/bin/env bash
#
# Copyright (c) 2013 Aaron Ecay
#
test_description='test of proper handling of in-reply-to and references headers'
# This test makes sure that the thread structure in the notmuch
# database is constructed properly, even in the presence of
# non-RFC-compliant headers'
test: use $(dirname "$0") for sourcing test-lib.sh Don't assume the tests are always run from within the source tree.
2017-09-25 22:38:19 +02:00
. $(dirname "$0")/test-lib.sh || exit 1
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
test_begin_subtest "Use References when In-Reply-To is broken"
add_message '[id]="foo@one.com"' \
'[subject]=one'
add_message '[in-reply-to]="mumble"' \
'[references]="<foo@one.com>"' \
'[subject]="Re: one"'
output=$(notmuch show --format=json 'subject:one' | notmuch_json_show_sanitize)
expected='[[[{"id": "foo@one.com",
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"match": true,
"excluded": false,
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"timestamp": 978709437,
"date_relative": "2001-01-05",
"tags": ["inbox", "unread"],
"headers": {"Subject": "one",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"},
"body": [{"id": 1,
"content-type": "text/plain",
"content": "This is just a test message (#1)\n"}]},
[[{"id": "msg-002@notmuch-test-suite",
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"match": true, "excluded": false,
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"timestamp": 978709437, "date_relative": "2001-01-05",
"tags": ["inbox", "unread"], "headers": {"Subject": "Re: one",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"},
"body": [{"id": 1, "content-type": "text/plain",
"content": "This is just a test message (#2)\n"}]}, []]]]]]'
expected=`echo "$expected" | notmuch_json_show_sanitize`
test_expect_equal_json "$output" "$expected"
test/thread-replies: mangle In-Reply-To's In a future commit, we will start trusting In-Reply-To's when they look sane (i.e. a single message-id). Modify these tests so they will keep passing (i.e. keep choosing References) when that happens.
2018-08-30 13:29:12 +02:00
test_begin_subtest "Prefer References to dodgy In-Reply-To"
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
add_message '[id]="foo@two.com"' \
'[subject]=two'
test/thread-replies: mangle In-Reply-To's In a future commit, we will start trusting In-Reply-To's when they look sane (i.e. a single message-id). Modify these tests so they will keep passing (i.e. keep choosing References) when that happens.
2018-08-30 13:29:12 +02:00
add_message '[in-reply-to]="Your message of December 31 1999 <bar@baz.com>"' \
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
'[references]="<foo@two.com>"' \
'[subject]="Re: two"'
output=$(notmuch show --format=json 'subject:two' | notmuch_json_show_sanitize)
expected='[[[{"id": "foo@two.com",
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"match": true, "excluded": false,
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["inbox", "unread"],
"headers": {"Subject": "two",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"},
"body": [{"id": 1, "content-type": "text/plain",
"content": "This is just a test message (#3)\n"}]},
[[{"id": "msg-004@notmuch-test-suite", "match": true, "excluded": false,
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["inbox", "unread"],
"headers": {"Subject": "Re: two",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"},
"body": [{"id": 1,
"content-type": "text/plain", "content": "This is just a test message (#4)\n"}]},
[]]]]]]'
expected=`echo "$expected" | notmuch_json_show_sanitize`
test_expect_equal_json "$output" "$expected"
test_begin_subtest "Use In-Reply-To when no References"
add_message '[id]="foo@three.com"' \
'[subject]="three"'
add_message '[in-reply-to]="<foo@three.com>"' \
'[subject]="Re: three"'
output=$(notmuch show --format=json 'subject:three' | notmuch_json_show_sanitize)
expected='[[[{"id": "foo@three.com", "match": true, "excluded": false,
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["inbox", "unread"],
"headers": {"Subject": "three",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"}, "body": [{"id": 1,
"content-type": "text/plain", "content": "This is just a test message (#5)\n"}]},
[[{"id": "msg-006@notmuch-test-suite", "match": true, "excluded": false,
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["inbox", "unread"],
"headers": {"Subject": "Re: three",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"}, "body": [{"id": 1,
"content-type": "text/plain", "content": "This is just a test message (#6)\n"}]},
[]]]]]]'
expected=`echo "$expected" | notmuch_json_show_sanitize`
test_expect_equal_json "$output" "$expected"
test/thread-replies: mangle In-Reply-To's In a future commit, we will start trusting In-Reply-To's when they look sane (i.e. a single message-id). Modify these tests so they will keep passing (i.e. keep choosing References) when that happens.
2018-08-30 13:29:12 +02:00
test_begin_subtest "Use last Reference when In-Reply-To is dodgy"
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
add_message '[id]="foo@four.com"' \
'[subject]="four"'
add_message '[id]="bar@four.com"' \
'[subject]="not-four"'
test/thread-replies: mangle In-Reply-To's In a future commit, we will start trusting In-Reply-To's when they look sane (i.e. a single message-id). Modify these tests so they will keep passing (i.e. keep choosing References) when that happens.
2018-08-30 13:29:12 +02:00
add_message '[in-reply-to]="<baz@four.com> (RFC822 4lyfe)"' \
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
'[references]="<baz@four.com> <foo@four.com>"' \
'[subject]="neither"'
output=$(notmuch show --format=json 'subject:four' | notmuch_json_show_sanitize)
expected='[[[{"id": "foo@four.com", "match": true, "excluded": false,
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["inbox", "unread"],
"headers": {"Subject": "four",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"}, "body": [{"id": 1,
"content-type": "text/plain", "content": "This is just a test message (#7)\n"}]},
[[{"id": "msg-009@notmuch-test-suite", "match": false, "excluded": false,
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["inbox", "unread"],
"headers": {"Subject": "neither",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"}, "body": [{"id": 1,
"content-type": "text/plain", "content": "This is just a test message (#9)\n"}]},
[]]]]], [[{"id": "bar@four.com", "match": true, "excluded": false,
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"],
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
"timestamp": 978709437, "date_relative": "2001-01-05", "tags": ["inbox", "unread"],
"headers": {"Subject": "not-four",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "Fri, 05 Jan 2001 15:43:57 +0000"}, "body": [{"id": 1,
"content-type": "text/plain", "content": "This is just a test message (#8)\n"}]}, []]]]'
expected=`echo "$expected" | notmuch_json_show_sanitize`
test_expect_equal_json "$output" "$expected"
Add test for incorrect threading of messages This happens when there is some garbage after the last Message-ID in the References header. See for example https://lkml.org/lkml/headers/2014/5/19/864.
2014-05-26 16:05:56 +02:00
test_begin_subtest "Ignore garbage at the end of References"
add_message '[id]="foo@five.com"' \
'[subject]="five"'
add_message '[id]="bar@five.com"' \
'[references]="<foo@five.com> (garbage)"' \
'[subject]="not-five"'
output=$(notmuch show --format=json 'subject:five' | notmuch_json_show_sanitize)
expected='[[[{"id": "XXXXX", "match": true, "excluded": false,
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"], "timestamp": 42, "date_relative": "2001-01-05",
Add test for incorrect threading of messages This happens when there is some garbage after the last Message-ID in the References header. See for example https://lkml.org/lkml/headers/2014/5/19/864.
2014-05-26 16:05:56 +02:00
"tags": ["inbox", "unread"], "headers": {"Subject": "five",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "GENERATED_DATE"}, "body": [{"id": 1,
"content-type": "text/plain",
"content": "This is just a test message (#10)\n"}]},
[[{"id": "XXXXX", "match": true, "excluded": false,
cli/show: emit new whole-message crypto status output This allows MUAs that don't want to think about per-mime-part cryptographic status to have a simple high-level overview of the message's cryptographic state. Sensibly structured encrypted and/or signed messages will work fine with this. The only requirement for the simplest encryption + signing is that the message have all of its encryption and signing protection (the "cryptographic envelope") in a contiguous set of MIME layers at the very outside of the message itself. This is because messages with some subparts signed or encrypted, but with other subparts with no cryptographic protection is very difficult to reason about, and even harder for the user to make sense of or work with. For further characterization of the Cryptographic Envelope and some of the usability tradeoffs, see here: https://dkg.fifthhorseman.net/blog/e-mail-cryptography.html#cryptographic-envelope
2019-05-25 20:04:06 +02:00
"crypto": {},
cli/show: list all filenames of a message in the formatted output Instead of just having the first filename for the message, list all duplicate filenames of the message as a list in the formatted outputs. This bumps the format version to 3.
2017-02-25 14:31:31 +01:00
"filename": ["YYYYY"], "timestamp": 42, "date_relative": "2001-01-05",
Add test for incorrect threading of messages This happens when there is some garbage after the last Message-ID in the References header. See for example https://lkml.org/lkml/headers/2014/5/19/864.
2014-05-26 16:05:56 +02:00
"tags": ["inbox", "unread"],
"headers": {"Subject": "not-five",
"From": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"To": "Notmuch Test Suite <test_suite@notmuchmail.org>",
"Date": "GENERATED_DATE"},
"body": [{"id": 1, "content-type": "text/plain",
"content": "This is just a test message (#11)\n"}]}, []]]]]]'
expected=`echo "$expected" | notmuch_json_show_sanitize`
test_expect_equal_json "$output" "$expected"
test: add known broken tests for "ghost roots" This documents the bug discussed at id:87efgmmysi.fsf@len.workgroup The underlying issue is that the reply to a ghost (missing) message is falsely classified as a root message in _resolve_thread_relationships. There are two pairs of tests; in each case the the first test is simpler / more robust, but also easier to fool.
2018-08-30 13:29:03 +02:00
add_email_corpus threading
test_begin_subtest "reply to ghost"
notmuch show --entire-thread=true id:000-real-root@example.org | grep ^Subject: | head -1 > OUTPUT
cat <<EOF > EXPECTED
Subject: root message
EOF
test_expect_equal_file EXPECTED OUTPUT
test_begin_subtest "reply to ghost (tree view)"
test_emacs '(notmuch-tree "id:000-real-root@example.org")
(notmuch-test-wait)
(test-output)
(delete-other-windows)'
cat <<EOF > EXPECTED
2016-06-17 Alice ┬►root message (inbox unread)
2016-06-18 Alice ╰┬►child message (inbox unread)
2016-06-17 Mallory ├─►fake root message (inbox unread)
2016-06-18 Alice ├┬►grand-child message (inbox unread)
2016-06-18 Alice │╰─►great grand-child message (inbox unread)
2016-06-18 Daniel ╰─►grand-child message 2 (inbox unread)
End of search results.
EOF
test_expect_equal_file EXPECTED OUTPUT
test_begin_subtest "reply to ghost (RT)"
notmuch show --entire-thread=true id:87bmc6lp3h.fsf@len.workgroup | grep ^Subject: | head -1 > OUTPUT
cat <<EOF > EXPECTED
Subject: FYI: xxxx xxxxxxx xxxxxxxxxxxx xxx
EOF
test_expect_equal_file EXPECTED OUTPUT
test_begin_subtest "reply to ghost (RT/tree view)"
test_emacs '(notmuch-tree "id:87bmc6lp3h.fsf@len.workgroup")
(notmuch-test-wait)
(test-output)
(delete-other-windows)'
cat <<EOF > EXPECTED
2016-06-19 Gregor Zattler ┬┬►FYI: xxxx xxxxxxx xxxxxxxxxxxx xxx (inbox unread)
2016-06-19 via RT │╰─►[support.xxxxxxxxxxx-xxxxxxxxx-xxxxxxxxx.de #33575] AutoReply: FYI: xxxx xxxxxxx xxxxxxxxxxxx xxx (inbox unread)
2016-06-26 via RT ╰─►[support.xxxxxxxxxxx-xxxxxxxxx-xxxxxxxxx.de #33575] Resolved: FYI: xxxx xxxxxxx xxxxxxxxxxxx xxx (inbox unread)
End of search results.
EOF
test_expect_equal_file EXPECTED OUTPUT
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
test: add known broken test for good In-Reply-To / bad References The current scheme of choosing the replyto (i.e. the default parent for threading purposes) does not work well for mailers that put the oldest Reference last.
2018-08-30 13:29:11 +02:00
test_begin_subtest "trusting reply-to (tree view)"
test_emacs '(notmuch-tree "id:B00-root@example.org")
(notmuch-test-wait)
(test-output)
(delete-other-windows)'
cat <<EOF > EXPECTED
2016-06-17 Alice ┬►root message (inbox unread)
2016-06-18 Alice ╰┬►child message (inbox unread)
2016-06-18 Alice ╰─►grand-child message (inbox unread)
End of search results.
EOF
test_expect_equal_file EXPECTED OUTPUT
test: add tests for the handling of References and In-Reply-To headers These tests are known_broken, the following commit fixes them. amended per id:87txmi1zq3.fsf@nikula.org id:87vc6yalo7.fsf@zancas.localnet
2013-03-06 04:31:48 +01:00
test_done
Reference in a new issue Copy permalink