Attachment not shown when also inline image / PHPMailer 1.73

RESOLVED DUPLICATE of bug 674473

Status

RESOLVED DUPLICATE of bug 674473
7 years ago
7 years ago

People

(Reporter: bugzilla, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 555975 [details]
Source of affected message

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603

Steps to reproduce:

Read a message with HTML tecxt and an inline image (in the html).
The message also has an PDF attachment.

The mesage was sent by PHPMailer 1.73 (according to header).


Actual results:

The attachment is not shown in attachment area.


Expected results:

The attachment should be shown in attachment area.
(Reporter)

Comment 1

7 years ago
There is also a bug report at PHPMailer at sourceforge (though I am not 100% sure this is the right place, because there might be many so-called phpmailers out there).

See http://sourceforge.net/tracker/?func=detail&aid=3375756&group_id=26031&atid=385708
Can you attach a message that fails to display  so we can analyse why ?
(Reporter)

Comment 3

7 years ago
The attached zip file should contain such a message (I copied the message source into a txt file).
(Reporter)

Comment 4

7 years ago
It does not seem to happen on TB 3.1.5 (though tested on a different IMAP server and environment, but the message source seems to be identical).
Attachment #555975 - Attachment mime type: application/octet-stream → application/zip
MIME-Version: 1.0
Content-Type: multipart/related;
	type="text/html";
	boundary="b1_20d942cbceeb413655d66af4c6c0debb"

--b1_20d942cbceeb413655d66af4c6c0debb
Content-Type: multipart/alternative;
	boundary="b2_20d942cbceeb413655d66af4c6c0debb"

--b2_20d942cbceeb413655d66af4c6c0debb
Content-Type: text/plain; charset = "utf-8"
Content-Transfer-Encoding: 8bit


--b2_20d942cbceeb413655d66af4c6c0debb
Content-Type: text/html; charset = "utf-8"
Content-Transfer-Encoding: 8bit

--b1_20d942cbceeb413655d66af4c6c0debb
Content-Type: application/octet-stream; name="pro_carton_marketing_event_2011.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="pro_carton_marketing_event_2011.pdf"
Blocks: 505172
Component: Mail Window Front End → MIME
Product: Thunderbird → MailNews Core
QA Contact: front-end → mime
See bug 674473 (and bugs listed in dependency tree)

Comment 7

7 years ago
yeah, I think this is a dup of one of those bugs.
(Reporter)

Comment 8

7 years ago
Thanks for your quick replies!

After looking at bug 674473:
I am not very familiar with MIME - but in the case that I submitted, isnt the line

> Content-Disposition: attachment; filename="pro_carton_marketing_event_2011.pdf"

a clear indication that this part should be displayed as an "attachment"?
I mean, regardless of the "multipart/related" option?

Or, at least (if alternative parts are present), to my understanding, it should probably be displayed if it is related to the actually displayed (selected) part.
In this case here, the attachment seems to be related to the top level, so I would guess it should be displayed in all cases, shouldnt it?
DUPing to bug 674473
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 674473
You need to log in before you can comment on or make changes to this bug.