Inbound message missing attachments

[bamnptow]

I am using the beta2 release and am having trouble with some inbound messages with attachments. Here are the particulars:

- The inbox window shows that there are attachments.
- If I look at the message source, I see the details of the attachments -- it is a multipart mime message, and the attachments are the additional parts.
- When I open the message in Outlook Express, TYhunderbird, and IlohaMail, I can see and open the attachments.
- When I open the message in Roundcube, I cannot see the attachments.
- The examples I have so far are sent using the Blat smtp mailer, but I don't have enough examples to know if it is really only Blat causing the issue.
- Interestingly, if I use Roundcube to forward the message to myself, the attachments are visible and can be opened from within Roundcube.

Any ideas?

Here is part of the message source from the most recent example:

Date: Thu, 17 Aug 2006 21:22:30 -0400
From: my@email.address
To: my@email.address
X-Mailer: Blat v2.5.0 w/GSS encryption, a Win32 SMTP/NNTP mailer http://www.blat.net
Message-ID: <01c6c264$Blat.v2.5.0$c5fbfac2$1f2c@10.0.0.11>
Subject: Daily Log Files
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="=_BlatBoundary-fOdaaeCDKOQlMtRzEnNFo"

This is a multi-part message in MIME format.

--=_BlatBoundary-fOdaaeCDKOQlMtRzEnNFo
Content-description: Mail message body
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain; charset=ISO-8859-1

Today's log files are attached.

--=_BlatBoundary-fOdaaeCDKOQlMtRzEnNFo
Content-Type: application/octet-stream;
name="mercore.log"
Content-Disposition: ATTACHMENT;
filename="mercore.log"
Content-Transfer-Encoding: BASE64

TyAyMDA2MDcwOCAxNzI0IE1HMDAwMEMyIHN0ZXZlQHJhaWEudX MgICAgICAgICAgICAgICAg
ICBqb2huQGF0aGFzLmNvbSAgICAgICAgICAgICAgICAgODU5DQ pJIDIwMDYwNzA4IDE3NDMg

etc.

[bamnptow]

I found a message that is not generated by Blat that works the same way.

The Mercury/32 mailing list, which is generated by Listserv, sends its daily digest with the day's posts attached. These attachments also do not show up in the beta2 of Roundcube.

If I look at the message source in Roundcube, I can see them, but they do not appear if I just try to open the message from the Inbox normally.

The attachments work fine in Thunderbird, Outlook Express, and Ilohamail.

Given this, it seems unlikely that Blat is the cause of my problem.

[infoeon]

I have the same issue but with emails generated from Juno. Here is some sample data:

Return-Path: <XXXX@juno.com>
Received: from m9.nyc.untd.com ([127.0.0.1])
by server.XXXX.com
with XXXX ; Wed, 30 Aug 2006 19:29:56 -0500
Received: from 64.136.22.72 ([64.136.22.72] helo=m9.nyc.untd.com) by
spam.XXXX.com; 30 Aug 2006 19:29:54 -0500
Received: from m9.nyc.untd.com (localhost [127.0.0.1])
by m9.nyc.untd.com with SMTP id XXXX
for <XXXX@XXXX.com> (sender <XXXX@juno.com>);
Wed, 30 Aug 2006 17:31:07 -0700 (PDT)
X-UNTD-OriginStamp: XXXX==
Received: (from XXXX@juno.com)
by m9.nyc.untd.com (jqueuemail) id XXXXXXXX; Wed, 30 Aug 2006 17:30:22 PDT
To: XXXX@XXXX.com
Cc: XXXX@XXXX.com
Date: Wed, 30 Aug 2006 19:04:27 -0500
Subject: Fw: Treadmill dance
Message-ID: <20060830.190428.3516.4.XXXX@juno.com>
X-Mailer: Juno 5.0.33
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=--__JNP_000_2426.1280.6e14
From: XXXX <XXXX@juno.com>
X-ContentStamp: 1:1:493504430
X-UNTD-Peer-Info: 127.0.0.1|localhost|m9.nyc.untd.com|XXXX@juno.com
X-Assp-Received-SPF: pass (spam.XXXX.com: domain of XXXX@juno.com
designates 64.136.22.72 as permitted sender) client-ip=64.136.22.72;
envelope-from= XXXX@juno.com; helo=m9.nyc.untd.com;

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

