Closed stoecker closed 1 month ago
I just tried and can't reproduce ; could you please tell me more about how exactly you had this issue, and whether you have any other plugin enabled?
I tried with all plugins disabled and only custom_from active and the name is garbled. With custom_from deactivated it works. I'm running roundcubemail version 1.6.0 on openSUSE Leap 15.3 Linux. Plugin doesn't seem to have a version. Files are from 30. Nov 2021. Interface is running in German language.
Could you please confirm you also have the issue if you take the latest version from GitHub directly? If yes, please tell me what versions of PHP and Roundcube you're using so I can reproduce a similar environment.
I copied the git files. Nothing changed. Roundcube is 1.6.0 as said above. PHP is 7.4.33.
If you can give me a pointer which part of the code could be responsible, then I may have a look myself, but actually I didn't find anything in the source fast or obvious, so I would need to look much deeper into it.
Action to reproduce:
OK, this seems to be exactly the workflow I tried to reproduce but I'm using PHP 8. Not sure it can explain any difference though ; maybe a difference on mbstring.internal_encoding could have an impact but I'll need to conduct more tests. The entire code is contained in a single custom_from.php and I didn't see anything obvious either for now, but I'll double check.
I think when in message_compose_body the call should be rcube_mime::decode_address_list($message->headers->{$header}, null, false); That prevents the decoding and thus also encoding issue.
This will work for all ascii mail addresses. For non-ascii mail address probably in the test loop a rcube_mime::decode_mime_string for the mailto needs to be done as well. Don't have such a situation...
P.S. Small side note: For the example default config file I permanently get the error in log: Failed to load config from /srv/www/roundcubemail/plugins/custom_from/config.inc.php
I fixed this by simply uncommenting the first option with default value. Afterwards error is gone.
You're right: I was using Roundcube 1.5-rc and didn't have any encoding issue, but after pulling current master (49eb9e) I reproduce your issue. I guess something changed in how address decoding works and didn't take time to investigate exactly what commit caused the issue, but your fix works just fine. I merged it in a746a76ccdf2986980342fc72af1a7c537ab438a and also took care of fixing the sample configuration file to avoid warnings in 765650d9665c06b02ca2c9049ee3019de309499d.
Thanks a lot for taking the time to file this bug report and providing the solution! 🙏
When I use this plugin and answer to an e-mail from someone who has non-ascii text, then the UTF-8 parts are displayed broken.
Example would be an email from me: "Dirk Stöcker <name@email.tld>" would look like "Dirk Stöcker <name@email.tld>".