Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id D00DF6DE1643 for ; Sun, 18 Oct 2015 04:58:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.177 X-Spam-Level: X-Spam-Status: No, score=-0.177 tagged_above=-999 required=5 tests=[AWL=-0.201, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_SBL=0.644, URIBL_SBL_A=0.1] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAZ345IpErQi for ; Sun, 18 Oct 2015 04:58:34 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by arlo.cworth.org (Postfix) with ESMTPS id BF31B6DE0943 for ; Sun, 18 Oct 2015 04:58:33 -0700 (PDT) Received: by wicfx6 with SMTP id fx6so15578945wic.1 for ; Sun, 18 Oct 2015 04:58:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-type; bh=1YFiJytSkauuI/z+hnTMLciOsBXVKpjd2WdHAm+li1o=; b=YICtPF4EdWsrlVxs74RlN1v9rATWOqDaNb7VZ2C+ApHuTyHZsL7zjVEvJcKFlgojoK pBYD4OBMvHafrJYex1RInOGkm3LM+ESgBPFAcplHLqzcEmZlDeZ9V3rsm9rWAlXgoV/O HWDQms595bEl69VSZDuGJsmFoK8Qszf6rP26I4WF1IirqCNj7Sr67T1XcbxoZLacdlD5 D+yqZMbMyyh1TSFOtpuChYNwTvaGuW4xhNBpi7DT6YBNaNplf3YfjFb2drM3Y4a26GGD MoDWSRvxW7zy2dBBIUlanMZadP1SQ/LQCWBUD5PQLdcLbEupxYj6aShS+xP/HV9NTuNO yDaA== X-Gm-Message-State: ALoCoQmUfUCdS7z5I/dPeEYZiII2LEcEI1VHM3lk7Gy4RVVZtNR/SLRyz2PlvsyJdMofp59PuRaq X-Received: by 10.180.189.41 with SMTP id gf9mr14034217wic.95.1445169511602; Sun, 18 Oct 2015 04:58:31 -0700 (PDT) Received: from localhost (mobile-access-bceec0-208.dhcp.inet.fi. [188.238.192.208]) by smtp.gmail.com with ESMTPSA id s16sm10691229wik.16.2015.10.18.04.58.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Oct 2015 04:58:31 -0700 (PDT) From: Jani Nikula To: David Bremner , David Bremner , Johannes Schauer , notmuch@notmuchmail.org Subject: Re: [WIP] tests: add test for case insensitive Content-Disposition In-Reply-To: <1444126846-1918-1-git-send-email-david@tethera.net> References: <1443260122-5122-2-git-send-email-jani@nikula.org> <1444126846-1918-1-git-send-email-david@tethera.net> User-Agent: Notmuch/0.21~rc0+2~gb7a0eab (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Sun, 18 Oct 2015 14:58:01 +0300 Message-ID: <87r3kscrsm.fsf@nikula.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 11:58:37 -0000 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