Shouldn’t we encode according to outgoing encoding we define in the
config? And do it using the method we use for other outgoing emails.
This should be covered with tests for latin1 chars and else chacters:
russian, chinese or something else outside latin1.On Thu, May 7, 2009 at 12:08 PM, elacour@bestpractical.com wrote:
Author: elacour
Date: Thu May 7 04:08:18 2009
New Revision: 19576
Modified:
rt/3.8/trunk/lib/RT/Interface/Email.pm
Log:
Properly MIME encode (RFC 2047) headers of forwarded messages, so for example
non ascii subject are properly displayed in MUA.
Modified: rt/3.8/trunk/lib/RT/Interface/Email.pm
— rt/3.8/trunk/lib/RT/Interface/Email.pm (original)
+++ rt/3.8/trunk/lib/RT/Interface/Email.pm Thu May 7 04:08:18 2009
@@ -622,7 +622,7 @@
);
}
- $mail->head->set( $_ => $args{ $_ } )
- $mail->head->set( $_ => Encode::encode(‘MIME-Header’, $args{ $_ }) )
foreach grep defined $args{$_}, qw(To Cc Bcc);
$mail->attach(
@@ -643,8 +643,8 @@
$from = $obj->QueueObj->CorrespondAddress
|| RT->Config->Get(‘CorrespondAddress’);
}
- $mail->head->set( Subject => “Fwd: $subject” );
- $mail->head->set( From => $from );
- $mail->head->set( Subject => Encode::encode(‘MIME-Header’, “Fwd: $subject”) );
- $mail->head->set( From => Encode::encode(‘MIME-Header’, $from) );
my $status = RT->Config->Get('ForwardFromUser')
# never sign if we forward from User
Rt-commit mailing list
Rt-commit@lists.bestpractical.com
rt-commit Info Page
Best regards, Ruslan.
Shouldn’t we encode according to outgoing encoding we define in the
config? And do it using the method we use for other outgoing emails.
This should be covered with tests for latin1 chars and else chacters:
russian, chinese or something else outside latin1.
In this patch, I’m just fixing headers of the mail forward (not the
forwarded email). And as it is made of forwarded email subject that may
contain non ascii chars and as it’s possible to have To/Cc/Bcc that
contains a name with non-ascii chars, I encoded those headers with rfc
2047.
But maybe it’s possible to use same code as other outgoing emails, but
that needs whole refactoring of forward method.
Ok. I should look into it and really think it’s time to release 3.8.3.
As this is not a regression since 3.8.0 where it’s broken in the same
way as in 3.8.2, so I don’t think this should block 3.8.3.On Sat, May 9, 2009 at 12:25 PM, Emmanuel Lacour elacour@easter-eggs.com wrote:
On Sat, May 09, 2009 at 12:42:15AM +0400, Ruslan Zakirov wrote:
Shouldn’t we encode according to outgoing encoding we define in the
config? And do it using the method we use for other outgoing emails.
This should be covered with tests for latin1 chars and else chacters:
russian, chinese or something else outside latin1.
In this patch, I’m just fixing headers of the mail forward (not the
forwarded email). And as it is made of forwarded email subject that may
contain non ascii chars and as it’s possible to have To/Cc/Bcc that
contains a name with non-ascii chars, I encoded those headers with rfc
2047.
But maybe it’s possible to use same code as other outgoing emails, but
that needs whole refactoring of forward method.
Best regards, Ruslan.
Ok. I should look into it and really think it’s time to release 3.8.3.
As this is not a regression since 3.8.0 where it’s broken in the same
way as in 3.8.2, so I don’t think this should block 3.8.3.
I created a branch forward-with-transaction for some post-3.8.3
work so this may want to happen on that branch or on a separate
feature branch. I’m probably going to take these commits and
move them onto a branch and out of the 3.8.3-releng branch
and trunk later today if I can.
-kevin