* Re: [bug] notmuch requires Content-Disposition mime header value to be lower case [not found] ` <20150917083612.1941.22480@localhost> @ 2015-09-17 8:39 ` Johannes Schauer 2015-09-18 12:03 ` David Bremner 0 siblings, 1 reply; 11+ messages in thread From: Johannes Schauer @ 2015-09-17 8:39 UTC (permalink / raw) To: notmuch [-- Attachment #1.1: Type: text/plain, Size: 1502 bytes --] Hi, Quoting Johannes Schauer (2015-09-17 10:36:12) > Quoting Johannes Schauer (2015-09-17 09:00:56) > > it seems that notmuch does not put the attachment tag if: > > > > Content-Disposition: ATTACHMENT; FILENAME=flyer-vk-web.pdf > > > > but it works for: > > > > Content-Disposition: attachment; filename=flyer-vk-web.pdf > > > > But rfc1341 says that the value should be treated as case insensitive (section 2). > > > > I got an email with upper case Content-Disposition value in an email with > > "User-Agent: Alpine 2.11 (LSU 23 2013-08-11)". > > > > Please CC me as I'm not subscribed - thanks! > > the fix seems to be to: > > --- a/lib/index.cc > +++ b/lib/index.cc > @@ -377,7 +377,7 @@ _index_mime_part (notmuch_message_t *message, > > disposition = g_mime_object_get_content_disposition (part); > if (disposition && > - strcmp (disposition->disposition, GMIME_DISPOSITION_ATTACHMENT) == 0) > + strcasecmp (disposition->disposition, GMIME_DISPOSITION_ATTACHMENT) == 0) > { > const char *filename = g_mime_part_get_filename (GMIME_PART (part)); > > > but then I saw that this was already done in your git. whoops, I confused my local git repositories. So the attached git format patch fixes the issue and adds a test case for this. Funnily though there seem to be some weird newline differences that I cannot explain, so I left them for somebody else to fix. Thanks! cheers, josch [-- Attachment #1.2: 0001-allow-case-insensitive-content-disposition-values.patch --] [-- Type: text/x-diff, Size: 1553 bytes --] From 8187076ab1ee9ce640cd15e9a214d49039b0f197 Mon Sep 17 00:00:00 2001 From: Johannes 'josch' Schauer <josch@mister-muffin.de> Date: Thu, 17 Sep 2015 10:39:29 +0200 Subject: [PATCH] allow case-insensitive content-disposition values --- lib/index.cc | 2 +- test/T190-multipart.sh | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/lib/index.cc b/lib/index.cc index e81aa81..34bab4e 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -377,7 +377,7 @@ _index_mime_part (notmuch_message_t *message, disposition = g_mime_object_get_content_disposition (part); if (disposition && - strcmp (disposition->disposition, GMIME_DISPOSITION_ATTACHMENT) == 0) + strcasecmp (disposition->disposition, GMIME_DISPOSITION_ATTACHMENT) == 0) { const char *filename = g_mime_part_get_filename (GMIME_PART (part)); diff --git a/test/T190-multipart.sh b/test/T190-multipart.sh index 7c4c9f7..f16cc90 100755 --- a/test/T190-multipart.sh +++ b/test/T190-multipart.sh @@ -48,7 +48,7 @@ cat embedded_message >> ${MAIL_DIR}/multipart cat <<EOF >> ${MAIL_DIR}/multipart --=-=-= -Content-Disposition: attachment; filename=attachment +Content-Disposition: ATTACHMENT; FILENAME=attachment This is a text attachment. @@ -487,7 +487,7 @@ This is an embedded message, with a multipart/alternative part. --==-=-==-- --=-=-= -Content-Disposition: attachment; filename=attachment +Content-Disposition: ATTACHMENT; FILENAME=attachment This is a text attachment. -- 2.5.1 [-- Attachment #2: signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV+nxcAAoJEPLLpcePvYPh1UUP/jAmxm4a0gq8rk2q58XjCI2c fmoKHteMlr4WbhgjfU0UHDFyz1iSkjh/xMPCMWffO178mkpDHv8gK1mosvpC4go3 D8kApTrjoQBcSI09PzSqZh8NZyaYps/2gfUcY15M5szRR7OVSql3FsbSaDWt+oQk Q4dGOgia101R17n95ENOxrA8kWB5THaeLC1FOx5IG+rYBsD1r7zrn8+JQZwHPvo7 jrfyBWD8IkgOwnBN+a39jt8f8KB2E+r6MHfor7BXhQt+DfhkFQhcBPUOZGmrIJzk aztYI4k7eOszjvQI8ShgFappC4vE1gcGkawAtafwpUK3M7zRQjF7r9E8JWZObcLS 2ZeUjV+XhC1TVsXRlfA9Ol7M7IG0HSxxEo6Q3gB+B3g/nIpbOmnYWwggK+S9DSaT 3TYlHdTG3nXeiS0XK18uJzv3DiZO54ZLLeGHvp02Mhc3DAEYL8hPsX1+QXyZpWQB N6KUbru79GCNolZOWzwemMXT8c5ptV9h9HbjIcaUZDoi/OpT25h7awzzYzq8/9Z/ ntMryD9H2DDcxuXqKOfQvhJJkwofaMyAIwrFEFoHEgDUdRRB/yJnmXjWTvZogHkd TXiZSZ0f+UCrLgcEpOtajxgaJCaFZX9FXlVwWGjUYtL3YAzdJOLJ6FPK2iwy5nC2 HbJ35KmFXSZ2U38uO2O/ =1KBd -----END PGP SIGNATURE----- ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [bug] notmuch requires Content-Disposition mime header value to be lower case 2015-09-17 8:39 ` [bug] notmuch requires Content-Disposition mime header value to be lower case Johannes Schauer @ 2015-09-18 12:03 ` David Bremner 2015-09-18 12:37 ` Johannes Schauer 0 siblings, 1 reply; 11+ messages in thread From: David Bremner @ 2015-09-18 12:03 UTC (permalink / raw) To: Johannes Schauer, notmuch Johannes Schauer <josch@debian.org> writes: > Funnily though there seem to be some weird newline differences that I cannot > explain, so I left them for somebody else to fix. > Looking at the files (.EXPECTED and .OUTPUT) in test/tmp.T190-multipart, there's more than whitespace changes. Some things that used to marked "attachment" in the output are now marked "part". > diff --git a/test/T190-multipart.sh b/test/T190-multipart.sh > index 7c4c9f7..f16cc90 100755 > --- a/test/T190-multipart.sh > +++ b/test/T190-multipart.sh > @@ -48,7 +48,7 @@ cat embedded_message >> ${MAIL_DIR}/multipart > cat <<EOF >> ${MAIL_DIR}/multipart > > --=-=-= > -Content-Disposition: attachment; filename=attachment > +Content-Disposition: ATTACHMENT; FILENAME=attachment > > This is a text attachment. > > @@ -487,7 +487,7 @@ This is an embedded message, with a multipart/alternative part. > --==-=-==-- > > --=-=-= > -Content-Disposition: attachment; filename=attachment > +Content-Disposition: ATTACHMENT; FILENAME=attachment > > This is a text attachment. > I'd recommend making your own new test, rather than modifying existing ones to test multiple things. I'd also recommend using json / sexp output for your tests, since the ad-hoc text format is kindof semi-deprecated. d ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bug] notmuch requires Content-Disposition mime header value to be lower case 2015-09-18 12:03 ` David Bremner @ 2015-09-18 12:37 ` Johannes Schauer 2015-09-18 13:26 ` David Bremner 0 siblings, 1 reply; 11+ messages in thread From: Johannes Schauer @ 2015-09-18 12:37 UTC (permalink / raw) To: David Bremner, notmuch [-- Attachment #1: Type: text/plain, Size: 893 bytes --] Hi, Quoting David Bremner (2015-09-18 14:03:20) > I'd recommend making your own new test, rather than modifying existing > ones to test multiple things. I'd also recommend using json / sexp > output for your tests, since the ad-hoc text format is kindof > semi-deprecated. can you take care of that? My goal was actually just to report this bug, not to spend more time to develop a proper patch for it :) Also, a related problem occurs when the Content-Disposition header contains UTF8 characters, in which case the header value gets encoded. Apparently notmuch does not attempt to decode it. Example mime header: --===============7161366892858136962== Content-Type: application/pdf MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9ImJlZ3LDvMOfdW5n?= =?utf-8?b?LnBkZiI=?= Thanks! cheers, josch [-- Attachment #2: signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJV/AWEAAoJEPLLpcePvYPhmIQQAKzQ2jHrlArH8TOK2Jc6Sj4a u+bIlsRfYhvfFxp0dwXXUEh1zwSiEdvdPb9oMYavggMlZz3Yog+T2KBxQEvU+Q6j Zc0ucb+TtuyzkmBMyijWuefsPVqMioHnyZdDxM7he3QCQBsJWQ9jOAXZ8BjEtmqA ciISmXNUf9jtcAJh3ZIssAT+5V+oKlGIBFjXlZCekBOumlOH/L9ej/L02EsyOvNE KTrdgtaWu/NnU0tbULgJxv7j8Via+0et5SJeaw0WsF9eYiuRVx99AnzhW2Wf6NhI QYgCeNIQagr0RTzI/ufGDfZD4t+LHVD1IZQ4jlNCT2o7zPVCCFSMHOf1zOQDG6Hs paOgfYSYNrPMUQYDnjqDElc7dV4viVzsMWIXw9YL/pW5sTtbfRX7+ZdM0OmXR4c7 lKx52dGYie+EQ2pU2GzOgJ+LEXMhbCl9w/jhEQdo5LsUdEL9MKS69V/RS1NpgMsP ySzYl1FOhZzj38XrePKvO5wc5EFj5S7zXaTPkAXMAKhML2I4hShPmUkJQEr2zwt6 lcKqVA+005+oxppLXrMvUO4PflpZAaQcopi/XTQ2w/885Q7P1Bhhke4AwNpY59l3 0GGdg28giEX7cgq5AwzV4zia0lwt7+nH8MGgOSHsRhmdsJcEEj06nVsw+8E12lkA rbTH+NWBLd0c+nWm0AYC =tIQp -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bug] notmuch requires Content-Disposition mime header value to be lower case 2015-09-18 12:37 ` Johannes Schauer @ 2015-09-18 13:26 ` David Bremner 2015-09-26 8:59 ` Jani Nikula 2015-09-26 9:35 ` [PATCH 1/2] lib: content disposition values are not case-sensitive Jani Nikula 0 siblings, 2 replies; 11+ messages in thread From: David Bremner @ 2015-09-18 13:26 UTC (permalink / raw) To: Johannes Schauer, notmuch Johannes Schauer <josch@debian.org> writes: > Hi, > > Quoting David Bremner (2015-09-18 14:03:20) >> I'd recommend making your own new test, rather than modifying existing >> ones to test multiple things. I'd also recommend using json / sexp >> output for your tests, since the ad-hoc text format is kindof >> semi-deprecated. > > can you take care of that? My goal was actually just to report this bug, not to > spend more time to develop a proper patch for it :) Consider the bug reported. At the moment I'm not completely convinced the patch is correct, never mind the tests. I agree it looks obvious enough, but the test results don't make sense to me yet. > > Also, a related problem occurs when the Content-Disposition header contains > UTF8 characters, in which case the header value gets encoded. Apparently > notmuch does not attempt to decode it. Example mime header: > > --===============7161366892858136962== > Content-Type: application/pdf > MIME-Version: 1.0 > Content-Transfer-Encoding: base64 > Content-Disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9ImJlZ3LDvMOfdW5n?= > =?utf-8?b?LnBkZiI=?= yes, that sounds like a distinct bug. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bug] notmuch requires Content-Disposition mime header value to be lower case 2015-09-18 13:26 ` David Bremner @ 2015-09-26 8:59 ` Jani Nikula 2015-09-26 9:35 ` [PATCH 1/2] lib: content disposition values are not case-sensitive Jani Nikula 1 sibling, 0 replies; 11+ messages in thread From: Jani Nikula @ 2015-09-26 8:59 UTC (permalink / raw) To: David Bremner, Johannes Schauer, notmuch On Fri, 18 Sep 2015, David Bremner <david@tethera.net> wrote: > Johannes Schauer <josch@debian.org> writes: > >> Hi, >> >> Quoting David Bremner (2015-09-18 14:03:20) >>> I'd recommend making your own new test, rather than modifying existing >>> ones to test multiple things. I'd also recommend using json / sexp >>> output for your tests, since the ad-hoc text format is kindof >>> semi-deprecated. >> >> can you take care of that? My goal was actually just to report this bug, not to >> spend more time to develop a proper patch for it :) > > Consider the bug reported. At the moment I'm not completely convinced > the patch is correct, never mind the tests. I agree it looks obvious > enough, but the test results don't make sense to me yet. > >> >> Also, a related problem occurs when the Content-Disposition header contains >> UTF8 characters, in which case the header value gets encoded. Apparently >> notmuch does not attempt to decode it. Example mime header: >> >> --===============7161366892858136962== >> Content-Type: application/pdf >> MIME-Version: 1.0 >> Content-Transfer-Encoding: base64 >> Content-Disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9ImJlZ3LDvMOfdW5n?= >> =?utf-8?b?LnBkZiI=?= > > yes, that sounds like a distinct bug. ...in the sending end. Correct me if you think I'm wrong, but I don't think that kind of encoding is allowed in Content-Disposition. BR, Jani. > _______________________________________________ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH 1/2] lib: content disposition values are not case-sensitive 2015-09-18 13:26 ` David Bremner 2015-09-26 8:59 ` Jani Nikula @ 2015-09-26 9:35 ` Jani Nikula 2015-09-26 9:35 ` [PATCH 2/2] cli: " Jani Nikula 2015-11-19 11:57 ` [PATCH 1/2] lib: content disposition values are not case-sensitive David Bremner 1 sibling, 2 replies; 11+ messages in thread From: Jani Nikula @ 2015-09-26 9:35 UTC (permalink / raw) To: David Bremner, Johannes Schauer, notmuch Per RFC 2183, the values for Content-Disposition values are not case-sensitive. While at it, use the gmime function for getting at the disposition string instead of referencing the field directly. This fixes "attachment" tagging and filename term generation for attachments while indexing. --- lib/index.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/index.cc b/lib/index.cc index e81aa8190288..f166aefd2fc1 100644 --- a/lib/index.cc +++ b/lib/index.cc @@ -377,7 +377,8 @@ _index_mime_part (notmuch_message_t *message, disposition = g_mime_object_get_content_disposition (part); if (disposition && - strcmp (disposition->disposition, GMIME_DISPOSITION_ATTACHMENT) == 0) + strcasecmp (g_mime_content_disposition_get_disposition (disposition), + GMIME_DISPOSITION_ATTACHMENT) == 0) { const char *filename = g_mime_part_get_filename (GMIME_PART (part)); -- 2.1.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH 2/2] cli: content disposition values are not case-sensitive 2015-09-26 9:35 ` [PATCH 1/2] lib: content disposition values are not case-sensitive Jani Nikula @ 2015-09-26 9:35 ` Jani Nikula 2015-10-06 10:20 ` [WIP] tests: add test for case insensitive Content-Disposition David Bremner 2015-11-19 11:57 ` [PATCH 1/2] lib: content disposition values are not case-sensitive David Bremner 1 sibling, 1 reply; 11+ messages in thread From: Jani Nikula @ 2015-09-26 9:35 UTC (permalink / raw) To: David Bremner, Johannes Schauer, notmuch Per RFC 2183, the values for Content-Disposition values are not case-sensitive. While at it, use the gmime function for getting at the disposition string instead of referencing the field directly. This fixes attachment display and quoting in notmuch show and reply, respectively. --- notmuch-reply.c | 3 ++- notmuch-show.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/notmuch-reply.c b/notmuch-reply.c index fd6a1ec1b11d..437c4ed5acc2 100644 --- a/notmuch-reply.c +++ b/notmuch-reply.c @@ -80,7 +80,8 @@ format_part_reply (mime_node_t *node) show_text_part_content (node->part, stream_stdout, NOTMUCH_SHOW_TEXT_PART_REPLY); g_object_unref(stream_stdout); } else if (disposition && - strcmp (disposition->disposition, GMIME_DISPOSITION_ATTACHMENT) == 0) { + strcasecmp (g_mime_content_disposition_get_disposition (disposition), + GMIME_DISPOSITION_ATTACHMENT) == 0) { const char *filename = g_mime_part_get_filename (GMIME_PART (node->part)); printf ("Attachment: %s (%s)\n", filename, g_mime_content_type_to_string (content_type)); diff --git a/notmuch-show.c b/notmuch-show.c index e05480899b33..e9f4dffe0877 100644 --- a/notmuch-show.c +++ b/notmuch-show.c @@ -456,7 +456,8 @@ format_part_text (const void *ctx, sprinter_t *sp, mime_node_t *node, g_mime_part_get_filename (GMIME_PART (node->part)) : NULL; if (disposition && - strcmp (disposition->disposition, GMIME_DISPOSITION_ATTACHMENT) == 0) + strcasecmp (g_mime_content_disposition_get_disposition (disposition), + GMIME_DISPOSITION_ATTACHMENT) == 0) part_type = "attachment"; else part_type = "part"; -- 2.1.4 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [WIP] tests: add test for case insensitive Content-Disposition 2015-09-26 9:35 ` [PATCH 2/2] cli: " Jani Nikula @ 2015-10-06 10:20 ` David Bremner 2015-10-18 11:58 ` Jani Nikula 0 siblings, 1 reply; 11+ messages in thread From: David Bremner @ 2015-10-06 10:20 UTC (permalink / raw) To: Jani Nikula, David Bremner, Johannes Schauer, notmuch These broken now, but will be fixed in the next commit --- The first test is OK, but the second one currently fails. It isn't clear to me if content dispositions permit RFC2047 style encoding. GMime does not decode them automatically (hence this test is failing). What is true is that the RFC states "Unrecognized disposition types should be treated as `attachment'". So maybe the logic in patch 1 should be reversed to check != 'inline'. test/T190-multipart.sh | 109 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 109 insertions(+) diff --git a/test/T190-multipart.sh b/test/T190-multipart.sh index 7c4c9f7..0f55e10 100755 --- a/test/T190-multipart.sh +++ b/test/T190-multipart.sh @@ -763,4 +763,113 @@ test_begin_subtest "indexes mime-type #3" output=$(notmuch search from:todd and mimetype:multipart/alternative | notmuch_search_sanitize) test_expect_equal "$output" "thread:XXX 2014-01-12 [1/1] Todd; odd content types (inbox unread)" +test_begin_subtest "case of Content-Disposition doesn't matter for indexing" +test_subtest_known_broken +cat <<EOF > ${MAIL_DIR}/content-disposition +Return-path: <david@tethera.net> +Envelope-to: david@tethera.net +Delivery-date: Sun, 04 Oct 2015 09:16:03 -0300 +Received: from gitolite.debian.net ([87.98.215.224]) + by yantan.tethera.net with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) + (Exim 4.80) + (envelope-from <david@tethera.net>) + id 1ZiiCx-0007iz-RK + for david@tethera.net; Sun, 04 Oct 2015 09:16:03 -0300 +Received: from remotemail by gitolite.debian.net with local (Exim 4.80) + (envelope-from <david@tethera.net>) + id 1ZiiC8-0002Rz-Uf; Sun, 04 Oct 2015 12:15:12 +0000 +Received: (nullmailer pid 28621 invoked by uid 1000); Sun, 04 Oct 2015 + 12:14:53 -0000 +From: David Bremner <david@tethera.net> +To: David Bremner <david@tethera.net> +Subject: test attachment +User-Agent: Notmuch/0.20.2+93~g33c8777 (http://notmuchmail.org) Emacs/24.5.1 + (x86_64-pc-linux-gnu) +Date: Sun, 04 Oct 2015 09:14:53 -0300 +Message-ID: <87io6m96f6.fsf@zancas.localnet> +MIME-Version: 1.0 +Content-Type: multipart/mixed; boundary="=-=-=" + +--=-=-= +Content-Type: text/plain +Content-Disposition: ATTACHMENT; filename=hello.txt +Content-Description: this is a very exciting file + +hello + +--=-=-= +Content-Type: text/plain + + +world + +--=-=-=-- + +EOF +NOTMUCH_NEW + +cat <<EOF > EXPECTED +attachment +inbox +unread +EOF + +notmuch search --output=tags id:87io6m96f6.fsf@zancas.localnet > OUTPUT +test_expect_equal_file EXPECTED OUTPUT + +test_begin_subtest "encoded Content-Disposition header" +test_subtest_known_broken +cat <<EOF > ${MAIL_DIR}/content-disposition2 +Return-path: <david@tethera.net> +Envelope-to: david@tethera.net +Delivery-date: Sun, 04 Oct 2015 09:16:03 -0300 +Received: from gitolite.debian.net ([87.98.215.224]) + by yantan.tethera.net with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) + (Exim 4.80) + (envelope-from <david@tethera.net>) + id 1ZiiCx-0007iz-RK + for david@tethera.net; Sun, 04 Oct 2015 09:16:03 -0300 +Received: from remotemail by gitolite.debian.net with local (Exim 4.80) + (envelope-from <david@tethera.net>) + id 1ZiiC8-0002Rz-Uf; Sun, 04 Oct 2015 12:15:12 +0000 +Received: (nullmailer pid 28621 invoked by uid 1000); Sun, 04 Oct 2015 + 12:14:53 -0000 +From: David Bremner <david@tethera.net> +To: David Bremner <david@tethera.net> +Subject: test attachment +User-Agent: Notmuch/0.20.2+93~g33c8777 (http://notmuchmail.org) Emacs/24.5.1 + (x86_64-pc-linux-gnu) +Date: Sun, 04 Oct 2015 09:14:53 -0300 +Message-ID: <87io6m96f6.fsf.2@zancas.localnet> +MIME-Version: 1.0 +Content-Type: multipart/mixed; boundary="=-=-=" + +--=-=-= +Content-Type: text/plain +Content-Disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9ImJlZ3LDvMOfdW5n?= + =?utf-8?b?LnBkZiI=?= +Content-Description: this is a very exciting file + +hello + +--=-=-= +Content-Type: text/plain + + +world + +--=-=-=-- + +EOF +NOTMUCH_NEW + +cat <<EOF > EXPECTED +attachment +inbox +unread +EOF + +notmuch search --output=tags id:87io6m96f6.fsf.2@zancas.localnet > OUTPUT +test_expect_equal_file EXPECTED OUTPUT + test_done -- 2.5.3 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [WIP] tests: add test for case insensitive Content-Disposition 2015-10-06 10:20 ` [WIP] tests: add test for case insensitive Content-Disposition David Bremner @ 2015-10-18 11:58 ` Jani Nikula 2015-10-18 12:05 ` Johannes Schauer 0 siblings, 1 reply; 11+ messages in thread From: Jani Nikula @ 2015-10-18 11:58 UTC (permalink / raw) To: David Bremner, David Bremner, Johannes Schauer, notmuch On Tue, 06 Oct 2015, David Bremner <david@tethera.net> wrote: > These broken now, but will be fixed in the next commit > --- > > The first test is OK, but the second one currently fails. It isn't > clear to me if content dispositions permit RFC2047 style > encoding. GMime does not decode them automatically (hence this test is > failing). What is true is that the RFC states "Unrecognized > disposition types should be treated as `attachment'". So maybe the > logic in patch 1 should be reversed to check != 'inline'. > +Content-Type: text/plain > +Content-Disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9ImJlZ3LDvMOfdW5n?= > + =?utf-8?b?LnBkZiI=?= > +Content-Description: this is a very exciting file Did you handcraft the example, or did some program actually produce this? I don't think this is [RFC 2231] compliant. IIUC only the content disposition parameter values may contain encoded words with charset/language specification. Like this, Content-Disposition: attachment; filename="=?utf-8?B?cMOkw6RtaWVz?=" We currently handle that correctly, and UTF-8 searches with attachment: prefix work. It's just that the disposition-type (usually "attachment" or "inline") should be interpreted case insensitive, which we currently fail at. What should we do about malformed content-disposition fields then? I think I'd just defer this to gmime. Sadly email seems to be a prime example of rampant robustness principle abuse. It has degenerated into, "Be liberal in what you send, be liberal in what you accept", which is getting dangerously close to the GIGO principle. BR, Jani. [RFC 2231] https://tools.ietf.org/html/rfc2231 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [WIP] tests: add test for case insensitive Content-Disposition 2015-10-18 11:58 ` Jani Nikula @ 2015-10-18 12:05 ` Johannes Schauer 0 siblings, 0 replies; 11+ messages in thread From: Johannes Schauer @ 2015-10-18 12:05 UTC (permalink / raw) To: Jani Nikula, David Bremner, David Bremner, notmuch [-- Attachment #1: Type: text/plain, Size: 1251 bytes --] Hi, Quoting Jani Nikula (2015-10-18 13:58:01) > On Tue, 06 Oct 2015, David Bremner <david@tethera.net> wrote: > > These broken now, but will be fixed in the next commit > > --- > > > > The first test is OK, but the second one currently fails. It isn't > > clear to me if content dispositions permit RFC2047 style > > encoding. GMime does not decode them automatically (hence this test is > > failing). What is true is that the RFC states "Unrecognized > > disposition types should be treated as `attachment'". So maybe the > > logic in patch 1 should be reversed to check != 'inline'. > > > +Content-Type: text/plain > > +Content-Disposition: =?utf-8?b?YXR0YWNobWVudDsgZmlsZW5hbWU9ImJlZ3LDvMOfdW5n?= > > + =?utf-8?b?LnBkZiI=?= > > +Content-Description: this is a very exciting file > > Did you handcraft the example, or did some program actually produce > this? I don't think this is [RFC 2231] compliant. IIUC only the content > disposition parameter values may contain encoded words with > charset/language specification. Like this, > > Content-Disposition: attachment; filename="=?utf-8?B?cMOkw6RtaWVz?=" I'm using alot as my MUA and that produced the Content-Disposition line I quoted. Thanks! cheers, josch [-- Attachment #2: signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJWI4sYAAoJEPLLpcePvYPhjnsP/1yEawnlB7hExS9Bb8dUqOh7 paNeYjCUNAGko0z+Kt4YysWvK/T7McXr/U9t6osmeKoaRmiCijUTi/9yfXBu3to1 Ou28Fa/gUyfJbiMtE8JbTUfqB/dOSy2wY5RNfAqikU8NkhuNsAjhkncRautZ+YyY HLJUigT6V5nVoN7FlGjJ1atalEqbn5kpZlnIIafQWW5M5cnHSWiL1n7lmBjWev/T bQyDmKGN7JN6eyeyHbqvqIcNIPsGQd7sODUNW4ukUz9R1wVzNGBWqpXiI8+zCN3d YXg1jMNEzGaAjYTcyFKYe74KD2E5tgDeXmII63B7cpsry6OJRHcQUD9I8CJWylC9 ZRuPk4YZy9s8CMtioTPoTq+w8siccSLB9Qcrr3pWWy1b4sNCDgnmSYQD9YJuGgkt 4pzYX3AaorN2ILEuWzN8tqb7iTQXfQLoLYSFoR6lrVO48BGBY7L8Wc+OJUkw+AeX Czel0eD2mny6SxFw7NtRsDBo1Wwzp869YKd2X0MTVrUm9ZXlRfGcXAGQFBTQFPTn WaYnSCY9bKpXoZldI9tJq6wIoPd54w6GYCbMLMEZisn4mFHVeOgGlwPUaYzsm86T 835AGm62l+26M50V4L6c3DTJ1D5O8sKsXSA9CakPypSGyGXOZAY8gNZX7Y+sof7Q YcbmXyBxKNCFpTrkQW0h =H93j -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH 1/2] lib: content disposition values are not case-sensitive 2015-09-26 9:35 ` [PATCH 1/2] lib: content disposition values are not case-sensitive Jani Nikula 2015-09-26 9:35 ` [PATCH 2/2] cli: " Jani Nikula @ 2015-11-19 11:57 ` David Bremner 1 sibling, 0 replies; 11+ messages in thread From: David Bremner @ 2015-11-19 11:57 UTC (permalink / raw) To: Jani Nikula, Johannes Schauer, notmuch Jani Nikula <jani@nikula.org> writes: > Per RFC 2183, the values for Content-Disposition values are not > case-sensitive. While at it, use the gmime function for getting at the > disposition string instead of referencing the field directly. I pushed these two, along with the working test from my patch. If someone actually has a fix for the other test, we can return to discussing whether it's a bug or not. d ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-11-19 11:59 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20150917070056.1941.94846@localhost>
[not found] ` <20150917083612.1941.22480@localhost>
2015-09-17 8:39 ` [bug] notmuch requires Content-Disposition mime header value to be lower case Johannes Schauer
2015-09-18 12:03 ` David Bremner
2015-09-18 12:37 ` Johannes Schauer
2015-09-18 13:26 ` David Bremner
2015-09-26 8:59 ` Jani Nikula
2015-09-26 9:35 ` [PATCH 1/2] lib: content disposition values are not case-sensitive Jani Nikula
2015-09-26 9:35 ` [PATCH 2/2] cli: " Jani Nikula
2015-10-06 10:20 ` [WIP] tests: add test for case insensitive Content-Disposition David Bremner
2015-10-18 11:58 ` Jani Nikula
2015-10-18 12:05 ` Johannes Schauer
2015-11-19 11:57 ` [PATCH 1/2] lib: content disposition values are not case-sensitive David Bremner
Code repositories for project(s) associated with this public inbox https://yhetil.org/notmuch.git/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).