----__JNP_000_2426.1280.6e14
Content-Type: multipart/alternative; boundary=--__JNP_000_4817.464d.5164

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

----__JNP_000_4817.464d.5164
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


This is a fun workout!
----__JNP_000_4817.464d.5164
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;</SPAN></=
FONT><FONT=20
face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial"> This is&nbsp;a =
fun=20
workout!</SPAN></FONT><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">&nbsp;</SPAN></=
FONT></DIV>

<P><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"></SPAN></FONT>&nbsp;</P>
<DIV>&nbsp;</DIV></BODY></HTML>

----__JNP_000_4817.464d.5164--

----__JNP_000_2426.1280.6e14
Content-Type: video/x-ms-wmv; name="some file.wmv"
Content-Transfer-Encoding: base64

<ENCODED DATA HERE>

----__JNP_000_2426.1280.6e14--

[ipfreaks]

i have the problem, too.
roundcube shows the mail i've sent with an attachment without the attachment-icon. the mail has the same size as the attachment. i could not verify which attachment sizes are the the problem... sometimes little attachments has the problem, sometimes only big attachments...

anyone an idea?
thanks!!
ipfreaks

version: 0.1-beta2 and the same issue with SVN 327

[zman818]

Based on other posts here, it would appear the Beta 2 is having some problems handling multipart attachments properly. Hopefully the developers will identify and address the issue.

I had severe problems with Beta 2 mangling zip and other binary attachments that were properly opened by RC Beta 1 and SquirrelMail.

[Guillermolococo]

Hello,

I have the same problem. Our clients (about 150 clients) have problems opening PDF files. I tried to fix but I cant. I dont know where is the problem.

" Houston, we have a problem ! "

If some one have any idea, please, post it.
Thanks soo much !

[desertadmin]

This was noticed by my 800+ clients Is there any alternative. I am really trying to convince everyone that roundcube is the way. And I will be toughing it alot more but is there any one out there with an answer to this issue?

Just curious. Thanks for everyone's help and comments on my other posts of odd questiosn that I have had. This is a very active community.

-Cheers
..:esertAdmin::..

[syc]

I've also run into this problem and I started to debug the application.

I looked into the mimeDecode calls that were being recursively made and it seems that part of the structure is not recognized properly.

This happens from emails from Outlook Express and Outlook 2003 from what I've been able to test so far.

I tested sending attachments from GMail and Hotmail to Roundcube and it had no issues with the files.

Looking at the source of the email coming from Outlook apps, you can see the major differences in the structure of the email.

I'm also wondering if PEAR's mimeDecode stuff is partly to blame, but I'll keep you guys updated.

I'm working on a fix.

UPDATE:

Latest SVN, when viewing emails with attachments from Outlook, the only thing you will see is the body of them message. After this, the cache is corrupted and you lose all your message headers when viewing your Inbox. Very interesting.

[syc]

Here is the fix. It is unrelated to RoundCube. Blame PEAR mimeDecode crap.

Open up mimeDecode.php in 'program/lib/Mail'.

Find line: 503 or look at the _boundrySplit function.

OLD LINE:

for ($i = 1; $i < count($tmp) - 1; $i++) {

NEW LINE:

for ($i = 1; $i < count($tmp) /*- 1*/; $i++) {

[tomvos]

Hello,

I have the same issue with missing attachments and missing text body. I applied the bugfix proposed by syc, but unfortunatly it did not help. Do you know of any other possible solutions?

I'm using MAMP (PHP 4.4.4, mysql 5.0.19), but the same happens with php5.

Thanks.

P.S.
Roundcube seems very promising to me.