Enabling $rfc2047_parameters by default
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. Thank you! -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: Enabling $rfc2047_parameters by default
Kevin J. McCarthy wrote in : |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