683995 - audio/wav attachments seem to "disappear"

Status: RESOLVED DUPLICATE of bug 674473

(Thunderbird :: Message Reader UI, defect, P1)

Description

[SJP]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20100101 Firefox/6.0.1
Build ID: 20110830092941

Steps to reproduce:

1) Upgraded to Thunderbird 6.0.1 (Windows XP SP3)
2) Received e-mail with Base 64; audio/wav attachment
3 [review]) The new e-mail appears in the inbox with the paperclip icon
4) Clicked on the new message


Actual results:

1) The paperclip icon disappears
2) There is no indication that there is an attachment in the reader UI

----
Checked that the "view attachments inline" option is active
Checked the message source to reveal the attachment truly does exist
Checked to ensure the OPtions - Attachments - Content Type audio/wav exists in the config

----

**** This behaviour is limited to audio/wav attachments only! ****


Expected results:

1) The paperclip icon should not be affected
2) The attachment should appear in the reader UI

----

**** This behaviour is limited to audio/wav attachments only! ****

Comment 1

[SJP]

Many VoIP providers, for example, offer their subscribers the option to receive voice mails to their e-mail.  More often than not, the VoIP voice mail systems encode the voice mails into audio/wav files and attach them to the e-mail with Base64 encoding.

While WAV attachments are not as popular as PDF, for example, there is a rather large population of users that may be affected by this bug.

Comment 2

[WADA:World Anti-bad-Duping Agency]

audio/wav part under multipart/related?
  if yes, same issue as Bug 674473.
  Note: if this case, the mail is semantically malformed.
Or audio/wav part under multipart/alternative?
  if yes, similar request to Bug 130119,
  and the audio/wav part can be accessed by enhancement of Bug 602718.

Comment 3

[SJP]

Thank you, WADA.  

I believe that you are correct that this is a duplicate of Bug 674473.

I do not, however, agree that this means the incoming mail is malformed.  What you are saying is a hotly contested point.  The RFC (2387) has been interpreted since 1998 a certain way.  This accounts for the fact that e-mail clients of all sorts have always displayed and handled attachments properly.  If there is a camp that decides to interpret the RFC a different way, then the RFC should be made obsolete and replaced with a new standard.

Unfortunately, it makes no difference how the RFC is interpreted in terms of the end-user experience.  Moreover, the end user who has saved older mails for reference will no longer be able to open relevant attachments if the e-mail client is not flexible enough to be "backward" compatible.