if pdf attachment names contain spaces, they cannot be opened

[gitgerardo]

• Android version:10 (Omnirom)
• Device:Oneplus 6
• Delta Chat version:1.6.2
• Expected behavior:open pdf files
• Actual behavior:if pdf attachments contain spaces, they cannot be opened error message:" storage permission is needed to proceed "
• Steps to reproduce the problem: If I receive a PDF attachment with spaces in the name, the attachment cannot be opened (error message:" storage permission is needed to proceed "). If I receive the same attachment with a name without spaces, it can be opened.

[Hocuri]

I could not reproduce this on Android 9, Fairphone 3, DC 1.6.2, not even if I denied storage permission to DC.

Does this still happen if you allow storage permission for DC in the system settings?

[r10s]

may it be that the error comes from the app handling the pdf, not from Delta Chat?

@gitgerardo can you provide a screenshot?

[gitgerardo]

Yes , this still happens if I allow storage permission for DC in the system settings.

[gitgerardo]

may it be that the error comes from the app handling the pdf, not from Delta Chat?

@gitgerardo can you provide a screenshot?

I tried to open the two pdf attachments you see in the screenshot with different PDF viewers.It's not possible to open the second one .I have to save it before I can open it. After saving it has a very long name: "utf-8''Risikoeinscha%CC%88tzungCoronaMusikSpahnRichterUpdate6.5.2020.%20pdf.pdf"

[gerryfrancis]

Confirmed.

• Sent attachment named Hello_Gerry Francis.pdf is received as filename*="=?utf-8?q?Hello=5FGerry_Francis=2Epdf?=" .
• Sent attachment named Hello_GerryFrancis.pdf is received as filename="Hello_GerryFrancis.pdf" .

I do not know if this is intended, but the space character is replaced by an underscore. Edit: According to RFC 1342, an underscore should be used instead of a space character, so this OK.

[gerryfrancis]

When we mention the character set (UTF-8), we have something like this:

filename*="=?utf-8?q?Hello=5FGerry_Francis=2Epdf?="

But according to RFC 2231, the value should be formed like this:

filename*=utf-8''Hello_Gerry%20Francis.pdf

I have formed this after reading the documentation, I cannot check out if my interpretation is correct, maybe someone else can do it.

[gerryfrancis]

Indeed, there is a difference! Here is a better example:

File named Hello_Gerry Francis_ÄÖÜäöü.pdf (with German umlauts).

Posteo Webmail (distorted in Delta Chat):

filename*0*=UTF-8''Hello_Gerry%20Francis_%C3%84%C3%96%C3%9C%C3%A4%C3%B6;
 filename*1*=%C3%BC.pdf

Delta Chat (distorted in Posteo Webmail): filename*="=?utf-8?b?SGVsbG9fR2VycnkgRnJhbmNpc1/DhMOWw5zDpMO2w7wtMzQ2OTY4Nzk3OC5wZGY=?="

[gerryfrancis]

Another thing that probably violates with RFC 2047 is this:

An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used.

In the Delta Chat encoding, I was counting 76 characters instead of 75.

[r10s]

closed in favor to more concrete https://github.com/deltachat/deltachat-core-rust/issues/2079