[Rt-devel] More fun with DecodeMIMEWordsToEncoding

Florian Weimer fw at deneb.enyo.de
Wed Feb 23 10:20:16 EST 2005

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

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)

More information about the Rt-devel mailing list