From dc320bbbe9cafcfceaa7422dcf1362518780dd07 Mon Sep 17 00:00:00 2001 From: Olivier Berger Date: Tue, 25 Sep 2012 12:52:22 +0200 Subject: [PATCH] Re: bug related to ical --- 20/21b62635e2c8b37e9dff22b5270b4ab493162f | 136 ++++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 20/21b62635e2c8b37e9dff22b5270b4ab493162f diff --git a/20/21b62635e2c8b37e9dff22b5270b4ab493162f b/20/21b62635e2c8b37e9dff22b5270b4ab493162f new file mode 100644 index 000000000..ae7c7b171 --- /dev/null +++ b/20/21b62635e2c8b37e9dff22b5270b4ab493162f @@ -0,0 +1,136 @@ +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 44B01431FC7 + for ; Tue, 25 Sep 2012 03:52:38 -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 BjN5aJdOL0Xb for ; + Tue, 25 Sep 2012 03:52:37 -0700 (PDT) +Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) + (using TLSv1 with cipher AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id D6A4D431FAF + for ; Tue, 25 Sep 2012 03:52:36 -0700 (PDT) +Received: from list by plane.gmane.org with local (Exim 4.69) + (envelope-from ) id 1TGSko-0004Lp-Gj + for notmuch@notmuchmail.org; Tue, 25 Sep 2012 12:52:38 +0200 +Received: from bauxite.int-evry.fr ([157.159.110.64]) + by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) + id 1AlnuQ-0007hv-00 + for ; Tue, 25 Sep 2012 12:52:38 +0200 +Received: from olivier.berger by bauxite.int-evry.fr with local (Gmexim 0.1 + (Debian)) id 1AlnuQ-0007hv-00 + for ; Tue, 25 Sep 2012 12:52:38 +0200 +X-Injected-Via-Gmane: http://gmane.org/ +To: notmuch@notmuchmail.org +From: Olivier Berger +Subject: Re: bug related to ical +Date: Tue, 25 Sep 2012 12:52:22 +0200 +Lines: 76 +Message-ID: <871uhq2x3t.fsf@inf-8657.int-evry.fr> +References: +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +X-Complaints-To: usenet@ger.gmane.org +X-Gmane-NNTP-Posting-Host: bauxite.int-evry.fr +User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) +Cancel-Lock: sha1:jqLWXB0qWmp7zzF350JB5z+amos= +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: Tue, 25 Sep 2012 10:52:38 -0000 + +Hi. + +I didn't seem to find any followup. + +I'm experiencing a similar problem... Anyone with hints on how to solve +this ? + +Thanks in advance. + +Best regards, + +Robert Horn writes: + +> I've noticed a problem related to handling of ical attachments. I'm +> using Notmuch 0.13 on Emacs 23.3.1. I've done some basic +> troubleshooting. +> +> The problem arises with emails from Concur that include an ical +> attachment being viewed with the notmuch message viewer. The problems +> are: +> 1. When opening the email there is sometimes the following mesage and +> error in Emacs message buffer: +> Converting icalendar...done +> notmuch-show-insert-bodypart-internal: Wrong type argument: stringp, nil +> +> 2. Some (not all) of the view commands fail, e.g. "v", "V", "w". +> Others work, like "m", and "q". +> +> 3. Examination of the /tmp directory shows notmuch-ical temp files being +> created but they are zero length. +> +> This is related to the ical attachment. When I editted one of the emails to +> remove the attachment, the problem went away. I suspect it is related +> to the attachments being base64 encoded. The header of the mime +> attachment shows: +> +> Content-Type: application/octet-stream; +> name="ConcurCalendarEntry.ics" +> Content-Transfer-Encoding: base64 +> Content-Disposition: attachment; +> filename="ConcurCalendarEntry.ics" +> +> The encoding is correct. The attachment decodes and looks right. With +> some details obscured the attachment contains: +> +> BEGIN:VCALENDAR +> VERSION:2.0 +> METHOD:PUBLISH +> BEGIN:VEVENT +> DTSTART:properly-formatted +> DTEND:properly-formatted +> DTSTAMP:properly-formatted +> LOCATION: +> SUMMARY:Concur Travel Itinerary +> DESCRIPTION:Lots of stuff +> with about 80 lines of description. All indented properly. +> UID:properly-formatted +> PRIORITY:3 +> TRANSP:TRANSPARENT +> END:VEVENT +> END:VCALENDAR +> +> I can live without the ics files, so fixing this is not a priority for +> me. If there is someone interested in figuring this out, I've saved an +> email and can answer questions. I got lost trying to follow the lisp +> code paths for attachments, so I'm not sure whether it's the text or the +> base64 that is being handed off to icalendar. +> +> R Horn +> rjhorn@alum.mit.edu + +-- +Olivier BERGER +http://www-public.it-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 +Ingenieur Recherche - Dept INF +Institut Mines-Telecom, Telecom SudParis, Evry (France) + -- 2.26.2