Closed Bug 188108 Opened 18 years ago Closed 15 years ago
Inline-Forward of message with unnamed RFC822 attachment unnecessarily adds name to the headers: (null).eml
11.96 KB, text/plain
931 bytes, patch
|Details | Diff | Splinter Review|
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
Assignee: mscott → cavin
Mail triage team: nsbeta1+/adt2
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)"
Mail triage team: nsbeta1-
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.
Updating summary to more precisely describe what's going on; resetting milestone, reducing severity, updating platform/OS.
Assignee: cavin → sspitzer
Severity: major → minor
OS: Windows 2000 → All
QA Contact: stephend
Hardware: PC → All
Summary: Forwarding an AOL forwarded message shows forwarded message (as attachment) as null.eml → Inline-Forward of message with unnamed RFC822 attachment unnecessarily adds name to the headers: (null).eml
Target Milestone: mozilla1.4beta → ---
*** Bug 277913 has been marked as a duplicate of this bug. ***
(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,
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!
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.
*** Bug 298288 has been marked as a duplicate of this bug. ***
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.
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.
Forgot a line there...
Attachment #223717 - Flags: superreview?(mscott)
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 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() );
Attachment #223717 - Flags: superreview?(mscott) → superreview+
(In reply to comment #17) > (From update of attachment 223717 [details] [diff] [review] ) > 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).
QA Contact: mscott
Whiteboard: [adt3] → [checkin needed]
Gavin might be able to land this on the branch for you along with 154332.
Depends on: 154332
Assignee: sspitzer → mkmelin+mozilla
Checked in on trunk. Not checking in on branch due to closure for Fx2 B2. /mozilla/mailnews/mime/src/mimedrft.cpp 1.148
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed] → [checkin needed (1.8 branch)]
Whiteboard: [checkin needed (1.8 branch)]
clearing the blocking flag, we ended up taking this though.
You need to log in before you can comment on or make changes to this bug.