More fun with DecodeMIMEWordsToEncoding

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;
}

  • We might have \n without trailing whitespace, which will result in

  • invalid headers.

  • $str =~ s,\n,gs;
    return ($str)
    }