[mel-base-devel] mel.mime:parts not working properly for rfc 2822 (reading from a file)

[Fred Gibson]

Hi Jochen,

Your fix works great for text/plain and multipart/alternative where
the same body tag is used throughout the message.  The problem happens
when you have a multipart/mixed structure where there is more than one
boundary in the message.  So what I did in the rewrite of
read-multipart-body-1 (RMB1) is in the case of a mixed type, read just
beyond the first boundary which can be ignored, then recurse on RMB1
again to deal with only the boundaries that matter by reading each one
in at the top of a message section and then sending it to scan rather
than trying to use the boundary identified in the message header, thus
allowing for many boundaries.   I realize it is pretty brute force,
but it works flawlessly so far.  It made more sense to me to deal with
the multiple tag issue in RMB1.  Is there a more elegant solution to
this?  (I've included a sample shortened version of the mixed
structure below so you can see the varying boundary issue. This is the
case for any mail with an attachment I think.)

My best,

Fred

Partial sample mutlipart/mixed type:

MIME-Version: 1.0
Received: by 10.140.136.4 with HTTP; Mon, 21 Dec 2009 12:06:02 -0800 (PST)
Date: Mon, 21 Dec 2009 12:06:02 -0800
Delivered-To: frederick at gibson-design.com
Message-ID: <306ae50912211206u58f1b598sf2fa7f561ec9cbb1 at mail.gmail.com>
Subject: Architectural Invoice + Brian
From: "Frederick Gibson, Architect" <frederick at gibson-design.com>
To: ...
Content-Type: multipart/mixed; boundary=000e0cd1465866ab58047b429eca

--000e0cd1465866ab58047b429eca
Content-Type: multipart/alternative; boundary=000e0cd1465866ab51047b429ec8

--000e0cd1465866ab51047b429ec8
Content-Type: text/plain; charset=ISO-8859-1

Hi Dave & Carol,

I just had an upbeat talk with Brian about the issue of which contractor
...

415.227.1684 |tel|  888 671-4958 |fax|

(c)2009 http://www.gibson-design.com

--000e0cd1465866ab51047b429ec8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi Dave & Carol,<br><br>I just had an upbeat talk with Brian about the =
...

p://www.gibson-design.com">http://www.gibson-design.com</a><br>
<br><br>

--000e0cd1465866ab51047b429ec8--
--000e0cd1465866ab58047b429eca
Content-Type: application/pdf; name="Invoice-2290.pdf"
Content-Disposition: attachment; filename="Invoice-2290.pdf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_g3hoa5eb0

JVBERi0xLjQNJeLjz9MNCjYgMCBvYmogPDwvTGluZWFyaXplZCAxL0wgMjc1MDUvTyA4L0UgMjM0
...
emUgNj4+DQpzdGFydHhyZWYNCjExNg0KJSVFT0YNCg==
--000e0cd1465866ab58047b429eca--




On Sat, Jan 23, 2010 at 5:04 AM, Jochen Schmidt <js at crispylogics.com> wrote:
>
> Am 23.01.2010 um 10:44 schrieb Fred Gibson:
>
>> I had to rewrite a good portion of read-multipart-body-1 to get the
>> parts to parse correctly.  I've tested this with text/plain,
>> multipart/alternative and multipart/mixed, and all parsed correctly.
>> Here is the diff from my git commit:
>
> Sorry for the inconvenience, but the bug was actually not in READ-MULTIPART-BODY-1 but in SCAN-FORWARD-BOUNDARY.
> It didn't expect a boundary directly as the first line of the message body - so the top boundary was actually skipped.
> If you add this clause to the start of the tagbody in SCAN-FORWARD-BOUNDARY, it works again.
>
> init (let ((c (peek)))
>                     (if (char= c #\-)
>                       (go possible-boundary)
>                       (go start)))
>
> Fix is in repository soon (with some other stuff).
>
> ciao,
> Jochen
>
> --
> Jochen Schmidt
> CRISPYLOGICS
> Uhlandstr. 9, 90408 Nuremberg
>
> Fon +49 (0)911 517 999 82
> Fax +49 (0)911 517 999 83
>
> mailto:(format nil "~(~36r@~36r.~36r~)" 870180 1680085828711918828 16438) http://www.crispylogics.com
>
>



-- 
Fred Gibson

Founder / Software Developer
http://www.streamfocus.com

(c)2010 Organon Technologies LLC