789777 - Show ATT00001 files attached to emails from Exchange servers only inline (and not as file attachment)

Status: RESOLVED WONTFIX

(MailNews Core :: Attachments, defect)

Description

[Vittorio Giovara]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0
Build ID: 20120824154833

Steps to reproduce:

I'm subscribed to several mailing list powered by Mailman system and I am receiving my mails on an Exange (2007 I believe). Every message I receive from those mailing list always contain an attachment file named "ATT00001.c" that hold the mailing list signature in text format.


Actual results:

According so some documentation found online on ATT files (eg. http://kb.mit.edu/confluence/pages/viewpage.action?pageId=4981187 ) it appears that this is caused by a strange behaviour in Exchange server, but only when other files are attached. What I am experiencing is that every message is affected by these ATT files and this makes it very difficult to understand whether the message really has an attachment file or just the mailing list signature.


Expected results:

Even though the problem is evidently in Exchange software, it would be nice that Thunderbird could handle those well-known files and integrate them directly in the message body, so that only real attachments are actually listed.

Comment 1

[Thomas D. (:thomas8)]

Vittorio, pls attach a testcase msg to this bug with private data removed as required.

Comment 2

[Vittorio Giovara]

Attachment: Example of email message with ATT00001.c attached

Here is an example message; the list is public so you can check the message in the archives as well: http://mailhost.tnt.uni-hannover.de/pipermail/cdvs/2012-August/000775.html.
As you can see there, something strange has already happened and it has been reported as follows:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailhost.tnt.uni-hannover.de/pipermail/cdvs/attachments/20120829/8a9ab280/attachment.htm

Comment 3

[Jim Porter (:squib)]

There doesn't appear to be anything in the attachment's headers (other than the name) that suggests this isn't a real attachment. I'm also not comfortable with the idea of treating attachments with names like this as not-attachments, since there's nothing improper about the name, and it's entirely possible that legitimate attachments could have a name like this (though it's probably pretty rare).

In general, I think we should be lenient with broken messages if following the spec would result in content going missing. However, when that lenience results in hiding content that the spec says should be visible, we should *always* follow the spec. Standards-compliant mailers deserve to have their content rendered properly, even if their content resembles that generated by non-compliant ones.