0

When I'm attaching a file with Russian name, the recipient received the attachment with name noname. I added set rfc2047_parameters = yes to .muttrc, and it started to work for simple filenames like Решение.doc and тест тест.txt. But when I attach a file with a long filename: Электронный документ, полученный из внешней системы.pdf, which is still valid and can be attached though Gmail web interface, it still gives noname as the file name when sent from mutt.

Is it possible to fix?

Update: locale result:

$ locale
LANG=en_US
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=en_US.UTF-8
4
  • What locale setting do you have (the output of the locale command)? I tested to send an empty file with the given name to myself with mutt (2.0.3) just now, and it worked as expected. I did not set rfc2047_parameters at all. – Kusalananda Dec 24 '20 at 19:40
  • @Kusalananda Updated the question. – user4035 Dec 24 '20 at 19:46
  • 1
    What email client are the recipient using when they see the noname name? What version of mutt are you using, and on what operating system? – Kusalananda Dec 24 '20 at 20:20
  • 1
    @Kusalananda Mutt 1.10.1 (2018-07-13) Linux Slackware 14.2. Seems, that my mutt is outdated, and this is the cause. – user4035 Dec 25 '20 at 10:37
2

I believe that this is a known bug in older releases of mutt and that it was fixed in May 2019 with commit 6898c083. This means that the fix ought to have been included in release 1.12.1.

I'm unable to reproduce your issue with release 2.0.3 (the current release at the time of writing), so I'm assuming that the fix is still in effect.

The issue was that mutt truncated the filenames of attachments that had long names. The truncation was not done correctly for multi-byte character strings and left the last character of the filename encoded erroneously. When a user's email client noticed that the encoding of the attachment filename was incorrect, it replaced the name with the string noname.

After release 1.12.1, you ought to be able to use filenames of up to 255 characters.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.