Re: [WIP] tests: add test for case insensitive Content-Disposition

[Jani Nikula]

On Tue, 06 Oct 2015, David Bremner  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
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [WIP] tests: add test for case insensitive Content-Disposition

[Johannes Schauer]

Hi,

Quoting Jani Nikula (2015-10-18 13:58:01)
> On Tue, 06 Oct 2015, David Bremner  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


signature.asc
Description: signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[WIP] tests: add test for case insensitive Content-Disposition

[David Bremner]

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 < ${MAIL_DIR}/content-disposition
+Return-path: 
+Envelope-to: da...@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 )
+   id 1ZiiCx-0007iz-RK
+   for da...@tethera.net; Sun, 04 Oct 2015 09:16:03 -0300
+Received: from remotemail by gitolite.debian.net with local (Exim 4.80)
+   (envelope-from )
+   id 1ZiiC8-0002Rz-Uf; Sun, 04 Oct 2015 12:15:12 +
+Received: (nullmailer pid 28621 invoked by uid 1000); Sun, 04 Oct 2015
+ 12:14:53 -
+From: David Bremner 
+To: David Bremner 
+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 < 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 < ${MAIL_DIR}/content-disposition2
+Return-path: 
+Envelope-to: da...@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 )
+   id 1ZiiCx-0007iz-RK
+   for da...@tethera.net; Sun, 04 Oct 2015 09:16:03 -0300
+Received: from remotemail by gitolite.debian.net with local (Exim 4.80)
+   (envelope-from )
+   id 1ZiiC8-0002Rz-Uf; Sun, 04 Oct 2015 12:15:12 +
+Received: (nullmailer pid 28621 invoked by uid 1000); Sun, 04 Oct 2015
+ 12:14:53 -
+From: David Bremner 
+To: David Bremner 
+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 < 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

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch