* 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).