Attachments with international characters (Intern)

RT 3.2.1 does not handle attachments with international characters (also RT 3.0.11).
The following part of a MIME mail does not show up in “Attachments”, but I am able
to download it (and open it as long as I know what format the file have .doc .xls etc).
The download link is displayed as " Download(untitled) "filename 570b ".

------=NextPart_001_01C47F8E.A445DC94
Content-Type: application/msword;
name="=?iso-8859-1?Q?Filename_with_norwegian_characters
=E6=F8=E5=2Edoc?="
Content-Transfer-Encoding: base64
Content-Description:
=?iso-8859-1?Q?Filename_with_norwegian_characters
=E6=F8=E5=2Edoc?=
Content-Disposition: attachment;
filename="=?iso-8859-1?Q?Filename_with_norwegian_characters_=E6=F8=E5=2Edoc?="

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMQAAAAAAAAAA
YXJ0amVuZXN0ZSBmb3IgYXV0b21hdGlza2UgYm9tc3Rhc2pvbmVyAAwQAAACAAAAHgAAAAcAAABU

------_=_NextPart_001_01C47F8E.A445DC94–

These headers need to be parsed in the same way the mail headers are (Subject: ).

Environment:
Linux (Fedora Core 1)
Perl 5.8.3
Apache 2.0.49
RT 3.2.1 as FastCGI

Have anyone else seen this, and know how this could be solved?

Regards
Ronny Pettersen

RT 3.2.1 does not handle attachments with international characters
(also RT 3.0.11).
The following part of a MIME mail does not show up in “Attachments”,
but I am able
to download it (and open it as long as I know what format the file
have .doc .xls etc).
The download link is displayed as " Download(untitled) "filename 570b
".

Ah. So the issue isn’t actually that RT doesn’t handle messages with
international characters, but that we only process the message headers
for international characters and MIME::Tools doesn’t do smart things on
our behalf :confused:

I wonder if Email::MIME handles it better.

Jesse

Ah. So the issue isn’t actually that RT doesn’t handle messages with
international characters, but that we only process the message headers
for international characters and MIME::Tools doesn’t do smart things
on our behalf :confused:

I wonder if Email::MIME handles it better.

I think it does, I’ve been using Email::MIME in a system that processes
attatchments with swedish filename, and those were handled ok. Anyways,
it’s easier to bother Simon if it’s borked :smiley: I’m also very interested
in getting this issue resolved, as it’s been an annoyance for us for
about a year now. :-/

Marcus

Marcus Ramberg wrote:

Ah. So the issue isn’t actually that RT doesn’t handle messages with
international characters, but that we only process the message headers
for international characters and MIME::Tools doesn’t do smart things
on our behalf :confused:

I wonder if Email::MIME handles it better.

I think it does, I’ve been using Email::MIME in a system that processes
attatchments with swedish filename, and those were handled ok. Anyways,
it’s easier to bother Simon if it’s borked :smiley: I’m also very interested
in getting this issue resolved, as it’s been an annoyance for us for
about a year now. :-/

Marcus

	Hello.

According to RFC2047:
http://www.zvon.org/tmRFC/RFC2047/Output/chapter5.html

An ‘encoded-word’ MUST NOT be used in parameter of a MIME Content-Type
or Content-Disposition field, or in any structured field body except
within a ‘comment’ or ‘phrase’.

Also RFC2183
http://zvon.org/tmRFC/RFC2183/Output/chapter2.html#sub2

2.3. The Filename Parameter

Current [RFC2045] grammar restricts parameter values (and hence
Content-Disposition filenames) to US-ASCII. We recognize the great
desirability of allowing arbitrary character sets in filenames, but it
is beyond the scope of this document to define the necessary mechanisms.
We expect that the basic [RFC1521(-> 2049draft | 2048bcp13 | 2047draft |
2046draft | 2045draft)] `value’ specification will someday be amended to
allow use of non-US-ASCII characters, at which time the same mechanism
should be used in the Content-Disposition filename parameter.

Today RFC2045 describe syntax of the ‘value’ and it’s still restricted
to US-ASCII.

In original example only Content-Description field is compliant with
current RFC, so other fields is violation of RFC and can be implemented
in any way.

			Best regards. Ruslan.

Hi Ruslan.

Thanks for the RFC quotes, I think we all agree that non-us ascii
filenames are an abdomination upon the face of the earth, however, I
doubt I can convince the 1000 real-estate brokers that use our system
of this, so it remains a problem for us.

MarcusOn 23. aug. 2004, at 13.15, Ruslan U. Zakirov wrote:

Marcus Ramberg wrote:

On 20. aug. 2004, at 13.37, Jesse Vincent wrote:

On Aug 19, 2004, at 12:52 PM, ronny.pettersen@edb.com wrote:

Ah. So the issue isn’t actually that RT doesn’t handle messages with
international characters, but that we only process the message
headers for international characters and MIME::Tools doesn’t do
smart things on our behalf :confused:

I wonder if Email::MIME handles it better.
I think it does, I’ve been using Email::MIME in a system that
processes attatchments with swedish filename, and those were handled
ok. Anyways, it’s easier to bother Simon if it’s borked :smiley: I’m also
very interested in getting this issue resolved, as it’s been an
annoyance for us for about a year now. :-/
Marcus

  Hello.

According to RFC2047:
Rafa Fernandez, Cerrajero – Calidad de servicio y profesionalismo

An ‘encoded-word’ MUST NOT be used in parameter of a MIME Content-Type
or Content-Disposition field, or in any structured field body except
within a ‘comment’ or ‘phrase’.

Also RFC2183
Rafa Fernandez, Cerrajero – Calidad de servicio y profesionalismo

2.3. The Filename Parameter

Current [RFC2045] grammar restricts parameter values (and hence
Content-Disposition filenames) to US-ASCII. We recognize the great
desirability of allowing arbitrary character sets in filenames, but it
is beyond the scope of this document to define the necessary
mechanisms. We expect that the basic [RFC1521(-> 2049draft | 2048bcp13
| 2047draft | 2046draft | 2045draft)] `value’ specification will
someday be amended to allow use of non-US-ASCII characters, at which
time the same mechanism should be used in the Content-Disposition
filename parameter.

Today RFC2045 describe syntax of the ‘value’ and it’s still restricted
to US-ASCII.

In original example only Content-Description field is compliant with
current RFC, so other fields is violation of RFC and can be
implemented in any way.

  		Best regards. Ruslan.

The rt-users Archives
Be sure to check out the RT wiki at http://wiki.bestpractical.com