[Mimedefang] $fname in filter() is an array reference

Matt Garretson mattg at assembly.state.ny.us
Mon Mar 1 18:05:38 EST 2010


I've noticed this for a while, but have only now gotten around to 
looking into it.  Maybe it doesn't matter, but I just figured I'd 
mention it.  This is MD version 2.68 on Fedora 12 (as well as
previous versions of both) ...

In mimedefang-filter, both filter() and filter_multipart() are 
passed a value ($fname in the example filter) that is supposed to 
be a string containing a suggested filename for the entity. 
However, what's really getting passed is an array reference. (If 
you print $fname, you'll get "ARRAY(0x3ee5968)" or some such.)

I think this is because of the way $fname is defined in
rebuild_entity() in mimedefang.pl :

    my($fname) = takeStabAtFilename($in);

My understanding is that the parens cause takeStabAtFilename() to 
be called in a list context, which in turn for is causing MIME-tools' 
decode_mimewords() to return an array rather than a scalar. The 
attached trivial patch to mimedefang.pl.in ditches the parens, 
causing $fname to be a scalar string as documented within MIMEdefang.

Now, the man page for MIME::Words says that forcing decode_mimewords()
to return a scalar is "probably not what you want", but it certainly
is easier to deal with, and it matches the MD's comments and docs.

I don't know what bad side effects my patch might cause, but 
hopefully those smarter than I here can shed some light on it.

Thanks!
-Matt
-------------- next part --------------
--- mimedefang.pl.in-SAVE       2010-02-24 09:55:03.000000000 -0500
+++ mimedefang.pl.in    2010-03-01 17:50:04.582972551 -0500
@@ -824,7 +824,7 @@
     my($type) = $in->mime_type;
     $type =~ tr/A-Z/a-z/;
     my($body) = $in->bodyhandle;
-    my($fname) = takeStabAtFilename($in);
+    my $fname = takeStabAtFilename($in);
     $fname = "" unless defined($fname);
     my $extension = "";
     $extension = $1 if $fname =~ /(\.[^.]*)$/;


More information about the MIMEDefang mailing list