it's worth noting that when this came up (on the users@ list iirc), it was
specifically related to the Message code using temp files for non-text raw
parts.  it appeared, based on the errors, that even if secure_tmpfile() failed,
Message continued on assuming the file existed, thereby causing a bunch of other
errors to pop up later on if that part was accessed.

the code looks like it's doing the right thing, but then why do the errors come
up? :)   so we should verify the issue anyway.


  if ($msg->{'type'} !~ m@^(?:text/(?:plain|html)$|message\b)@) {
    my $filepath;
    ($filepath, $msg->{'raw'}) = Mail::SpamAssassin::Util::secure_tmpfile();

    if ($filepath) {
      # The temp file was created, add it to the list of pending deletions
      # we cannot just delete immediately in the POSIX idiom, as this is
      # unportable (to win32 at least)
      push @{$self->{tmpfiles}}, $filepath;
      $msg->{'raw'}->print(@{$body});
    }
  }

  # if the part didn't get a temp file, go ahead and store the data in memory
  if (!exists $msg->{'raw'}) {
    $msg->{'raw'} = $body;
  }

This part of code has been changed during those 10 years and those errors should now be catched.