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
Re: Enabling $rfc2047_parameters by default
On Sat, Jan 08, 2022 at 02:46:48PM -0800, Kevin J. McCarthy wrote: > I'm thinking about enabling $rfc2047_parameters by default, and would like > to hear any counter-arguments against this. I believe the original argument against was that doing so violates the RFCs, and therefore potentially obscures a header that actually wanted that text to appear in the header in conformance with the spec. However--and my memory on this is as vague as ever--wasn't there an update to the RFCs that expressly allowed it in headers for which it wasn't previously allowed? One certainly might raise the question of why it was originally excluded from the spec... There was probably a reason, but I don't know it. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: Enabling $rfc2047_parameters by default
On Mon, Jan 10, 2022 at 06:08:12PM -0600, Derek Martin wrote: On Sat, Jan 08, 2022 at 02:46:48PM -0800, Kevin J. McCarthy wrote: I'm thinking about enabling $rfc2047_parameters by default, and would like to hear any counter-arguments against this. I believe the original argument against was that doing so violates the RFCs, and therefore potentially obscures a header that actually wanted that text to appear in the header in conformance with the spec. I guess it's theoretically possible someone would want an attachment named that way, but it doesn't sound likely. :-/ However--and my memory on this is as vague as ever--wasn't there an update to the RFCs that expressly allowed it in headers for which it wasn't previously allowed? If anyone else has a pointer please let me know, but I'll try to take a look. One certainly might raise the question of why it was originally excluded from the spec... There was probably a reason, but I don't know it. I think it's because 2231 both provides encoding and allows the parameters to be split across multiple lines and reassembled. The intro to the rfc also discusses the reason language information was added. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
