Unluckily, your suggestion doesn't seems to work. I managed to substitute chars, but parts() method starts complaining for the raw string, as you already guessed in your comments. That's why I tried to modify as following:

..
print Dumper \$ent;

my $aref=[];
my $oldr=$ent->{mail_inet_head}->{mail_hdr_list};
foreach (@$oldr){
  my $n=$_;
  $n=~s/\n/\r\n/g;
  push(@$aref,$n);
}

$ent->{mail_inet_head}->{mail_hdr_list}=$aref;
#       exit;

my $result = SOAP::Lite
          ->packager(SOAP::Packager::MIME->new)
          ->parts([$ent])
          ->proxy($create_proxy, ssl_opts => [ SSL_verify_mode => 1, S
+SL_ca_file => '/root/Firefox_CERT/CUSTOMERROOTCA2'] )
          ->call($header, $method => @data)
;
[download]

This actually override \n in header section, but the request is still not accepted by remote server throwing a 500 error. I'm still confused because MIME::Entity is only building a little block of the final HTTP request (the encoded binary file with his headers), I guess SOAP::Packager is adding lot of things like multipart etc. I'll try to deepen with curl changing only 1 row at a time to see which section of the request is causing the behaviour. In the meanwhile, suggestions are welcome

Looking at the source code of SOAP::Packager::MIME, the meat of it seems to be the sub ->package, which adds some headers to the MIME entity and after that calls $top->stringify_body;. So maybe the main trick is to use your own MIME::Entity subclass which has a better ->stringify_body:

package MIME::Entity::Ray;
use strict;
use parent 'MIME::Entity';
sub stringify_body {
    my( $self ) = @_;
    my $body = $self->SUPER::stringify_body();
    $body =~ s!\n!\r\n!g;
    return $body
};
[download]

And then instead of creating your own MIME::Entity objects create MIME::Entity::Ray objects instead.

If that still fails, maybe something else is creating MIME::Entity objects. Then either edit the source code or monkey patch MIME::Entity:

use MIME::Entity;
my $old_stringify_body = \&MIME::Entity::stringify_body;

*MIME::Entity::stringify_body = sub {
    my( $self ) = @_;
    my $body = $self->SUPER::stringify_body();
    $body =~ s!\n!\r\n!g;
    return $body
};
[download]

Update: After looking some more at SOAP::Packager, it even tries to do the Right Thing by setting:

   local $MIME::Entity::BOUNDARY_DELIMITER = "\r\n";
[download]

except that MIME::Entity does not use that variable.

The real solution would be to make MIME::Entity use that variable.

Update: Reply rewrote after several attempts.

First: As you say, the module seems to ignore the variable it even if it is mentioned in the module changelog.

I tried first solution, it is again not working. However, I cannot see any CRLF characters in the body section..and that is strange. Based on my test with curl, I suspect I should modify the boundary string of the main envelope section(see previous update) to add CRLF as exepcted by axis2 apache server. Of course I have no clue on how to do this in perl. That's why in the meanwhile I'm working on a simple sh implementation with the hardcoded request. I m unable to try your second suggestion it is actually, raising:

Can't locate object method "stringify_body" via package "main::SUPER" at ./AR_Create.pl_ATTACHMENTS_WIP line 7.

Here is the whole HTTP request with minimum CRLF characters expected by remote server I'm actually using with curl

This is a multi-part message in MIME format...

------------=_1482923885-24696-0^M
Content-Type: text/xml
Content-Disposition: inline
Content-Location: /main_envelope
Content-ID: <main_envelope>

<?xml version="1.0" encoding="UTF-8"?><soap:Envelope 
..SOAP STUFF CUTTED OUT
</soap:Envelope>^M
------------=_1482923885-24696-0^M
Content-Type: application/octet-stream; name="uu.gif"
Content-Disposition: attachment; filename="uu.gif"
Content-Transfer-Encoding: binary
MIME-Version: 1.0
X-Mailer: MIME-tools 5.508 (Entity 5.508)

------------=_1482923885-24696-0--
GIF89a^P^@^P^@¢ÿ^@ÿÿÿ999kkkÂ~LÂ~LÂ~LÃ~@Ã~@Ã~@Ã~NÃ~NÃ~Nççç^@^@^
+@!ù^D^A^@^@^D^@,^@^@^@^@^P^@^P^@^@^CBHºÃ~\¾ã^U@k1±Ã~MJ'Ã~V\W^TDÂ
+¦laÂ| ^FÃ~L4^\pÂ¥^H-pÂ~DÂ~TA/.|s»^S^NX{Ã~EÂ~H<Ã~[^P^P$ôÂ~NÂ~U&j(]RÂ
+~Z%Â~Av»e-^R^@;
------------=_1482923885-24696-0--
[download]

This is the HTTP request that works. You may see where CRLF is expected. Surpisngly seems to be useful only in first multipart section, the one carrying SOAP request.3 damn characters are blocking my plan..LOL

diff --git a/usr/local/share/perl5/MIME/Entity.pm
b/usr/local/share/perl5/MIME/Entity.pm
index 3006853..ddfeb6c 100644
--- a/usr/local/share/perl5/MIME/Entity.pm
+++ b/usr/local/share/perl5/MIME/Entity.pm
@@ -1828,9 +1828,9 @@ sub print_body {
        ### Parts:
        my $part;
        foreach $part ($self->parts) {
-           $out->print("--$boundary\n");
+           $out->print("--$boundary\r\n");
            $part->print($out);
-           $out->print("\n");           ### needed for next delim/clo
+se
+           $out->print("\r\n");           ### needed for next delim/c
+lose
        }
        $out->print("--$boundary--\n");
[download]

I confirm the "bug" is in the print_body sub of MIME::Entity, in the part where it adds boundaries string to the body. I'm sure with the proposed patch will work with apache axis but peraphs will broke compatibility with other systems. What to do in those cases? Should I open a bug request somewhere?