188108 - Inline-Forward of message with unnamed RFC822 attachment unnecessarily adds name to the headers: (null).eml

Status: RESOLVED FIXED

(MailNews Core :: Attachments, defect)

Description

[[e-mail] (gone - use [e-mail] instead)]

Build ID: 2003-01-03-07-08, ALL OSs.

Sorry for the lengthy summary.  The bug exists on our client side, therefore
this most likely belongs here in Bugzilla (as opposed to Bugscape).

Summary: Forwarding an AOL forwarded message show forwarded message (as
attachment) as null.eml

Steps to Reproduce:

1.  Have a forwarded message from an AOL client.
2.  Forward this message (or Message | Edit As New).

Expected Results:

I believe we should display the message's name in the Attachments pane.

Actual Results:

Attachments: (null).eml is displayed

Comment 1

[[e-mail] (gone - use [e-mail] instead)]

Attachment: Test message - forward or Edit | Message as New this

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

--> cavin

Comment 3

[Samir Gehani]

Mail triage team: nsbeta1+/adt2

Comment 4

[louis bennett]

i'm seeing this w/ messages forwarded from netscape 4.78, too.
(mach-o/1.3/20030310.) for reference:

MIME-version: 1.0
X-Mailer: Mozilla 4.78 [en] (Win98; U)
Content-type: multipart/mixed; boundary="Boundary_(ID_cAzqFAno6FcSYgHlAEFIQQ)"

Comment 5

[Samir Gehani]

Mail triage team: nsbeta1-

Comment 6

[Doug]

I see this from AOL too, but also, at least once, from Hotmail.

When I read the message, it is visible in the message pane. But when I forward
it, it is only in the attachments pane instead of quoted in the message pane as
expected. 

What happens next is that if I forward it as is, it is rejected by many servers
that don't let .eml attachments through. So I have to copy and paste the text
into a new message to forward it. If the email has images attached, I have to
save those and reattach them. If it's formatted with inline images, I don't have
a prayer.

Comment 7

[Mike Cowperthwaite]

Updating summary to more precisely describe what's going on; 
resetting milestone, reducing severity, updating platform/OS.

Comment 8

[Mike Cowperthwaite]

*** Bug 277913 has been marked as a duplicate of this bug. ***

Comment 9

[Chaos]

(In reply to comment #8)
> *** Bug 277913 has been marked as a duplicate of this bug. ***

Hi, This bug has been outstanding since 2003, and is marked as minor with no 
apparent visiblility on any fix being forthcomming. I find it more of a majopr 
bug than a minor, it (for me) makes thunderbird pretty much the most annoying 
and unuseable mail client around. I have to complement the developers on 
everything else though, its a great product bar this bug. Is there some way it 
can bumped up to a more visible status, or at least planned for fixing ? 

Thanks, 

Comment 10

[Jim Booth]

My Mail/Web Host is blocking all such incoming messages and will NOT cooperate
by adjusting their mail virus filter.  I have a major customer using Netscape
7.2 and when she forwards an AOL message, it bounces back.  This makes this a
pretty serious problem for me!

Comment 11

[GOD00007]

I agree.
This is a major bug!
It also happens with yahoo mails.
Most of the mails i get from yahoo.
Some of them are forwarded ones.And when i forward them it attaches (null).eml

Very annoying and makes thunderbird unusable to me.

Please fix this ASAP.

Comment 12

[Mike Cowperthwaite]

*** Bug 298288 has been marked as a duplicate of this bug. ***

Comment 13

[Magnus Melin [:mkmelin]]

After the fix for bug 154332, this has different symptoms. (Now the tmp file is used as message name.)

To fix this bug "correctly" I think this is were to start...
http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimemsg.cpp#163
http://lxr.mozilla.org/seamonkey/source/mailnews/mime/src/mimemoz2.cpp#254

... but unless someone has good pointers, it may be a lot of work.

Comment 14

[Magnus Melin [:mkmelin]]

Attachment: use ForwardedMessage.eml as attachment name if the we don't know the name

This patch makes us use "ForwardedMessage.eml" for name if the eml attachment is not named in any way. It's not of course *the* optimal solution, but a lot better than the current situation, IMO.

If one don't have view attachments inline turned on, it would even be the expected result due to bug 227720.

Comment 15

[Magnus Melin [:mkmelin]]

Attachment: use ForwardedMessage.eml as attachment name if the we don't know the name

Forgot a line there...

Comment 16

[Mike Cowperthwaite]

I just explained this symptom in response to a newsgroup query; the probem is being encountered in the field, and we have a patch, so it would be nice to get it in place.

However, I wonder whether this patch is the ideal fix.  Wouldn't it make better sense, when we forward a message, that we don't change the MIME headers for the attached parts, and (in this case) leave the attachment unnamed (and inline)?

Comment 17

[Scott MacGregor]

Comment on attachment 223717 [details] [diff] [review]
use ForwardedMessage.eml as attachment name if the we don't know the name

sr=mscott, but I'd be curious to note what happens if we just didn't fill in a real_name at all here, since it didn't have a name to begin with. 

i.e. 

    else if (tmpSpec.get())
-          NS_MsgSACopy ( &(tmp->real_name), tmpSpec.get() );

Comment 18

[Magnus Melin [:mkmelin]]

(In reply to comment #17)
> (From update of attachment 223717 [details] [diff] [review] [edit])
> sr=mscott, but I'd be curious to note what happens if we just didn't fill in a
> real_name at all here, since it didn't have a name to begin with. 

I tried that, what happens is the mail to fwd does not show up as an attachment, nor is it included when sent. It would only show the -------- Original Message --------  etc. headers, but not the message it self. I guess there is a null check somewhere...

As for getting this into tb2, I think the fix for bug 154332 also have to get on branch (because that path is hit first IIRC, so it would have a name by the time we get to the code touched by this fix).

Comment 19

[Scott MacGregor]

Gavin might be able to land this on the branch for you along with 154332.

Comment 20

[Peter Kasting]

Checked in on trunk.  Not checking in on branch due to closure for Fx2 B2.

/mozilla/mailnews/mime/src/mimedrft.cpp 1.148

Comment 21

[:Gavin Sharp [email: [e-mail]]]

mozilla/mailnews/mime/src/mimedrft.cpp 	1.142.2.5

Comment 22

[Scott MacGregor]

clearing the blocking flag, we ended up taking this though.