Thanks for the replies everyone, so far I have got it working to my satisfaction, but the browser has other ideas, I'm using CGI::Application so the sub in question (with hard coded parameters) is below:

sub do_download {
        my $self = shift;
        my $post = $self->query();
        my $fname = "/storage/surtron/cda/clients/ryan/new/surtron-020
+130-01.zip";
        my $fsize = -s $fname;
        $self->header_props(    -type => "application/octet-stream",
                                -attachment => "blahblah2123.zip",
                                -Content_length => $fsize);
        open(READ,$fname) || die;
        my @fcontent = <READ>;
        close(READ);
        return "@fcontent";
}
[download]

The above code correctly produces the following output

Content-Disposition: attachment; filename="blahblah2123.zip"
content-length: 139124
Content-Type: application/octet-stream

PK {rest of zip file}
[download]

Evidently the browser is not honouring the Disposition header, I'm testing it will IE 6.0.2600.0000. Any further ideas?

Update:
There is a MS support article on this for IE 5.5: FIX: "Content-Disposition: Attachment" Fails for Known Content Types (Q267991) HERE

I just went for a drive to test IE 5.5 with the fix, it recognises it needs to download, then pops up 2 prompts, one for the name of the CGI and one for the name passed in the Disposition header, then it saves the file in some unknown format which winzip doesn't like. Hmmm is there any hope?

Could the code I have provided possibly mangle the data in any way so as to cause it to be an invalid zip file? When I try to recover the zip file I can recover the first 2 files out of the 5 in the archive.

More Updating:
I just changed the code to a crude:

my $filecat = `cat /blah/blah/whatever`;
return $filecat;
[download]

and now it all works :-)