--- /dev/null
+Return-Path: <jani@nikula.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id C7558431FB6\r
+ for <notmuch@notmuchmail.org>; Sat, 18 Oct 2014 02:12:10 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+ tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id pn-ld9NsCCBr for <notmuch@notmuchmail.org>;\r
+ Sat, 18 Oct 2014 02:12:02 -0700 (PDT)\r
+Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com\r
+ [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+ (No client certificate requested)\r
+ by olra.theworths.org (Postfix) with ESMTPS id 524FF431FBC\r
+ for <notmuch@notmuchmail.org>; Sat, 18 Oct 2014 02:12:02 -0700 (PDT)\r
+Received: by mail-wi0-f178.google.com with SMTP id h11so3178340wiw.5\r
+ for <notmuch@notmuchmail.org>; Sat, 18 Oct 2014 02:11:59 -0700 (PDT)\r
+X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;\r
+ d=1e100.net; s=20130820;\r
+ h=x-gm-message-state:from:to:cc:subject:in-reply-to:references\r
+ :user-agent:date:message-id:mime-version:content-type;\r
+ bh=iCmOE9vH003xLPt36pWG76Ge41o0e9DYGVdJe4BsUhs=;\r
+ b=TLVRMXYHGSY8QB8o8S6HzF6cQczxCDCkobBAg78RVcxs5M8aajzP29FJ/vBnxezW+t\r
+ 0WnzNzQ4lhRV8vkkpeiZbibJRC+L/proIxEoGvyiy/2N1UiDUFwvLAfoCPnY/cuKqVE5\r
+ 4sgC+sseHKzKFHKDM9VuJv4xyYm6wfvWIkgLT6+KiOQ3615oZ+bGo0Gs0yoGoa8OqtvH\r
+ n1N9WpGDRg2np9mm4G+pTIDf+SUCFrdHPNjk0asGqMDEk645+Pxux66a299u+w47lS9r\r
+ loHVv5XLOZcf9FfXCFQ0jeVRM/pyy0xJiE4TBoRcfA9ZJ18DiyhbC4HPJ7u3gPrLgf69\r
+ 1dLw==\r
+X-Gm-Message-State:\r
+ ALoCoQlYAN6uqjDgxI3bzs5JaYHDYe1VrECdrm5+QTcBkmxGM1Qf2Bp/n6yxwKvdCw6R22iHO83R\r
+X-Received: by 10.180.14.231 with SMTP id s7mr4975919wic.0.1413623519809;\r
+ Sat, 18 Oct 2014 02:11:59 -0700 (PDT)\r
+Received: from localhost (mobile-internet-5d6ad2-138.dhcp.inet.fi.\r
+ [93.106.210.138])\r
+ by mx.google.com with ESMTPSA id yr9sm4550840wjc.31.2014.10.18.02.11.58\r
+ for <multiple recipients>\r
+ (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\r
+ Sat, 18 Oct 2014 02:11:58 -0700 (PDT)\r
+From: Jani Nikula <jani@nikula.org>\r
+To: sshilovsky@gmail.com, Jameson Graef Rollins <jrollins@finestructure.net>\r
+Subject: Re: Tabulation in multiline headers\r
+In-Reply-To:\r
+ <CAHc2pO21-pahkpyT1jYk2ExWHDGiOO+weovMA-vd8s82LpqK4A@mail.gmail.com>\r
+References:\r
+ <CAHc2pO1QjtqMw9rf0aWGup+Bs_ZpvsZ1bd32H0xiDdzQ_k5GFA@mail.gmail.com>\r
+ <87vbnime8n.fsf@servo.finestructure.net>\r
+ <CAHc2pO21-pahkpyT1jYk2ExWHDGiOO+weovMA-vd8s82LpqK4A@mail.gmail.com>\r
+User-Agent: Notmuch/0.18.1+65~g9f0f30f (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sat, 18 Oct 2014 12:11:56 +0300\r
+Message-ID: <87ppdp3foj.fsf@nikula.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 18 Oct 2014 09:12:10 -0000\r
+\r
+On Sat, 18 Oct 2014, Sergei Shilovsky <sshilovsky@gmail.com> wrote:\r
+>> Hi, Sergei. I'm not clear on where exactly you are seeing a problem\r
+>> with this tab in the subject line. Is it showing up somewhere you think\r
+>> it shouldn't?\r
+>\r
+> It is shown in e.g. `notmuch show` as well as\r
+> 'notmuch_message_get_header(m, "subject")`\r
+>\r
+>> I'm not sure libnotmuch should be doing any scrubbing of the message\r
+>> contents. The emacs UI does seem to replace the tab with a space,\r
+>> though. Maybe other MUAs should be doing the same?\r
+>\r
+> My point is that this tabulation character does not relate to the\r
+> contents of the header (this might be arguable though) and libnotmuch\r
+> should return the contents, not its representation on file system.\r
+\r
+This is folding and unfolding of long header fields in action, described\r
+in [1]. In short, folding happens by inserting CRLF before any WSP, and\r
+unfolding happens by removing any CRLF immediately followed by WSP. The\r
+WSP is preserved unchanged through folding and unfolding. The TAB is not\r
+part of the multiple line representation, it's part of the unfolded\r
+content.\r
+\r
+If my memory serves me right, many problems lead back to an\r
+interpretation of [2] that you could insert extra WSP while folding. Due\r
+to this interpretation, many agents replace the WSP following a CRLF\r
+with a single space while unfolding. And presumably because of this,\r
+buggy folding in a Python email package that replaces WSP by a TAB while\r
+folding went unnoticed. This problem, in turn, has been literally spread\r
+wide by Mailman 2 through its use of said email package. In practice it\r
+follows that a perfectly good message will have folding WSP replaced by\r
+TAB when it gets transmitted through Mailman 2. Again, this is all from\r
+memory, [citation needed] etc.\r
+\r
+Notmuch is not free of a history of its own when it comes to header\r
+unfolding. For historical reasons, we used two header parsers until\r
+recently. One from gmime, and one of our own. After all of the above, it\r
+shouldn't surprise the reader that the parsers treated folding WSP\r
+differently! Our own parser replaced folding WSP with a single space,\r
+while gmime respects the RFC. Starting from 0.18 we only use gmime to\r
+parse headers, which means we're at least consistent, but, by the GIGO\r
+principle, we may see more folding TABs.\r
+\r
+I do not think we should workaround header folding problems in the lib,\r
+and I'm not sure about the cli either. We should consider replacing TABs\r
+with spaces in notmuch-emacs though (I personally use a\r
+notmuch-show-markup-headers-hook that does that).\r
+\r
+HTH,\r
+Jani.\r
+\r
+\r
+[1] https://tools.ietf.org/html/rfc5322#section-2.2.3\r
+[2] https://tools.ietf.org/html/rfc822#section-3.1\r
projects / notmuch-archives.git / commitdiff