0f/e29a5b9d5843093128764382e749da17de5fd6

   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 297D3431FB6\r
   6         for <notmuch@notmuchmail.org>; Sun, 23 Jun 2013 06:12:09 -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 ibOtpzha0IDc for <notmuch@notmuchmail.org>;\r
  16         Sun, 23 Jun 2013 06:11:59 -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 1527D431FAE\r
  21         for <notmuch@notmuchmail.org>; Sun, 23 Jun 2013 06:11:59 -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 3FF53691410\r
  26         for <notmuch@notmuchmail.org>; Sun, 23 Jun 2013 15:11:56 +0200 (CEST)\r
  27 Received: by mail.jade-hamburg.de (Postfix, from userid 401)\r
  28         id B693BDF2A4; Sun, 23 Jun 2013 15:11:55 +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 A7E24DF29F\r
  34         for <notmuch@notmuchmail.org>; Sun, 23 Jun 2013 15:11:46 +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 1Uqk54-0000xC-7F\r
  38         for notmuch@notmuchmail.org; Sun, 23 Jun 2013 15:11:46 +0200\r
  39 Content-Type: text/plain; charset="utf-8"\r
  40 MIME-Version: 1.0\r
  41 Content-Transfer-Encoding: quoted-printable\r
  42 To: notmuch mailing list <notmuch@notmuchmail.org>\r
  43 Message-ID: <20130623131145.2526.439@thinkbox.jade-hamburg.de>\r
  44 From: Justus Winter <4winter@informatik.uni-hamburg.de>\r
  45 User-Agent: alot/0.3.4\r
  46 Subject: header continuation issue in notmuch frontend/alot/pythons email\r
  47         module\r
  48 Date: Sun, 23 Jun 2013 15:11:45 +0200\r
  49 X-BeenThere: notmuch@notmuchmail.org\r
  50 X-Mailman-Version: 2.1.13\r
  51 Precedence: list\r
  52 List-Id: "Use and development of the notmuch mail system."\r
  53         <notmuch.notmuchmail.org>\r
  54 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  55         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  56 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  57 List-Post: <mailto:notmuch@notmuchmail.org>\r
  58 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  59 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  60         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  61 X-List-Received-Date: Sun, 23 Jun 2013 13:12:09 -0000\r
  62 \r
  63 Hi,\r
  64 \r
  65 I recently had a problem replying to a mail written by Thomas Schwinge\r
  66 using an oldish notmuch. Not sure if it has been fixed in more recent\r
  67 versions, but I think notmuch could improve uppon its header\r
  68 generation (see below). Problematic part of the mail:\r
  69 \r
  70 ~~~ snip ~~~\r
  71 [...]\r
  72 To: someone@example.org, "line\r
  73  break" <linebreak@example.org>, someoneelse@example.org\r
  74 User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 =\r
  75 (i486-pc-linux-gnu)\r
  76 [...]\r
  77 ~~~ snap ~~~\r
  78 \r
  79 http://tools.ietf.org/html/rfc2822#section-2.2.3 says:\r
  80 \r
  81    Note: Though structured field bodies are defined in such a way that\r
  82    folding can take place between many of the lexical tokens (and even\r
  83    within some of the lexical tokens), folding SHOULD be limited to\r
  84    placing the CRLF at higher-level syntactic breaks.  For instance, if\r
  85    a field body is defined as comma-separated values, it is recommended\r
  86    that folding occur after the comma separating the structured items in\r
  87    preference to other places where the field could be folded, even if\r
  88    it is allowed elsewhere.\r
  89 \r
  90 So notmuch "rfc-SHOULD" place the newlines after the comma.\r
  91 \r
  92 The rfc goes on:\r
  93 \r
  94    The process of moving from this folded multiple-line representation\r
  95    of a header field to its single line representation is called\r
  96    "unfolding". Unfolding is accomplished by simply removing any CRLF\r
  97    that is immediately followed by WSP.  Each header field should be\r
  98    treated in its unfolded form for further syntactic and semantic\r
  99    evaluation.\r
 100 \r
 101 My interpretation is that unfolding simply removes any linebreaks\r
 102 first, so the value does not contain any newlines. But pythons email\r
 103 module discriminates quoted and unquoted parts of the value:\r
 104 \r
 105 ~~~ snip ~~~\r
 106 from __future__ import print_function\r
 107 import email\r
 108 from email.utils import getaddresses\r
 109 \r
 110 m =3D email.message_from_string('''To: "line\r
 111  break" <linebreak@example.org>, line\r
 112  break <linebreak@example.org>''')\r
 113 print("m['To'] =3D ", m['To'])\r
 114 print("getaddresses(m.get_all('To')) =3D ", getaddresses(m.get_all('To')))\r
 115 ~~~ snap ~~~\r
 116 \r
 117 % python3 test.py\r
 118 m['To'] =3D  "line\r
 119  break" <linebreak@example.org>, line\r
 120  break <linebreak@example.org>\r
 121 getaddresses(m.get_all('To')) =3D  [('line\n break', 'linebreak@example.org=\r
 122 '), ('line break', 'linebreak@example.org')]\r
 123 \r
 124 I believe that is what's preventing me from replying to the message\r
 125 using alot without sanitizing the To header first. Not really sure who\r
 126 is wrong or right here... any thoughts?\r
 127 \r
 128 Justus\r