Problem Description

When uploading ICS files using CalDAV containing 'folded' / split-up UTF-8 characters. Example:

[snip]
DESCRIPTION:Lorem ipsum dolor sit amet, consectetur adipisicing elit, **BeschÃ
 ¤ftigte** sed do eiusmod tempor incididunt ut labore et dolore magna aliqua...
[snip]

This occurs with us when splitting up a two-byte encoded "Umlaut" which starts at column 75. The second byte will get folded into the next line, divided by \r\n. Sogo seems to decode UTF-8 first (recognising invalid characters and thus refusing the ICS file) and then unfold the file.

RFC 5545 (iCalendar) states:

Lines of text SHOULD NOT be longer than 75 octets [...]

Where there is no other definition for octets than bytes. Actually they're even addressing the issue described above on the next page:

 Note: It is possible for very simple implementations to generate
 improperly folded lines in the middle of a UTF-8 multi-octet
 sequence.  For this reason, implementations need to unfold lines
 in such a way to properly restore the original sequence.

In our case, the "very simple implementation" is a Perl script which unfolds the ICS file, changes some contents and then folds the lines again.

How to reproduce

Upload attached ICS file, which will be refused with an HTTP error 404. If the \r\n sequence is removed in between the split up multibyte character, the upload works as expected.

Expected behavior

The ICS file with folded multibyte character should be accepted and parsed correctly.

Attachments

broken.ics - folded umlaut, doesn't get imported
fixed.ics - removed folding sequence, thus line too long but gets imported