0e/9f77048737ef5c195440be5fc6bb8580e6b472

   1 Return-Path: <teythoon@jade-hamburg.de>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 16C6C431FBD\r
   6         for <notmuch@notmuchmail.org>; Mon, 24 Jun 2013 01:57:44 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id d+Fd0wHck8ug for <notmuch@notmuchmail.org>;\r
  16         Mon, 24 Jun 2013 01:57:34 -0700 (PDT)\r
  17 Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68])\r
  18         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id 8B5F8431FAF\r
  21         for <notmuch@notmuchmail.org>; Mon, 24 Jun 2013 01:57:34 -0700 (PDT)\r
  22 Received: from mail.jade-hamburg.de (mail.jade-hamburg.de [85.183.11.228])\r
  23         (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))\r
  24         (No client certificate requested)\r
  25         by mail.cryptobitch.de (Postfix) with ESMTPSA id 0509662C358\r
  26         for <notmuch@notmuchmail.org>; Mon, 24 Jun 2013 10:57:17 +0200 (CEST)\r
  27 Received: by mail.jade-hamburg.de (Postfix, from userid 401)\r
  28         id 812A4DF2A5; Mon, 24 Jun 2013 10:57:15 +0200 (CEST)\r
  29 Received: from thinkbox.jade-hamburg.de (unknown\r
  30         [IPv6:2002:55b7:be4:1:216:d3ff:fe3e:5058])\r
  31         (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))\r
  32         (No client certificate requested) (Authenticated sender: teythoon)\r
  33         by mail.jade-hamburg.de (Postfix) with ESMTPSA id 99CADDF29F;\r
  34         Mon, 24 Jun 2013 10:57:11 +0200 (CEST)\r
  35 Received: from teythoon by thinkbox.jade-hamburg.de with local (Exim 4.80)\r
  36         (envelope-from <teythoon@thinkbox.jade-hamburg.de>)\r
  37         id 1Ur2aE-0008Nc-K6; Mon, 24 Jun 2013 10:57:10 +0200\r
  38 Content-Type: text/plain; charset="utf-8"\r
  39 MIME-Version: 1.0\r
  40 Content-Transfer-Encoding: quoted-printable\r
  41 To: Austin Clements <amdragon@MIT.EDU>,\r
  42         thomas schwinge <thomas@codesourcery.com>, \r
  43 From: Justus Winter <4winter@informatik.uni-hamburg.de>\r
  44 In-Reply-To: <20130623165938.GA2214@mit.edu>\r
  45 References: <20130623131145.2526.439@thinkbox.jade-hamburg.de>\r
  46         <20130623165938.GA2214@mit.edu>\r
  47 Message-ID: <20130624085710.31827.41792@thinkbox.jade-hamburg.de>\r
  48 User-Agent: alot/0.3.4\r
  49 Subject: Re: header continuation issue in notmuch frontend/alot/pythons email\r
  50         module\r
  51 Date: Mon, 24 Jun 2013 10:57:10 +0200\r
  52 Cc: notmuch mailing list <notmuch@notmuchmail.org>\r
  53 X-BeenThere: notmuch@notmuchmail.org\r
  54 X-Mailman-Version: 2.1.13\r
  55 Precedence: list\r
  56 List-Id: "Use and development of the notmuch mail system."\r
  57         <notmuch.notmuchmail.org>\r
  58 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  59         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  60 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  61 List-Post: <mailto:notmuch@notmuchmail.org>\r
  62 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  63 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  64         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  65 X-List-Received-Date: Mon, 24 Jun 2013 08:57:44 -0000\r
  66 \r
  67 Quoting Austin Clements (2013-06-23 18:59:39)\r
  68 > Quoth Justus Winter on Jun 23 at  3:11 pm:\r
  69 > > Hi,\r
  70 > > =\r
  71 \r
  72 > > I recently had a problem replying to a mail written by Thomas Schwinge\r
  73 > > using an oldish notmuch. Not sure if it has been fixed in more recent\r
  74 > > versions, but I think notmuch could improve uppon its header\r
  75 > > generation (see below). Problematic part of the mail:\r
  76 > > =\r
  77 \r
  78 > > ~~~ snip ~~~\r
  79 > > [...]\r
  80 > > To: someone@example.org, "line\r
  81 > >  break" <linebreak@example.org>, someoneelse@example.org\r
  82 > > User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.=\r
  83 4.1 (i486-pc-linux-gnu)\r
  84 > > [...]\r
  85 > > ~~~ snap ~~~\r
  86 > > =\r
  87 \r
  88 > > http://tools.ietf.org/html/rfc2822#section-2.2.3 says:\r
  89 > > =\r
  90 \r
  91 > >    Note: Though structured field bodies are defined in such a way that\r
  92 > >    folding can take place between many of the lexical tokens (and even\r
  93 > >    within some of the lexical tokens), folding SHOULD be limited to\r
  94 > >    placing the CRLF at higher-level syntactic breaks.  For instance, if\r
  95 > >    a field body is defined as comma-separated values, it is recommended\r
  96 > >    that folding occur after the comma separating the structured items in\r
  97 > >    preference to other places where the field could be folded, even if\r
  98 > >    it is allowed elsewhere.\r
  99 > > =\r
 100 \r
 101 > > So notmuch "rfc-SHOULD" place the newlines after the comma.\r
 102 > > =\r
 103 \r
 104 > > The rfc goes on:\r
 105 > > =\r
 106 \r
 107 > >    The process of moving from this folded multiple-line representation\r
 108 > >    of a header field to its single line representation is called\r
 109 > >    "unfolding". Unfolding is accomplished by simply removing any CRLF\r
 110 > >    that is immediately followed by WSP.  Each header field should be\r
 111 > >    treated in its unfolded form for further syntactic and semantic\r
 112 > >    evaluation.\r
 113 > > =\r
 114 \r
 115 > > My interpretation is that unfolding simply removes any linebreaks\r
 116 > > first, so the value does not contain any newlines. But pythons email\r
 117 > > module discriminates quoted and unquoted parts of the value:\r
 118 > > =\r
 119 \r
 120 > > ~~~ snip ~~~\r
 121 > > from __future__ import print_function\r
 122 > > import email\r
 123 > > from email.utils import getaddresses\r
 124 > > =\r
 125 \r
 126 > > m =3D email.message_from_string('''To: "line\r
 127 > >  break" <linebreak@example.org>, line\r
 128 > >  break <linebreak@example.org>''')\r
 129 > > print("m['To'] =3D ", m['To'])\r
 130 > > print("getaddresses(m.get_all('To')) =3D ", getaddresses(m.get_all('To'=\r
 131 )))\r
 132 > > ~~~ snap ~~~\r
 133 > > =\r
 134 \r
 135 > > % python3 test.py\r
 136 > > m['To'] =3D  "line\r
 137 > >  break" <linebreak@example.org>, line\r
 138 > >  break <linebreak@example.org>\r
 139 > > getaddresses(m.get_all('To')) =3D  [('line\n break', 'linebreak@example=\r
 140 .org'), ('line break', 'linebreak@example.org')]\r
 141 > > =\r
 142 \r
 143 > > I believe that is what's preventing me from replying to the message\r
 144 > > using alot without sanitizing the To header first. Not really sure who\r
 145 > > is wrong or right here... any thoughts?\r
 146 > =\r
 147 \r
 148 > There are at least two bugs here.  Regardless of what we RFC-should\r
 149 > do, that folding *is* permitted by RFC2822, since quoted\r
 150 > strings can contain folding whitespace:\r
 151 > =\r
 152 \r
 153 >   http://tools.ietf.org/html/rfc2822#section-3.2.5\r
 154 > =\r
 155 \r
 156 > For completeness, the full derivation for this "To" header is:\r
 157 > =\r
 158 \r
 159 > to              =3D       "To:" address-list CRLF\r
 160 > address-list    =3D       (address *("," address)) / obs-addr-list\r
 161 > address         =3D       mailbox / group\r
 162 > mailbox         =3D       name-addr / addr-spec\r
 163 > name-addr       =3D       [display-name] angle-addr\r
 164 > display-name    =3D       phrase\r
 165 > phrase          =3D       1*word / obs-phrase\r
 166 > word            =3D       atom / quoted-string\r
 167 > quoted-string   =3D       [CFWS]\r
 168 >                         DQUOTE *([FWS] qcontent) [FWS] DQUOTE\r
 169 >                         [CFWS]\r
 170 > =\r
 171 \r
 172 > Do you happen to know how the strangely folded "to" header was\r
 173 > produced for this message?\r
 174 \r
 175 No, but Thomas might. Thomas, the problematic message is\r
 176 id:877ghpqckb.fsf@kepler.schwinge.homeip.net\r
 177 \r
 178 >  In notmuch-emacs, a user can put whatever\r
 179 > they want in a message-mode buffer's headers and mm will dutifully\r
 180 > pass it on to their MTA.  We could validate it, but that's a slippery\r
 181 > slope and I would hope that the MTA itself is validating it (and\r
 182 > probably more thoroughly than we could).\r
 183 > =\r
 184 \r
 185 > That said, the first bug here is in Python.  As I mentioned above,\r
 186 > foldable whitespace is allowed in quoted strings.  In fact, though the\r
 187 > standard is rather long-winded about whitespace, if you dig into the\r
 188 > grammar, you'll find that *all whitespace can be folded* (except in\r
 189 > the obsolete grammar, which allowed whitespace between the header name\r
 190 > and the colon, which obviously can't be folded).  I'm not sure what\r
 191 > Python is doing, but I bet it's going to a lot of effort to\r
 192 > mis-implement something very simple.\r
 193 \r
 194 Yes, I'm glad you came to the same conclusion.\r
 195 \r
 196 > There also appears to be a bug in the notmuch CLI's reply command\r
 197 > where it omits addresses that were folded in the original message.  I\r
 198 > don't know if alot uses the CLI's reply command, so this may or may\r
 199 > not be related to your specific issue.  I haven't dug into this yet,\r
 200 > other than to confirm that it's the CLI's fault and not\r
 201 > notmuch-emacs's.\r
 202 \r
 203 No, alot does not use notmuchs reply command.\r
 204 \r
 205 Thanks,\r
 206 Justus\r