Re: RFC 2047 in headers

[Jean Louis]

* Sergey Poznyakoff <gray@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.