Discounting issues with the "Host" header (which in my experience, a lot of webservers will let you slide on provided you specify a fully qualified URL in the "POST/GET" line) you have pointed out something very interesting...

• The HTTP::Request::Common documentation provides a direct example of using the POST method to create a multipart request that includes a local file upload -- as of perl5.6.1 this example does not show the Content-Length header within the file piece of the multipart message.
• To my knowledge, no RFC relating to MIME Multipart Messages forbids the use of a Content-Length header within a single sub-part ... it's just redundent.

Bottom line: I don't know why the POST method is adding that header, but it shouldn't be causing your www server / CGI to complain. Do you know what is parsing the request on the server end?

Update: After looking over the docs some more, and skimming the code for the POST method, it looks like you might be able to workarround this problem by setting $HTTP::Request::Common::DYNAMIC_FILE_UPLOAD = 1; prior to calling POST. This is designed to make the HTTP::Request delay in reading the file untill it accutally needs to send it across the wire -- either because you don't want to load the whole thing in memory when you call POST, or because it's an "inifinte" file like "/dev/audio".

In any case, using it causes the Request to be devoid of all Content-Length headers (which could cause other problems).

Another thing to consider: you could try building up the content of your request using something like MIME::Lite and then set it in your request, ala...$request->content($msg->as_string)