Attachments to email

Hello All,

I’m faced with a problem that I haven’t seen sofar. An application of
ours sends an email from an Oracle database to our RT (3.8.2) install
containing attachments. The filename in the Content-Disposition:
attachment; field contains a name which is not compliant with the
filesystem of the OS (Centos5).
See the below example:

-------7D81B75CCC90D2974F7A1CBD
Content-Type: application/octet-stream
Content-Disposition: attachment; filename="F413529322/Test Janine en
Miranda.doc"
Content-Transfer-Encoding: base64

RT accepts the email and creates a ticket including the attachment but
you can’t get it out of the database anymore because the ‘/’ isn’t
escaped or translated into something not harmful, same holds true for
the spaces in the filename.
I googled for rfc and Content-Disposition: attachment; filename= which
came up with RFC-2183 which mentions that the recieving end is
responsible for sanitizing the filename part.

Did I found a bug or I’m misinformed about how the
Content-Disposition: attachment; filename= should work?

Regards,

Joop

PS:
Compleet message is available if needed for testing.

As a follow up:

The URL in Ticket Metadata is:
http://rt3.mococo.nl:82/rt3/Ticket/Attachment/431330/279232/F1356386247%2Ftest%20%20print%20screen.doc
but clicking on it displays:
http://rt3.mococo.nl:82/rt3/Ticket/Attachment/431330/279232/F1356386247%2Ftest
print screen.doc
Notice the escaped / but not the spaces and an error in my browser (FF
3.6.10). Changing the %2F to / will give me a download dialog. Using IE6
gives me an URL with all spaces escaped and the / escaped but same here,
I need to edit %2f to / to get the document out or RT

Regards,

Joop

Sory to bump this message.

Doesn’t anyone have an opinion as to how RT should behave?

Regards,

Joop