With latest Winterfell, I'm experiencing the following in Roundcube:
Honestly, I would expect "Rasen mähen.ics" as filename, pretty nice UTF-8 encoded ;-)
According to code it looks intentional, but I don't know a real reason, maybe there was some interoperability issue. Honestly, I don't see a reason to not use unicode.
Compatibility with other clients basically requires (read: "has required"?) file names for attachments are ascii-encoded and do not contain spaces. I think there's even an RFC on client-compatible naming conventions for naming attachments, but I'm failing to recall the number (maybe 2138?).
Other than that, it should be considered non-discretionary to the sender. Any modification of what is about to actually happen would fall under the category of obfuscation.
Maybe I wasn't clear about what I would like to see: Roundcube's config/defaults.inc.php has by default this:
// Encoding of long/non-ascii attachment names: // 0 - Full RFC 2231 compatible // 1 - RFC 2047 for 'name' and RFC 2231 for 'filename' parameter (Thunderbird's default) // 2 - Full 2047 compatible $config['mime_param_folding'] = 1;
Above works properly when attaching a file myself to an e-mail. However this setting seems to be completely ignored when selecting "Send" (as attachment) inside of the calendar appointment, because:
Content-Transfer-Encoding: base64 Content-Type: text/calendar; name=Rasenmhen.ics Content-Disposition: attachment; filename=Rasenmhen.ics; size=475
All I would like to see is that the "Send" (via Calendar) honors $config['mime_param_folding'] and thus behaves like the rest of the Roundcube code.
@vanmeeuwen Spaces and unicode are perfectly allowed in attachment names thanks to the RFCs about encoding the names in headers. The ticket is about iTip attachments specifically. I confirm that the code removes all non-ascii characters making the attachment name completely dummy in some cases. I don't really know why @bruederli make it this way. Maybe there was a reason.
@rsc that setting is not really relevant as the name is made ascii-only before it has a chance to encode the name, but indeed it will be used if we change the code to allow unicode.