MIME::Field::ParamVal doesn't use warnings itself, so it is only warning because the original poster running using the -w switch (or is turning on warnings with the $^W variable.) Removing the -w and putting "use warnings" in the main script instead should fix the problem (by disabling any warnings from all modules that didn't explicitly enable them), as would:

BEGIN {
    local $^W = 0;
    require MIME::Field::ParamVal;
}
[download]

I don't think that workaround will work

Oops, my bad. Indeed, your suggested mechanism should work far better.

Incidentally, this warning is removed as of 5.8.1, but is still in bleadperl; is this intentional?

I would expect so, but I'd have to check back through the voluminous discussions around this to be certain. I think the intention is that in 5.10 the various v-string syntaxes will generate a version object, and require VERSION; will simply DTRT.

Hugo

I would doubt this fix will make your program work correctly, since all it is doing is suppressing an otherwise irrelevant warning. (And please note the correct version of that workaround supplied in the comment from ysth.)

I would suspect that as a result of installing MIME::Parser, a simpler heuristic for validating an email address has been replaced with something that tries to be more precise, but in the process loses the ability to cope with IP address as domain.

One possible approach (which might be a good idea anyway) would be to replace the dotted IP addresses with names. However there are reasons you might be unable or unwilling to do that.

My guess is that the error message is coming from Mail::Address->_tokenise(), called by parse(), but I haven't analysed the code to determine why it is giving the error: certainly a standalone attempt to parse the same string seems quite happy:

  perl -MMail::Address -wle 'print Mail::Address->parse("1002\@151.104
+.234.7")'                                     
  Mail::Address=ARRAY(0x815a8bc)
[download]

.. showing that it returns a single Mail::Address object. (Does it do the same for you?)

Beyond that I can think of no obvious reason for a problem. One possible approach is to install a duplicate of the relevant modules in a space somewhere under your control, and add diagnostics (or use the debugger) to track down precisely where the problem occurs and why. Once you've gained that understanding, you should be able to determine whether it is a problem with your own code or with that in one of the modules, and resolve it either by fixing your code or supplying a rationale and patch to the relevant module maintainer and waiting for a new release.

Assuming I'm correct about the source of the error message, the starting point would be the one place in the code that mentions Mail::Address, where depending on whether the module can be loaded one of two versions of each of two subroutines is installed: extract_full_addrs() and extract_only_addrs().

(Indeed, this suggests one possible workaround, to subclass MIME::Lite and overload those two subroutines to point to the fallback methods:

  {
    package My::MIME::Lite;
    use MIME::Lite;
    our @ISA = qw/ MIME::Lite /;
    *extract_full_addrs=*MIME::Lite::my_extract_full_addrs;
    *extract_only_addrs=*MIME::Lite::my_extract_only_addrs;
  }
  $mime_msg = My::MIME::Lite->new(...);
  My::MIME::Lite->send(...);
  $mime_msg->send();
[download]

.)

Hugo

I think youll find that alas this wont work. MIME::Lite is a hybrid OO/and imperative so extract_XXXX_addrs() are called procedurally from the methods in MIME::Lite so will no actually end up using the new ones. (A good argument for NOT doing this type of hybridization IMO.) In fact its arguable I should change this so that this type of thing is easier.



---
demerphq


First they ignore you, then they laugh at you, then they fight you, then you win.
-- Gandhi