48/a41286d2421c031315e8f9f4f7b96d424a29d5

   1 Return-Path: <amdragon@mit.edu>\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 DEBFA431FBD\r
   6         for <notmuch@notmuchmail.org>; Sun, 23 Jun 2013 09:59:55 -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.7\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_LOW=-0.7] 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 jC52PBMVKejM for <notmuch@notmuchmail.org>;\r
  16         Sun, 23 Jun 2013 09:59:46 -0700 (PDT)\r
  17 Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu\r
  18         [18.7.68.34])\r
  19         by olra.theworths.org (Postfix) with ESMTP id AF04A431FAE\r
  20         for <notmuch@notmuchmail.org>; Sun, 23 Jun 2013 09:59:46 -0700 (PDT)\r
  21 X-AuditID: 12074422-b7ef78e000000935-85-51c72981074c\r
  22 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36])\r
  23         by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id 8F.FA.02357.18927C15; Sun, 23 Jun 2013 12:59:45 -0400 (EDT)\r
  25 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])\r
  26         by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r5NGxhZg030538; \r
  27         Sun, 23 Jun 2013 12:59:44 -0400\r
  28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])\r
  29         (authenticated bits=0)\r
  30         (User authenticated as amdragon@ATHENA.MIT.EDU)\r
  31         by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r5NGxeMv030643\r
  32         (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT);\r
  33         Sun, 23 Jun 2013 12:59:42 -0400\r
  34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.80)\r
  35         (envelope-from <amdragon@mit.edu>)\r
  36         id 1Uqndb-0004Kv-Oo; Sun, 23 Jun 2013 12:59:40 -0400\r
  37 Date: Sun, 23 Jun 2013 12:59:39 -0400\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Justus Winter <4winter@informatik.uni-hamburg.de>\r
  40 Subject: Re: header continuation issue in notmuch frontend/alot/pythons email\r
  41         module\r
  42 Message-ID: <20130623165938.GA2214@mit.edu>\r
  43 References: <20130623131145.2526.439@thinkbox.jade-hamburg.de>\r
  44 MIME-Version: 1.0\r
  45 Content-Type: text/plain; charset=us-ascii\r
  46 Content-Disposition: inline\r
  47 In-Reply-To: <20130623131145.2526.439@thinkbox.jade-hamburg.de>\r
  48 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  49 X-Brightmail-Tracker:\r
  50  H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IRYrdT0W3UPB5o0LJH3GJ26w8mi+s3ZzI7\r
  51         MHlMPH+azePZqlvMAUxRXDYpqTmZZalF+nYJXBmH+26wF/xTqdi8YQ9bA+NdmS5GTg4JAROJ\r
  52         /q7ZbBC2mMSFe+uBbC4OIYF9jBJfX3xjgnA2MkrMXLEJyjnNJNF54wQ7hLOEUWLT/JVg/SwC\r
  53         qhJPj91nBLHZBDQktu1fDmaLCJhKbHjwgB3EZhYwkri/YzpzFyMHh7BAmMTsTnuQMK+AtsSZ\r
  54         MzvASoQE7CTWftzLBhEXlDg58wkLRKuWxI1/L5lAWpkFpCWW/+MACXMK2Es8v9/KCmKLCqhI\r
  55         TDm5jW0Co9AsJN2zkHTPQuhewMi8ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdULzezRC81pXQT\r
  56         IzisXZR2MP48qHSIUYCDUYmHN1P1WKAQa2JZcWXuIUZJDiYlUd6zUscDhfiS8lMqMxKLM+KL\r
  57         SnNSiw8xSnAwK4nwbrgGVM6bklhZlVqUD5OS5mBREucVu7UzUEggPbEkNTs1tSC1CCYrw8Gh\r
  58         JMFrqQE0VLAoNT21Ii0zpwQhzcTBCTKcB2j4GnWgGt7igsTc4sx0iPwpRl2OyWe3vGcUYsnL\r
  59         z0uVEuddrAZUJABSlFGaBzcHlo5eMYoDvSXMuwFkFA8wlcFNegW0hAloyZ7Vh0CWlCQipKQa\r
  60         GJs3HSk6037wGUfJAp1DjdMTuO7ZqRlN5Thmv5HpYuz3JXwpOe0eblUTNyYumnVHc52RI+PJ\r
  61         tQZxncq/2L/9WDb5Yq+V+fFlV7gfxLYsVlCLzNrhl1kUUriojv/x2xu3Lqny62Q0WC4Sv3C8\r
  62         /IXYbdP3JVnpQkvvf4++dHSLJesak6OMKy4zXVFiKc5INNRiLipOBADxp15XIgMAAA==\r
  63 Cc: notmuch mailing list <notmuch@notmuchmail.org>\r
  64 X-BeenThere: notmuch@notmuchmail.org\r
  65 X-Mailman-Version: 2.1.13\r
  66 Precedence: list\r
  67 List-Id: "Use and development of the notmuch mail system."\r
  68         <notmuch.notmuchmail.org>\r
  69 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  70         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  71 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  72 List-Post: <mailto:notmuch@notmuchmail.org>\r
  73 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  74 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  75         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  76 X-List-Received-Date: Sun, 23 Jun 2013 16:59:56 -0000\r
  77 \r
  78 Quoth Justus Winter on Jun 23 at  3:11 pm:\r
  79 > Hi,\r
  80 > \r
  81 > I recently had a problem replying to a mail written by Thomas Schwinge\r
  82 > using an oldish notmuch. Not sure if it has been fixed in more recent\r
  83 > versions, but I think notmuch could improve uppon its header\r
  84 > generation (see below). Problematic part of the mail:\r
  85 > \r
  86 > ~~~ snip ~~~\r
  87 > [...]\r
  88 > To: someone@example.org, "line\r
  89 >  break" <linebreak@example.org>, someoneelse@example.org\r
  90 > User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 (i486-pc-linux-gnu)\r
  91 > [...]\r
  92 > ~~~ snap ~~~\r
  93 > \r
  94 > http://tools.ietf.org/html/rfc2822#section-2.2.3 says:\r
  95 > \r
  96 >    Note: Though structured field bodies are defined in such a way that\r
  97 >    folding can take place between many of the lexical tokens (and even\r
  98 >    within some of the lexical tokens), folding SHOULD be limited to\r
  99 >    placing the CRLF at higher-level syntactic breaks.  For instance, if\r
 100 >    a field body is defined as comma-separated values, it is recommended\r
 101 >    that folding occur after the comma separating the structured items in\r
 102 >    preference to other places where the field could be folded, even if\r
 103 >    it is allowed elsewhere.\r
 104 > \r
 105 > So notmuch "rfc-SHOULD" place the newlines after the comma.\r
 106 > \r
 107 > The rfc goes on:\r
 108 > \r
 109 >    The process of moving from this folded multiple-line representation\r
 110 >    of a header field to its single line representation is called\r
 111 >    "unfolding". Unfolding is accomplished by simply removing any CRLF\r
 112 >    that is immediately followed by WSP.  Each header field should be\r
 113 >    treated in its unfolded form for further syntactic and semantic\r
 114 >    evaluation.\r
 115 > \r
 116 > My interpretation is that unfolding simply removes any linebreaks\r
 117 > first, so the value does not contain any newlines. But pythons email\r
 118 > module discriminates quoted and unquoted parts of the value:\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 > m = email.message_from_string('''To: "line\r
 126 >  break" <linebreak@example.org>, line\r
 127 >  break <linebreak@example.org>''')\r
 128 > print("m['To'] = ", m['To'])\r
 129 > print("getaddresses(m.get_all('To')) = ", getaddresses(m.get_all('To')))\r
 130 > ~~~ snap ~~~\r
 131 > \r
 132 > % python3 test.py\r
 133 > m['To'] =  "line\r
 134 >  break" <linebreak@example.org>, line\r
 135 >  break <linebreak@example.org>\r
 136 > getaddresses(m.get_all('To')) =  [('line\n break', 'linebreak@example.org'), ('line break', 'linebreak@example.org')]\r
 137 > \r
 138 > I believe that is what's preventing me from replying to the message\r
 139 > using alot without sanitizing the To header first. Not really sure who\r
 140 > is wrong or right here... any thoughts?\r
 141 \r
 142 There are at least two bugs here.  Regardless of what we RFC-should\r
 143 do, that folding *is* permitted by RFC2822, since quoted\r
 144 strings can contain folding whitespace:\r
 145 \r
 146   http://tools.ietf.org/html/rfc2822#section-3.2.5\r
 147 \r
 148 For completeness, the full derivation for this "To" header is:\r
 149 \r
 150 to              =       "To:" address-list CRLF\r
 151 address-list    =       (address *("," address)) / obs-addr-list\r
 152 address         =       mailbox / group\r
 153 mailbox         =       name-addr / addr-spec\r
 154 name-addr       =       [display-name] angle-addr\r
 155 display-name    =       phrase\r
 156 phrase          =       1*word / obs-phrase\r
 157 word            =       atom / quoted-string\r
 158 quoted-string   =       [CFWS]\r
 159                         DQUOTE *([FWS] qcontent) [FWS] DQUOTE\r
 160                         [CFWS]\r
 161 \r
 162 Do you happen to know how the strangely folded "to" header was\r
 163 produced for this message?  In notmuch-emacs, a user can put whatever\r
 164 they want in a message-mode buffer's headers and mm will dutifully\r
 165 pass it on to their MTA.  We could validate it, but that's a slippery\r
 166 slope and I would hope that the MTA itself is validating it (and\r
 167 probably more thoroughly than we could).\r
 168 \r
 169 That said, the first bug here is in Python.  As I mentioned above,\r
 170 foldable whitespace is allowed in quoted strings.  In fact, though the\r
 171 standard is rather long-winded about whitespace, if you dig into the\r
 172 grammar, you'll find that *all whitespace can be folded* (except in\r
 173 the obsolete grammar, which allowed whitespace between the header name\r
 174 and the colon, which obviously can't be folded).  I'm not sure what\r
 175 Python is doing, but I bet it's going to a lot of effort to\r
 176 mis-implement something very simple.\r
 177 \r
 178 There also appears to be a bug in the notmuch CLI's reply command\r
 179 where it omits addresses that were folded in the original message.  I\r
 180 don't know if alot uses the CLI's reply command, so this may or may\r
 181 not be related to your specific issue.  I haven't dug into this yet,\r
 182 other than to confirm that it's the CLI's fault and not\r
 183 notmuch-emacs's.\r
 184 \r
 185 > Justus\r