Umlauts and spaces getting removed when sending appointment (as attachment) in Roundcube
Open, LowPublic


With latest Winterfell, I'm experiencing the following in Roundcube:

  1. Create a new appointment titled "Rasen mähen" (note the German umlaut), save it
  2. Click the appointment, select "Options" and "Send"
  3. New e-mail screen opens where the attachment is named "Rasenmhen.ics"

Honestly, I would expect "Rasen mähen.ics" as filename, pretty nice UTF-8 encoded ;-)


Ticket Type

Event Timeline

rsc created this task.Aug 16 2018, 11:19 PM
rsc added a project: Roundcube Kolab Plugins .

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.

vanmeeuwen closed this task as Wontfix.
vanmeeuwen moved this task from Backlog to Done on the Roundcube Kolab Plugins board.
vanmeeuwen added a subscriber: vanmeeuwen.

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.

rsc reopened this task as Open.Aug 23 2018, 1:31 AM

Maybe I wasn't clear about what I would like to see: Roundcube's config/ 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;
Content-Disposition: attachment;

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.

vanmeeuwen lowered the priority of this task from Needs Triage to Low.Mar 22 2019, 11:53 AM

This seems like low-priority aesthetics to me more so than an actual problem.