On version 0.2.3, escaping headers were introduced exactly by this PR-131
Unfortunately this change ignored RFC-2047 Section 2 regarding encoded words having a maximum size of 76 characters including prefix =?UTF-8?Q? and suffix ?=.
One other thing this PR fixes is regarding question mark was not being escaped.
At RFC-2045 Section 6.7 is listed on rule 2 that question marks (among other characters) could be encoded (but not mandatory) and we don't encode it. But encoding it would simplify the way we handle encoded words prefixes and suffixes as I describe below.
Take sufixo ?= incluído aqui as an example.
Not encoding question mark, we have: =?UTF-8?Q?sufixo ?=3D inclu=C3=ADdo aqui?= that decoded translates to sufixo 3D inclu=C3=ADdo aqui ?=.
If we encode question mark we have =?UTF-8?Q?sufixo =3F=3D inclu=C3=ADdo aqui?= and then we don't have any issue.
bcardarella
commented
3 years ago
Changes proposed in this pull request
On version 0.2.3, escaping headers were introduced exactly by this PR-131
Unfortunately this change ignored RFC-2047 Section 2 regarding encoded words having a maximum size of 76 characters including prefix
=?UTF-8?Q?and suffix?=.One other thing this PR fixes is regarding question mark was not being escaped.
At RFC-2045 Section 6.7 is listed on rule 2 that question marks (among other characters) could be encoded (but not mandatory) and we don't encode it. But encoding it would simplify the way we handle encoded words prefixes and suffixes as I describe below.
Take
sufixo ?= incluído aquias an example.Not encoding question mark, we have:
=?UTF-8?Q?sufixo ?=3D inclu=C3=ADdo aqui?=that decoded translates tosufixo 3D inclu=C3=ADdo aqui ?=.If we encode question mark we have
=?UTF-8?Q?sufixo =3F=3D inclu=C3=ADdo aqui?=and then we don't have any issue.