* Sergey Poznyakoff <g...@gnu.org.ua> [2020-11-03 21:12]: > Jean Louis <bugs@gnu.support> ha escrit: > > > > > And how do I get name for the text part? > > > > That's not possible, currently. It could rather easily be implemented, > though. Can you tell me why is it needed?
It is for sending emails. There is difference if I address person with person's name or with email address only. Is Cyrilic in Ukraine? Maybe you should know what I mean. Imagine you wish to address Ivan in Russian language, but mail fails because you cannot write Иван as it is UTF-8 and should be RFC 2047 encoded. mail tool I am using to programmatically send emails to people. Some features were not available in past and I had to use makemime to make proper email with attachments from Courier MTA package. Now I would like to come back to mail tool. Compiling and building Courier MTA on my system is tiresome. Composing proper multipart emails is not easy task. So far among all tools I know only makemime is capable to compose it and now GNU mail from mailtools. For email clients and for webmail and public email providers it is not visible, people see proper names and proper subjects. Both names in every header should be properly encoded. Only for subject I do not know. Some references: https://dmorgan.info/posts/encoded-word-syntax/ I have discovered that Yahoo was not accepting Q encoding, just B encoding. So both options should be possible and it should be possible to use a switch for either Q or B. More references for the Subject: https://ncona.com/2011/06/using-utf-8-characters-on-an-e-mail-subject/ https://en.wikipedia.org/wiki/Unicode_and_email#Unicode_support_in_message_header So I guess RFC 2047 applies both for names with email addresses and for Subject lines. Myself I am sending many emails to people all over the world. Currently according to database it is from 229 countries. People have various names, some are Chinese, Russian, Serbian. Subject is not always ASCII, emails written in other languages what I do need subject to be converted. My software is doing that and I hope it will be included in GNU ELPA. I am waiting for external package to be included first in GNU ELPA, people are willing and it is matter of time and polishing the package related to database. Once that is in GNU ELPA, I will be able to make dependency on that package and introduce my system to GNU ELPA. Imagine membership management. Members need to get informed automatically. Is is like mailing list manager equivalent to software such as Mautic.org only managed through GNU Emacs without any web interface.