Hi,
We ran into an issue after a clean install of RT 3.4.1 (and RTIR 1.1.5).
An external commercial ticket tracking system another part of our
organization uses was no longer able to process incoming email from RT.
It had previously processed mail sent from RT 3.2.2 correctly.
Digging through the mail headers we saw two basic differences between
the two systems. We changed $EmailOutputEncoding to ‘us-ascii’ per the
RT_SiteConfig.pm, but were unable to manually specify the
content-transfer-encoding.
It looks like RT 3.2.2 had not specified the content-transfer-encoding,
but 3.4.1 now specified it as 8bit. This other commercial ticket
tracking system needed messages to be encoded as 7bit, for some reason.
I manually made this change:
/rt3/lib/RT/I18N.pm
$head->mime_attr( “content-type” => ‘text/plain’ )
unless ( $head->mime_attr(“content-type”) );
$head->mime_attr( “content-type.charset” => $enc );
# ADDED FOLLOWING ONE LINE
-
$head->mime_attr( "content-transfer-encoding" => "7bit" ); $entity->bodyhandle($new_body);
And it worked fine: outgoing mail is now encoded as 7bit, and the
commercial system reads our mail.
I am not sure if this was a local problem, or something that other users
will run into. Is it possible to assign content-transfer-encoding to a
variable that can be set in the RT_SiteConfig? I am a terrible mail
encoding, perl, and everything else newbie so I may have missed some
easier way to do this. 
Phil