debian/notmuch
1
0
Fork 0
mirror of https://git.notmuchmail.org/git/notmuch synced 2024-11-22 19:08:09 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
notmuch/test/corpora/protected-headers/protected-with-legacy-display.eml

41 lines
1.5 KiB
Text
Raw Normal View History

test: avoid showing legacy-display parts Enigmail generates a "legacy-display" part when it sends encrypted mail with a protected Subject: header. This part is intended to display the Subject for mail user agents that are capable of decryption, but do not know how to deal with embedded protected headers. This part is the first child of a two-part multipart/mixed cryptographic payload within a cryptographic envelope that includes encryption (that is, it is not just a cleartext signed message). It uses Content-Type: text/rfc822-headers. That is: A └┬╴multipart/encrypted B ├─╴application/pgp-encrypted C └┬╴application/octet-stream * ╤ <decryption> D └┬╴multipart/mixed; protected-headers=v1 (cryptographic payload) E ├─╴text/rfc822-headers; protected-headers=v1 (legacy-display part) F └─╴… (actual message body) In discussions with jrollins, i've come to the conclusion that a legacy-display part should be stripped entirely from "notmuch show" and "notmuch reply" now that these tools can understand and interpret protected headers. You can tell when a message part is a protected header part this way: * is the payload (D) multipart/mixed with exactly two children? * is its first child (E) Content-Type: text/rfc822-headers? * does the first child (E) have the property protected-headers=v1? * do all the headers in the body of the first child (E) match the protected headers in the payload part (D) itself? If this is the case, and we already know how to deal with the protected header, then there is no reason to try to render the legacy-display part itself for the user. Furthermore, when indexing, if we are indexing properly, we should avoid indexing the text in E as part of the message body. 'notmuch reply' is an interesting case: the standard use of 'notmuch reply' will end up omitting all mention of protected Subject:. The right fix is for the replying MUA to be able to protect its headers, and for it to set them appropriately based on headers found in the original message. If a replying MUA is unable to protect headers, but still wants the user to be able to see the original header, a replying MUA that notices that the original message's subject differs from the proposed reply subject may choose to include the original's subject in the quoted/attributed text. (this would be a stopgap measure; it's not even clear that there is user demand for it) This test suite change indicates what we want to happen for this case (the tests are currently broken), and includes three additional TODO suggestions of subtle cases for anyone who wants to flesh out the test suite even further. (i believe all these cases should be already fixed by the rest of this series, but haven't had time to write the tests for the unusual cases) Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
2019-08-29 17:38:48 +02:00
From: test_suite@notmuchmail.org
To: test_suite@notmuchmail.org
Subject: Subject Unavailable
Date: Sat, 01 Jan 2000 12:00:00 +0000
Message-Id: <protected-with-legacy-display@crypto.notmuchmail.org>
MIME-Version: 1.0
Content-Type: multipart/encrypted; boundary="=-=-=";
protocol="application/pgp-encrypted"
--=-=-=
Content-Type: application/pgp-encrypted
Version: 1
--=-=-=
Content-Type: application/octet-stream
-----BEGIN PGP MESSAGE-----
hIwDxE023q1UqxYBBACkgwtKOAP+UlKYDzYkZY+gDuMNKnHjWIvv2Cdnovy40QzL
5sbuib40y7orO+MqYMCWpoFtgBVsGiOUE3bZAg8n3Ji38/zVGwQveu6sh7SAy0Q9
zFEvLhtajw17nPe+QH2UmIyfVikA57Mot13THq4i6C4ozVCyhyIltx+sNJkmw9Lp
AdQd+cgCMRSMbi++eRwIi4zgxKrfAoGOmdMiVzBrh3yZqnbI0rCxJIKu7gEWuQLT
7BuvN2bJUkPGLAUhUanFararVoD7WWOl67IlWFkyncES0PRskUf9coV68WZnYjsR
Y3LdLnha1sdMwUNeBKQ44XBd2e7mXbDSp1cSjTDf9euwB4m7uQFTLwoQ8Of+LmQD
KMHzjmucbkNAIpfAjcDusTA/oaaqUiEgGIgYYMDqG1CaaxdT55S7tMjW5yJryQmo
pg65jrUMgEn5XHZ+KI2OsCmwGdoBYNau8p1a2hsiKhHJmLUeEAu34gFI3hylIOC0
0KC40d0zTSb0s7SZuTrD6vYgiXG9aFktHvAWFH0ATCts7qyiRN7k5jt7yWfRntE2
UCexTGE3TH7aju+IqDPC1XsaKF4T3CVhdr8WmKCa+0VOaw7xHRGYnzq9y91GcaCx
8AcoZ3kYs+f2LIn+T667A0KKP4Z6OmLjCx3b1RvRUQYR9taruEMAQbIuAajiyTe9
KfUrsUULZfInE50x+OneYvDhzoSgSJoHIK+18X/wo6YcyleJ9fZxCQ/vaXTDkAeF
ve7TFcbIqmJ4MHygXILHUuDwp7P4t/tIL7SZwja70P3digjsgoNZY29VTnU8uyIb
d6eOjgpeNVhRjDWxbUvhFD7i4rHCi/bbXFlW0cCXoiaVQBtYmiNysRoRZOv0h3TW
q/+/UmqkaQFnF3zp5sr87y+ValItgPWmb9Ds0lyAoSvQx35zVh8DFfH04m7hmsb7
gcvemlPTAnQWkIMC3c/bZWgt8tNcG7tQeUMWd9n4281y/hApbm90x2NLzEqvVcRq
K0iIgVxbCHSKqGh4TtbIwpNhzSP+KHYkZ8h6+QUDRwGEV9QqZKg=
=2O0V
-----END PGP MESSAGE-----
--=-=-=--
Reference in a new issue Copy permalink