Kevin J. McCarthy wrote in
<[email protected]>:
|I'm thinking about enabling $rfc2047_parameters by default, and would
|like to hear any counter-arguments against this.
|
|Here we are in 2022, yet I still occasionally receive tickets, or most
|recently even a merge request (!154), about this. Obviously some mail
|clients are *still* improperly applying 2047 encoding.
|
|Making the situation worse, the config variable name isn't intuitive (to
|someone who isn't familiar with the relevant rfcs), so the user usually
|has no idea how to fix the problem. Even the merge request author, who
|was skilled enough to hack the code, wasn't aware there was already a
|variable.
|
|To me, enabling the variable has low potential risk and would definitely
|save user frustration, but I'd like to hear if there are potential
|downsides to doing this.
The MUA i maintain does
/* We do have a result, but some (elder) software (S-nail <v14.8)
* will use RFC 2047 encoded words in parameter values, too */
/* TODO Automatically check whether the value seems to be RFC 2047
* TODO encwd. -- instead use *rfc2047_parameters* like mutt(1)? */
if((p = su_cs_find(rv, "=?")) != NIL &&
su_cs_find(p, "?=") != NIL){
Ever since
1b94b14714f mime_param.c (Steffen Nurpmeso 2015-03-30 23:30:28 +0200 884)
* TODO encwd. -- instead use *rfc2047_parameters* like mutt(1)? */
i personally never encountered a problem.
A nice Sunday i wish from Germany,
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
