Encode content for textual "message/..." attachments

If $TreatAttachedEmailAsFiles is true, message-like attachments wouldn't
be split into parts in RT database, in which case "OriginalContent"
could return decoded strings(with utf-8 flag on), which "ContentAsMIME"
doesn't like(it feeds OriginalContent to MIME::Body::Scalar) and could
cause the following warning(when there are some non-ascii chars):

    Strings with code points over 0xFF may not be mapped into in-memory file handles

Even worse, it dies if you stringify the returned MIME::Entity object:

    open body: Invalid argument at .../MIME/Entity.pm line 1897.

This commit fixes the issue by encoding content accordingly.

1 files changed, 8 insertions, 2 deletions

diff --git a/lib/RT/Attachment.pm b/lib/RT/Attachment.pm
index e51a9b7073..858c42907f 100644
--- a/lib/RT/Attachment.pm
+++ b/lib/RT/Attachment.pm
@@ -376,8 +376,14 @@ sub OriginalContent {
     if ($self->IsMessageContentType) {
         # There shouldn't be more than one "subpart" to a message/* attachment
         my $child = $self->Children->First;
-        return $self->Content unless $child and $child->id;
-        return $child->ContentAsMIME(Children => 1)->as_string;
+        if ( $child and $child->id ) {
+            return $child->ContentAsMIME( Children => 1 )->as_string;
+        }
+        else {
+            # No children could happen if $TreatAttachedEmailAsFiles is true.
+            # Can't indiscriminately return $self->Content as it might be decoded(for textual messages).
+            # Leave it to the follwing code, which covers this case.
+        }
     }
 
     return $self->Content unless RT::I18N::IsTextualContentType($self->ContentType);