Hi List,
I think there is a problem with mime-encoded header handling.
The following code (and comments) are in I18N.pm file (3.8.7):
It’s legal for headers to contain mime-encoded commas and semicolons which
should not be treated as address separators. (Encoding == quoting here)
until this is fixed, we must escape any string containing a comma or
semicolon
this is only a bandaid
Some other MUAs encode quotes already, and double quotes
confuse us a lot, so only quote it if it isn’t quoted
already.
$enc_str = qq{“$enc_str”} if $enc_str =~ /[,;]/ and $enc_str !~ /^“.*”$/;
It is good for To, Cc and other fields because non-ascii, encoded names
before email
addresses can containt commas and semicolons, for example:
NonAscii, Name foo@bar.com
becomes
“NonAscii, Name” foo@bar.com
and that’s why commas don’t cause problems, but it’s not good for subject.
If I have a non-ascii subject with comma or semicolon it will be quoted.
Non-ascii, subject
becomes
“Non-ascii, subject”
It’s not good but tolerable. But if I have a long non-ascii subject, I will
get
a worse thing:
It is a very long non ascii subject with commas, in the header, it will be
encoded and multiline
becomes something like this:
“It is a very long non ascii subject with commas, in”" the header, it will
be encoded and multiline"
It’s not good if you parse the subject, and may annoy your users.
I attached a patch that I use to avoid this problem. It’s maybe useful but
maybe you have a better solution
or opinion about this problem. Please let me know if there is!
Thanks,
Bekeny
Docca OutSource IT Ltd
subject_noquote.diff (834 Bytes)