Error when sending mail with accents in the filename of an attachment

There are some issues when sending an email with accents in the filename of an attachment. I received this error message in the status bar (bottom of the screen):

imap: size of Literal is not equal to Len() (97934 != 97932)

The recipient was unable to open the attachment and there were. A workaround was to rename the attachment to remove the accents and resend it.

The offending character was "é" but I suspect any character outside the ascii space will fail.

I faced it both on master and 0.4.0.

Assigned to
a month ago
29 days ago

~crocmagnon a month ago

Here's what the recipient sees as filename when I sent the attachment with the accent and the file wouldn't open:

=?utf-8?q?R =C3=A9servation_Mingat

See this screenshot.

~john1doe a month ago

Can confirm: tried to send an attachment named with Cyrillic characters, лето лето.png (note the absence of any leading spaces or whatever). Got the same error while sending, imap: size of Literal is not equal to Len() (428883 != 428884). And the received letter had this:

Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="=?utf-8?q?
Content-Type: image/png; name="=?utf-8?q?=D0=BB=D0=B5=D1=82=D0=BE_

Note the added linebreak in the filename parameter of Content-Disposition header, same as with the original case, =?utf-8?q?R =C3=A9servation_Mingat, right before the first non-ASCII character.

I also send the same attachment only renamed in English, 'summer summer.png', and this time the header didn't have any of this:

Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="summer summer.png"
Content-Type: image/png; name="summer summer.png"

However, it's not limited to attachments: for emails, sent from aerc, I also notice some (not every, not always) non-ASCII subjects being displayed partly or not displayed at all.

For instance, this was the subject of the email I received (лето, ах лееето) in Russian, meaning something like summer, oh suuuummer)):

Subject: =?UTF-8?B?0LvQtdGC0L4sINCw0YUg0LvQtdC10LXRgtC+KQ==?=

I replied to this letter in aerc, the subject became Re: лето, ах лееето), and in the sent email it looked like this:

Subject: =?utf-8?q?Re:_=D0=BB=D0=B5=D1=82=D0=BE,_=D0=B0=D1=85_
 =D0=BB=D0=B5=D0=B5?= =?utf-8?q?=D0=B5=D1=82=D0=BE)?=

And in aerc the last леееето was missing, the subject looked like this: Re: лето, ах (Re: summer, oh), though in my webmail I could see it in full.

So, it indeed seems that aerc does something strange (like, inserts a linebreak or whatever) before some non-ASCII chars. And besides that, aerc also fails to display Subject in full if the named linebreak is present (well, can't really blame aerc here :).

~crocmagnon a month ago

Fix screenshot link from previous comment, sorry for the trouble.

~john1doe 30 days ago

A short follow up to my previous comment: if I move that letter with an inserted linebreak in a Subject to an empty folder, so that it would the only letter there, then aerc will display it like this, showing exactly that added/inserted symbol as indeed a linebreak.

~labrat 30 days ago

Please stop dumping screenshots into the ticket... It's very nice that you figured out the culprit, non ascii chars in the attachment filename.

As for now, someone needs to debug the code, screenshots of artifacts aren't helpful anymore.

~john1doe 30 days ago

Not only in the attachment filename but also in the Subject (and other fields may be affected, too).

~labrat 29 days ago

Please test the master branch and report if this fixes your issue

~john1doe 29 days ago

From my side, it looks like so. Thank you very much :)

~labrat REPORTED FIXED 29 days ago

Register here or Log in to comment, or comment via email.