Re: [SM-USERS] Strange behavior with an attachment.

[J Adams]

SquirrelMail 1.4.2
Courier-IMAP
FreeBSD 6.x
PHP 5.1.x
Apache 1.3

I had this issue a while back, but was unable to resolve it.  Problem still persists for my users.

What I noticed is that some Content-type that comes into our system is interpretted (correctly), by SM and I am able to view/download the attachment.  However, if I try to forward this message (BOTH as regular forward and forward as attachment)... the message is sent with the "untitled-[1]  0 k   [ multipart/alternative ]" attachment.  I can see this in my Sent folder, as well as on the recepient's mailbox (on the same system). 

The recepient is unable to view/download the attachment, nor am I able to view/download the attachment from my Sent folder.  However, as noted by Matthew Ruzicka, is viewable/downloadable in a standard client such as Mozilla Thunderbird or MS Outlook.

A particular instance, adding to what Matthew said, is when one of my users sent a PDF file from another system.  SM recognized the attachment, and showed me it as "[ application/octet-stream ]".  I am able to download this file correctly.  If I compose a new message and attach the same file, SM will note it as being "[ application/pdf ]", which is more appropriate.

The problem in this situation lies when I try to forward the "[ application/octet-stream ]".  When I forward it, my Sent folder will show the untitled 0k and the recepient of the message (on the same system) will see the untitled 0k as well in SM.

This may have something to do with how SM handles the converting of the octet-stream content type.

Is there something I can modify to the SM code to alieviate the issue?

Thank you.
-Alex

On 5/3/06, Matt Ruzicka <[EMAIL PROTECTED]> wrote: Hmm.. That's really interesting because we have had similar reports.

Here are our specs:

SquirrelMail 1.4.6
FreeBSD 4.x
Apache 2.2.x
PHP 5.1.x
Courier-IMAP

It has been a while since I looked into this, but I seem to remember my
testing indicated it was the result of certain mailer scripts or clients
not adding a name or filename label to the Content-Type or
Content-Disposition headers. Although other clients such as OE and
Thunderbird handled them properly I sort of assumed they were just
"fixing" the broken formatting, where as SM was maybe truer to RFC.  I
could be off base on that assumption though. I seem to remember that if I
manually edited the mail file and added those labels I believe the
attachments would be handled as expected.  This lead me to believe it was
how the original message was being broken apart then re-attached that
might be the problem.  We discovered that if the user just forwarded as
attachment (which I understand other web clients like yahoo and hotmail do
by default) everything forwarded fine.

Either way it was primarily affecting one user that was receiving mail
from a FAX service that was adding a 'X-Mailer: Mabry' header so we told
them to just forward as attachment.

If this could be "fixed" that would be great as well, but unless someone
who understands mail RFC better than I do indicates otherwise, I'm not
sure SM is actually going anything "wrong".

Matthew Ruzicka - Systems Administrator
Front Range Internet, Inc.
[EMAIL PROTECTED] - (970) 212-0728

Got SPAM?  Take back your email with MailArmory.   http://www.MailArmory.com

On Wed, 3 May 2006, J Adams wrote:

> A user attaches a file in SquirrelMail. It shows up in the compose window
> and it seems to attach correctly but, after sending, the attachment is no
> longer there. It appears in the sent fold as "untitled-[1]  0 k   [
> multipart/alternative ]"
>
> I have several reports of this behavior from users, but I haven't been able
> to reproduce it.
> My first thought was that this is not a squirrelmail issue (and I'm still
> skeptical), but I need to rule it out. I don't see any other common
> denominators among these users.
>
> SquirrelMail 1.4.2
> php 4.3.6
> FreeBSD 5.x
> Apache 1.3
> courier-imap
>
> Thanks.
>

I can reproduce this behavior by setting the "default email composition format" to HTML in Options -> Display Preferences. Changing that setting to "plain text" clears it up.

Is this a known issue? Is there something we can do about this?