In a folded header, the prefix part of the regexp does not match
characters on the previous line. As a result, part of the header is
lost. To address this, the patch below causes
DecodeMIMEWordsToEncoding to match the header as a single line (‘s’
flag). We also replace the negated character class by a non-greedy
.*? construct (the negated character class does not seem to match \n,
which surprises me somewhat).
A header which can be used to reproduce the bug is:
Content-Type: application/msword;
name=“030728 AV Promotion und =?ISO-8859-1?Q?F=FChrungszeugnis=2Edoc?=”
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename=“030728 AV Promotion und =?ISO-8859-1?Q?F=FChrungszeugnis=2Edoc?=”
An unpatched RT turns this header into the following, clearly bogus
header:
Content-Type: “030728 AV Promotion und Führungszeugnis.doc”
Content-Disposition: “030728 AV Promotion und Führungszeugnis.doc”
Content-Transfer-Encoding: base64
In its second hunk, the patch below also addresses some problems which
we discussed a few months ago (but I don’t know exactly where).
Index: I18N.pm
— I18N.pm (…/branches/bestpractical/lib/RT/I18N.pm) (revision 110)
+++ I18N.pm (…/trunk/lib/RT/I18N.pm) (revision 110)
@@ -289,7 +289,7 @@
my $enc = shift;
- @_ = $str =~ m/([^=])=?([^?]+)?([QqBb])?([^?]+)?=([^=])/g;
-
@_ = $str =~ m/(.?)=?([^?]+)?([QqBb])?([^?]+)?=([^=])/gs;
return ($str) unless (@_);
@@ -338,6 +338,10 @@
$str .= $prefix . $enc_str . $trailing;
}