From: Jameson Graef Rollins Date: Thu, 8 Mar 2012 21:32:44 +0000 (+1600) Subject: Re: Parsing regression with gmime-2.6? X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=0b1a0593e10fae277799bca97814882f47fd6818;p=notmuch-archives.git Re: Parsing regression with gmime-2.6? --- diff --git a/0f/99a5897f28c520da767e7d6a6f65a23a8c025f b/0f/99a5897f28c520da767e7d6a6f65a23a8c025f new file mode 100644 index 000000000..7fffd1af1 --- /dev/null +++ b/0f/99a5897f28c520da767e7d6a6f65a23a8c025f @@ -0,0 +1,131 @@ +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 BE529431FB6 + for ; Thu, 8 Mar 2012 13:33:11 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -2.29 +X-Spam-Level: +X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_MED=-2.3, T_MIME_NO_TEXT=0.01] 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 4tJfoOv3XNYZ for ; + Thu, 8 Mar 2012 13:33:11 -0800 (PST) +Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu + [131.215.239.19]) + by olra.theworths.org (Postfix) with ESMTP id ED61A431FAE + for ; Thu, 8 Mar 2012 13:33:10 -0800 (PST) +Received: from earth-doxen.imss.caltech.edu (localhost [127.0.0.1]) + by earth-doxen-postvirus (Postfix) with ESMTP id 6FFC066E01EE; + Thu, 8 Mar 2012 13:33:10 -0800 (PST) +X-Spam-Scanned: at Caltech-IMSS on earth-doxen by amavisd-new +Received: from finestructure.net (DHCP-123-180.caltech.edu [131.215.123.180]) + (Authenticated sender: jrollins) + by earth-doxen-submit (Postfix) with ESMTP id 292F566E00DA; + Thu, 8 Mar 2012 13:32:47 -0800 (PST) +Received: by finestructure.net (Postfix, from userid 1000) + id CAA149DE; Thu, 8 Mar 2012 13:32:46 -0800 (PST) +From: Jameson Graef Rollins +To: Daniel Kahn Gillmor , + David Bremner , + Austin Clements , notmuch@notmuchmail.org +Subject: Re: Parsing regression with gmime-2.6? +In-Reply-To: <87vcme3kf6.fsf@pip.fifthhorseman.net> +References: <87d38w2e7h.fsf@zancas.localnet> + <1331058417-13776-1-git-send-email-amdragon@mit.edu> + <87wr6xmlml.fsf@zancas.localnet> + <87vcme3kf6.fsf@pip.fifthhorseman.net> +User-Agent: Notmuch/0.11.1+266~gadb05cc (http://notmuchmail.org) Emacs/23.3.1 + (x86_64-pc-linux-gnu) +Date: Thu, 08 Mar 2012 13:32:44 -0800 +Message-ID: <874ntybwxv.fsf@servo.finestructure.net> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha256; protocol="application/pgp-signature" +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: Thu, 08 Mar 2012 21:33:11 -0000 + +--=-=-= +Content-Transfer-Encoding: quoted-printable + +On Thu, 08 Mar 2012 15:30:21 -0500, Daniel Kahn Gillmor wrote: +> This does seem to be a regression in gmime 2.6. I've reported the bug +> upstream, along with a simplified (non-notmuch) demonstration: +>=20 +> https://bugzilla.gnome.org/show_bug.cgi?id=3D671680 +>=20 +> We'll see what gmime's upstream has to say about it. + +Thanks so much for following up on this, Daniel. + +> As a devil's advocate, i could argue that a message in a maildir that +> starts with a "From " line isn't a proper e-mail message in the first +> place, and therefore gmime 2.6 is being more rigorously correct about +> what it accepts. In particular, if a user were to place a multi-message +> mbox file in their notmuch message store, i think that notmuch linked +> against 2.4 would happily index only the first message of it, and the +> rest of the message would be "hidden", whereas gmime 2.6 allows us to +> detect these failures and avoid indexing them directly. + +I actually agree with this position. mbox files are not proper email +messages, so if gmime does not explicitly support parsing them then we +really can't expect it to parse them. We *can* expect gmime to return +some sort of proper error message/return code/etc and not fail in a bad +way, but beyond that I think the burden is on us. + +> That said, i understand that this is probably not an entirely rare +> situation, and i lean toward the idea that gmime 2.4's behavior was +> actually the Right Thing. Also, I haven't been able to find any +> explicit documentation to indicate that the behavior change was +> a deliberate one. + +And I think I don't agree with this one: I not think that handling mbox +files in the way you've outlined above is the Right Thing. Only +partially parsing an mbox file, by indexing only the first message for +instance, seems like a bad solution to me, and one that's likely to lead +to a lot of confusion (e.g. "where are the rest of the messages that +were in my mbox?"). + +If notmuch encounters an mbox file in the store it should just skip the +message and continue, while indicating that it is skipping the message +because it's not a proper email message, as it does with other non-email +files. + +jamie. + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.11 (GNU/Linux) + +iQIcBAEBCAAGBQJPWSV8AAoJEO00zqvie6q86N0P/RT0X702Jhcnl+53tFyUjFUH +UkAH+Myqp+6di7YVvoFoDrATmXVGj4S0Z2QeO+MEjSbfmuY2Xx9V4V2Sh5QQ08ZW +TeZPQ8qYkWI0FQsG6nQjZhAbxf6QEJ0DRBdDYsuNJK1a6FwayE2bqDvvSw9xf7fE +D/C0Dleucr3L10utZuSmxNcJLB/flpPI3A6GcUgwf81OF5N2paqsKUW1rZdYtHkJ +y8Go7rHMmsaw82ABQfG/eoEKTotQNGgNpciWsOub7/CT/PC9yF+yQBr44VsVIhTn +w0tYpiy1pNFQ1eWLDe1QWDW+dv1HNYDqBeThURN3A90IgV49IVEjfJHLMaxtSKuh +KCgniEOB0V40LY01Bt3ot1yHcMbY58slH15NFbVINQifs2egtRuESwBgeO+EcbGU +sfqP3nrAS2aDD/bhnEeQlEidGD4xsXLVk1bT7pj+2oSImj7rXd9ph/XJCrX0KCyI +3HtOkAnsxFer2x6UYAaLQ3D4CDKppwvrcwMH1pHckR6J+Foz5GC7Eq3AxGj9fUGJ ++SAsRFucJ50LnumziD3nQf+n+PBLfsp22ZVahT0waJJaxIiqMGdko/8mI9A4CSlA +uflptkIfkiSanbt7xkk+MI7MGonvRfT4m1G/5gHqdwhsihoeHI6fIfiTXq30ozBg +vCgiuNNbMG6lhfXq6o9X +=Flnt +-----END PGP SIGNATURE----- +--=-=-=--