From dc15bb11e6ebe535b9eec1cad3ad43752bccdd75 Mon Sep 17 00:00:00 2001 From: Justus Winter <4winter@informatik.uni-hamburg.de> Date: Sun, 23 Jun 2013 15:11:45 +0200 Subject: [PATCH] header continuation issue in notmuch frontend/alot/pythons email module --- 0f/e29a5b9d5843093128764382e749da17de5fd6 | 128 ++++++++++++++++++++++ 1 file changed, 128 insertions(+) create mode 100644 0f/e29a5b9d5843093128764382e749da17de5fd6 diff --git a/0f/e29a5b9d5843093128764382e749da17de5fd6 b/0f/e29a5b9d5843093128764382e749da17de5fd6 new file mode 100644 index 000000000..fa145f860 --- /dev/null +++ b/0f/e29a5b9d5843093128764382e749da17de5fd6 @@ -0,0 +1,128 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 297D3431FB6 + for ; Sun, 23 Jun 2013 06:12:09 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id ibOtpzha0IDc for ; + Sun, 23 Jun 2013 06:11:59 -0700 (PDT) +Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68]) + (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 1527D431FAE + for ; Sun, 23 Jun 2013 06:11:59 -0700 (PDT) +Received: from mail.jade-hamburg.de (mail.jade-hamburg.de [85.183.11.228]) + (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by mail.cryptobitch.de (Postfix) with ESMTPSA id 3FF53691410 + for ; Sun, 23 Jun 2013 15:11:56 +0200 (CEST) +Received: by mail.jade-hamburg.de (Postfix, from userid 401) + id B693BDF2A4; Sun, 23 Jun 2013 15:11:55 +0200 (CEST) +Received: from thinkbox.jade-hamburg.de (unknown + [IPv6:2002:55b7:be4:1:216:d3ff:fe3e:5058]) + (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) + (No client certificate requested) (Authenticated sender: teythoon) + by mail.jade-hamburg.de (Postfix) with ESMTPSA id A7E24DF29F + for ; Sun, 23 Jun 2013 15:11:46 +0200 (CEST) +Received: from teythoon by thinkbox.jade-hamburg.de with local (Exim 4.80) + (envelope-from ) + id 1Uqk54-0000xC-7F + for notmuch@notmuchmail.org; Sun, 23 Jun 2013 15:11:46 +0200 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: quoted-printable +To: notmuch mailing list +Message-ID: <20130623131145.2526.439@thinkbox.jade-hamburg.de> +From: Justus Winter <4winter@informatik.uni-hamburg.de> +User-Agent: alot/0.3.4 +Subject: header continuation issue in notmuch frontend/alot/pythons email + module +Date: Sun, 23 Jun 2013 15:11:45 +0200 +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +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, 23 Jun 2013 13:12:09 -0000 + +Hi, + +I recently had a problem replying to a mail written by Thomas Schwinge +using an oldish notmuch. Not sure if it has been fixed in more recent +versions, but I think notmuch could improve uppon its header +generation (see below). Problematic part of the mail: + +~~~ snip ~~~ +[...] +To: someone@example.org, "line + break" , someoneelse@example.org +User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.4.1 = +(i486-pc-linux-gnu) +[...] +~~~ snap ~~~ + +http://tools.ietf.org/html/rfc2822#section-2.2.3 says: + + Note: Though structured field bodies are defined in such a way that + folding can take place between many of the lexical tokens (and even + within some of the lexical tokens), folding SHOULD be limited to + placing the CRLF at higher-level syntactic breaks. For instance, if + a field body is defined as comma-separated values, it is recommended + that folding occur after the comma separating the structured items in + preference to other places where the field could be folded, even if + it is allowed elsewhere. + +So notmuch "rfc-SHOULD" place the newlines after the comma. + +The rfc goes on: + + The process of moving from this folded multiple-line representation + of a header field to its single line representation is called + "unfolding". Unfolding is accomplished by simply removing any CRLF + that is immediately followed by WSP. Each header field should be + treated in its unfolded form for further syntactic and semantic + evaluation. + +My interpretation is that unfolding simply removes any linebreaks +first, so the value does not contain any newlines. But pythons email +module discriminates quoted and unquoted parts of the value: + +~~~ snip ~~~ +from __future__ import print_function +import email +from email.utils import getaddresses + +m =3D email.message_from_string('''To: "line + break" , line + break ''') +print("m['To'] =3D ", m['To']) +print("getaddresses(m.get_all('To')) =3D ", getaddresses(m.get_all('To'))) +~~~ snap ~~~ + +% python3 test.py +m['To'] =3D "line + break" , line + break +getaddresses(m.get_all('To')) =3D [('line\n break', 'linebreak@example.org= +'), ('line break', 'linebreak@example.org')] + +I believe that is what's preventing me from replying to the message +using alot without sanitizing the To header first. Not really sure who +is wrong or right here... any thoughts? + +Justus -- 2.26.2