[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