Opened 10 years ago

Last modified 7 years ago

#4973 new bug

Zip attachment is renamed

Reported by: humdinger Owned by: bga
Priority: normal Milestone: R1
Component: Applications/Mail Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

This is hrev33939.

When attaching a zip archive to a mail, it appears simply as "attachment" not with it's proper filename, when sent to someone not using Haiku Mail. For example in my gmx.de webmail account or when sent so some MS Outlook shlob.

Mail shows the proper filename, independently if the BeOS attributes are sent with it or not.

JPEGs, PNGs, a HTML page and a TXT file came through unharmed.

Strangeness.

Attachments (1)

Test mail with attachment bügs.zip 20091116164049 Humdinger.zip (4.5 KB) - added by humdinger 10 years ago.
Test mail with attached file "bügs.zip"

Download all attachments as: .zip

Change History (4)

comment:1 Changed 10 years ago by axeld

Since Mail does not have any special treatment for ZIP files, this sounds indeed strange. Can you attach a problematic test mail to this ticket?

comment:2 Changed 10 years ago by humdinger

I first couldn't reproduce. Thought I went mad[[BR]] It looks like it only happening with attachments containing a non-ASCII(?) character. At least with my German Umlaut "ü". So... the zipped up mail is attached to this ticket.

Attached to this mail is a zip file called "bügs.zip", within it a text file named "bugs".

When viewed via the web mail interface, the enclosure appears renamed to "attachment". When it's downloaded from Haiku, Mail does show the correct filename "bügs.zip".

From Mail's preferences "No BeOS attributes" are sent with the mail, but even if you do, there's no different outcome.

Changed 10 years ago by humdinger

Test mail with attached file "bügs.zip"

comment:3 Changed 7 years ago by stpere

From http://www.ietf.org/rfc/rfc2183.txt:

In the 2.3 section, "The filename parameter".. :

Current [RFC 2045] grammar restricts parameter values (and hence

Content-Disposition filenames) to US-ASCII

So, I guess we should transcode the string to US-ASCII to follow the standard.

Note: See TracTickets for help on using tickets.