Welcome to WebmasterWorld Guest from

Forum Moderators: coopster & jatar k & phranque

Message Too Old, No Replies

Mime::Lite error

"Strict refs"

8:39 pm on Mar 29, 2009 (gmt 0)

WebmasterWorld Senior Member rocknbil is a WebmasterWorld Top Contributor of All Time 10+ Year Member

Linux server, Fedora, moving a client from an older host to new one, using Mime:Lite for attachments. Has worked for years but in the new environment gets

Can't use string ("multipart/mixed") as a HASH ref while "strict refs" in use at /server/path/to/perl5/site_perl/5.8.8/MIME/Lite.pm line 1690.....

The difference is in setting up his server, I cpan'ed the latest version of Mime::Lite and something is different. I know this has to do with hard/soft references, but I'm just not seeing it.

I've pasted the subroutine below, it's standard Mime::Lite usage.

I set up a test bed inline, and it runs fine, but when I do this, I'm hosed. Any ideas?

Script is not using strict and is one of those legacy take-over-my-mess projects, it would take days to clean it all up to run without warnings.

sub local_mail {
my ($to,$from,$subject,$body,$attachment,$str,$msg);
($to,$from,$subject,$body,$attachment) = (@_);
$body .= qq¦
if (($attachment ne '') && (-f "$root/$datadir/$attachment")) {
$msg = MIME::Lite->new(
From => "$from",
To => "$to",
Subject => "$subject",
Type => 'multipart/mixed'
Type => 'TEXT',
Data => "$body"
Type => 'application/octet-stream',
Path => "$root/$datadir/$attachment",
Filename => "$attachment",
Disposition => 'attachment'
else {
$msg = MIME::Lite->new(
From => "$from",
To => "$to",
Subject => "$subject",
Data => "$body"
$str = $msg->as_string;
10:32 pm on Mar 29, 2009 (gmt 0)

5+ Year Member

I would try removing the scrub method.....


Instance method. This is Alpha code. If you use it, please let me know how it goes. Recursively goes through the "parts" tree of this message and tries to find MIME attributes that can be removed. With an array argument, removes exactly those attributes; e.g.:

Besides that I see nothing in your snippet that would produce the error.

10:43 pm on Mar 29, 2009 (gmt 0)

WebmasterWorld Senior Member rocknbil is a WebmasterWorld Top Contributor of All Time 10+ Year Member

Thanks krugs, but I doubt scrub is it, that just clears headers from the message . . . note it dies at trying to set Type (which can be a hash, for multiple attachments . . . )

However, I have a "workaround," it's just not a GOOD one.

I commented out the strict line at the head of Mime:Lite. This isn't a solution . . . it should run under strict. But now my programs are all working this way.

What's odd, like I say, in an "inline" test bed, it was fine. It only croaks when I put it in a subroutine. I tried another experiement with a simplified version, extracted from my program, and it ran . . . just never sent any mail.

I figure it's a problem with the way the original program is coded. Still on the blocks, haven't given up on setting it right, but it's off my desk . . for today.

5:02 am on Mar 30, 2009 (gmt 0)

5+ Year Member

Did you try removing srub? Because when I looked in the source of MIME::Lite the line number where the error occurs appears to be in the scrub methods code. And the problem does appear to be associated with the headers.

site_perl/5.8.8/MIME/Lite.pm line 1690 <-----

7:17 pm on Mar 31, 2009 (gmt 0)

WebmasterWorld Senior Member rocknbil is a WebmasterWorld Top Contributor of All Time 10+ Year Member

Thank you krugs, honestly it was at the end of a 12 hour day on a pro-bono project and I was at that point of patching it and getting out. I didn't go that deep into the module.

However, I returned to it today and as you say, removing scrub worked - but when it's inline, and not in a subroutine, scrub() works without a hitch. (Also allowed me to return to use strict; in the module, whew . . . )

Unfortunately, this is a vital piece for this project; the emails *must* be plain text with attachments. If you don't scrub() it will give you this prior to the mail body:

Content-Disposition: inline
Content-Length: 2005
Content-Transfer-Encoding: binary
Content-Type: text/plain

I got most of it to work by specifying the headers to scrub,

$msg->scrub(['content-disposition', 'content-length','content-transfer-encoding','content-type']);

which now leaves me with this, which is equally ugly:

This is a multi-part message in MIME format.

So, for the time being, they're going to have to live with the content headers in the mail body.

Because of the inline/subroutine puzzle, I still think it's something in the original program (not the mime module.)

This is why I don't like using modules. :-(

P/S., I remember that "alpha code" comment from years ago . . . when it WORKED . . . figured it was just a legacy oversight in the documentation.

2:22 am on Apr 1, 2009 (gmt 0)

5+ Year Member

Weird, I have no idea why being in a subroutine would cause different behavior. Sorry about the pro-bono work. My last project turned out to be pro-bono too, because the jerk took my work and never paid me! $1,000 worth of time, thats the last time I trust anyone again, from now on I use an escrow service or the custmer pays upfront.
2:40 pm on Apr 1, 2009 (gmt 0)

WebmasterWorld Senior Member rocknbil is a WebmasterWorld Top Contributor of All Time 10+ Year Member

Well, this one is volunteer work. I've had my share of "oops I stepped in it's." But in this case, it's one of the projects I volunteered to a good cause . . .

I just hate leaving issues unresolved, for the time being it's "working" but not "right."


Featured Threads

Hot Threads This Week

Hot Threads This Month