RT 3.8.7 : text/plain attachements not sent

Hello,

I have been reported by our users that ‘some’ attachments were not actually attached. After having searched this issue, it appears
that if we attach files that the browser reports as having the MIME type of text/plain, these files are not sent, they even do not
appear inline to the recipient. But they are registered into the ticket normally.

Do other RT 3.8.7 (or lower ?) users have the same problem ? Does anybody has a solution ? I browsed the mailing-list, find many
discussions about text/plain files, but not my case specifically.

My users report that in 3.6.1 (our previous version, installed on an older CentOS 4), they were able to send text attachments.

I installed RT 3.8.7 on a CentOS 5.4 OS; I installed many Perl modules from Rpmforge, and as all could not be installed that way, I
finished with make fixdeps. Hopefully it is not an issue with some Perl module version. As I don’t see ANYTHING in RT’s log nor in
httpd.log (log level already set to ‘debug’), I can’t even guess what is happening and what to look for - I don’t have a clue.

Best regards

Robert GRASSO – System engineer

CEDRAT S.A.
15 Chemin de Malacher - Inovallée - 38246 MEYLAN cedex - FRANCE
Phone: +33 (0)4 76 90 50 45 - Fax: +33 (0)4 56 38 08 30
mailto:robert.grasso@cedrat.com - http://www.cedrat.com

Kenneth,

Thanks for trying. I apologize for not having been accurate enough. I will try to improve my accuracy, without writing a too long
post :wink:

I actually had already tweaked the option you mention : “$SuppressInlineTextFiles” without success.

Here is the story :

I put RT 3.8.7 in production some weeks ago. So far so good. In our templates (Correspondence etc), I had enabled long ago :

RT-Attach-Message: yes

so that our people could send attachments. And attachements were flowing away from RT 3.8.7. So far so good.

Then some days ago, I have been reported that one of our customers did not receive one specific attachment ! Hell ! What kind of
quirk was this ?

I performed several tests with Firefox, from Win$, Ubuntu, MSIE from Win$ : all my attachments were sent to the recipient ? I was
amazed.

So yesterday I decided I had to make more thorough tests, and find it out : because I was not confident in our general attachment
sending, until I would not have solved this mystery !

Posting from the PC of the user who reported the failure, even if I connected into my RT account, attaching the file which
originally failed to be sent by the user, it failed as well ! But it did not fail from MY PC !! Amazing !

So I went deeper into the MIME topic which I did not know well so far. Browsing the failed tickets, it looked like troubles were
happening about text/plain attachments. I spent time browsing the Gossamer threads. I discovered the hard job the browsers do at
guessing the MIME types of the files we use to download/upload.

I discovered in the registry (under HKEY_CLASSES_ROOT on XP) the MIME ‘table’ used by MSIE (our users mainly use MSIE :frowning: ), and
then ran the killer test from MSIE :

  • I renamed a test text file with several extensions, which were each assigned the ‘text/plain’ MIME type in the registry (registry
    tag : “Content Type”) : .odh, .py, .txt, attached them, and posted them to a test recipient : and EACH TIME, the recipient DID NOT
    receive the attached file ! Whereas the attached file appeared as a normal attachment in the RT Web UI.

So this is my diagnostic : with RT 3.8.7, when the MIME type assigned to the attachement by the browser (as an uploaded file) is
’text/plain’, RT registers it correctly in the DB, but fails to actually send it.

Well, I have been at bit long, hopefully I have been clear enough ?

Regards

Robert GRASSO – System engineer

CEDRAT S.A.
15 Chemin de Malacher - Inovallée - 38246 MEYLAN cedex - FRANCE
Phone: +33 (0)4 76 90 50 45 - Fax: +33 (0)4 56 38 08 30
mailto:robert.grasso@cedrat.com - http://www.cedrat.com