Autrijus Tang put in some heroic effort to attempt to resolve the utf8
bugs people have been experiencing. I’ve just rolled 3.0.2pre4 with his
patches. The new release needs Locale::Maketext::Lexicon 0.22, which
isn’t on cpan. I’ve uploaded a copy of it to
http://fsck.com/pub/rt/devel/
Is this release any better for people?
-j
Request Tracker — Best Practical Solutions – Trouble Ticketing. Free.
Jesse Vincent wrote:
Autrijus Tang put in some heroic effort to attempt to resolve the utf8
bugs people have been experiencing. I’ve just rolled 3.0.2pre4 with his
patches. The new release needs Locale::Maketext::Lexicon 0.22, which
isn’t on cpan. I’ve uploaded a copy of it to
http://fsck.com/pub/rt/devel/
Locale::Maketext::Lexicon 0.22 and 3.0.2pre4 installed
Is this release any better for people?
yes, it’s better - but there seems to be issues still 
My enviroment:
Redhat Linux 8.0 with apache 2.0.40 (package version 16)
perl 5.8.0
mod_perl 1.99_05
MASON dependencies:
Params::Validate 0.02…found
Cache::Cache …found
Exception::Class …found
HTML::Mason 1.16…found
MLDBM …found
Errno …found
FreezeThaw …found
Digest::MD5 …found
CGI::Cookie 1.20…found
Storable …found
Apache::Session 1.53…found
MAILGATE dependencies:
HTML::TreeBuilder …found
HTML::FormatText …found
Getopt::Long …found
LWP::UserAgent …found
CLI dependencies:
Getopt::Long 2.24…found
CORE dependencies:
Digest::MD5 …found
DBI 1.18…found
Test::Inline …found
Class::ReturnValue 0.40…found
DBIx::SearchBuilder 0.80…found
Text::Template …found
File::Spec 0.8…found
HTML::Entities …found
Net::Domain …found
Log::Dispatch 2.0…found
Locale::Maketext 1.04…found
Locale::Maketext::Lexicon 0.22…found
Locale::Maketext::Fuzzy …found
MIME::Entity 5.108…found
Mail::Mailer 1.57…found
Net::SMTP …found
Text::Wrapper …found
Time::ParseDate …found
File::Temp …found
Term::ReadKey …found
Text::Autoformat …found
Text::Quoted …found
DEV dependencies:
Regexp::Common …found
Time::HiRes …found
Test::Inline …found
WWW::Mechanize …found
MODPERL2 dependencies:
CGI 2.89…found
Apache::DBI …found
MYSQL dependencies:
DBD::mysql 2.1018…found
There seems to be problem with converting the character with incoming
mail, according to the log the mail correctly get recognized as UTF-8
but still there seems to be something turning out wrong.
By typing the Norwegian characters ‘���’ at the bottom of the mail, gets
it imported correctly into R/T.
Mail available upon request.
There seems to be a new bug around, could be that I’ve not seen it before:
when replying to a ticket, RT doesn’t seem to find the email-address of
the requestor. It seems to be finding CCs fine…
Excerpt from log:
[Mon Apr 28 01:28:33 2003] [debug]: Guessed encoding: utf8
(/usr/local/rt3/lib/RT/I18N.pm:185)
[Mon Apr 28 01:28:34 2003] [info]: RT::Scrip=HASH(0x9664f40): Couldn’t
prepare Open Tickets (/usr/local/rt3/lib/RT/Scrip_Overlay.pm:338)
[Mon Apr 28 01:28:34 2003] [info]:
rt-3.0.2pre4-69-241.10.0986919788155@bluecom.no #69/241 - Scrip 4
(/usr/local/rt3/lib/RT/Action/SendEmail.pm:91)
[Mon Apr 28 01:28:34 2003] [info]:
rt-3.0.2pre4-69-241.10.0986919788155@bluecom.no No recipients found.
Not sending. (/usr/local/rt3/lib/RT/Action/SendEmail.pm:170)
[Mon Apr 28 01:28:34 2003] [info]:
rt-3.0.2pre4-69-241.17.9168157102785@bluecom.no #69/241 - Scrip 5
(/usr/local/rt3/lib/RT/Action/SendEmail.pm:91)
[Mon Apr 28 01:28:34 2003] [info]:
rt-3.0.2pre4-69-241.17.9168157102785@bluecom.no No recipients found.
Not sending. (/usr/local/rt3/lib/RT/Action/SendEmail.pm:170)
[Mon Apr 28 01:28:34 2003] [info]:
rt-3.0.2pre4-69-241.2.68671849750952@bluecom.no #69/241 - Scrip 6
(/usr/local/rt3/lib/RT/Action/SendEmail.pm:91)
[Mon Apr 28 01:28:34 2003] [info]:
rt-3.0.2pre4-69-241.2.68671849750952@bluecom.no No recipients found.
Not sending. (/usr/local/rt3/lib/RT/Action/SendEmail.pm:170)
All the mail I’ve got sent via R/T seems to have proper encoding now.
Updating fields with norwegian characters works now, which it didn’t
with 3.0.2pre3.
Roy-Magne Mo
There seems to be problem with converting the character with incoming
mail, according to the log the mail correctly get recognized as UTF-8
but still there seems to be something turning out wrong.By typing the Norwegian characters ‘???’ at the bottom of the mail, gets
it imported correctly into R/T.Mail available upon request.
That’s the next thing in my tofix list. Please send me that mail
so I can verify my fix.
Thanks,
/Autrijus/
Autrijus Tang put in some heroic effort to attempt to resolve the utf8
bugs people have been experiencing. I’ve just rolled 3.0.2pre4 with his
patches. The new release needs Locale::Maketext::Lexicon 0.22, which
isn’t on cpan. I’ve uploaded a copy of it to
http://fsck.com/pub/rt/devel/Is this release any better for people?
Hi Jesse & Autrijus,
my problem hasn’t changed: it’s still the old autohandler, and
the message coming in charset=“iso-8859-1”, with some non-ASCII
characters in it, the empty ticket is created.
With the encoding map removed from autohandler, it converts
the charsets more or less correctly.
By the way, it would be nice in rt-mailgate, that --debug
option would cause “&DEBUG=1” added to the URL.
Cheers,
Stan
With the encoding map removed from autohandler, it converts
the charsets more or less correctly.
The reason that this works is because Perl’s default magic
behaviour on concatenating utfstrings and non-utfstrings;
the latter is silently converted via:
Encode::decode('iso8859-1', $octets)
Hence, if incoming mails are stored in anything else than
latin1, everything still breaks.
There are two ways to fix this problem: either hack rt-mailgate
so that it extracts the charset and pre-convert the whole mail
to utfstring before POSTing it to the REST receiver, or add a
special flag that inhibits utfstring conversion in autohandler,
and let the REST handler to do the dirty work.
Personally I like the second way better (so that other mailgates
won’t have to duplicate the code), but I’d like to ask Jesse’s
opinion before plunging in.
Also… What should such a flag be called? “PreserveOctets=1”?
“Decode=0”?
Thanks,
/Autrijus/
Autrijus Tang put in some heroic effort to attempt to resolve the utf8
bugs people have been experiencing. I’ve just rolled 3.0.2pre4 with his
patches. The new release needs Locale::Maketext::Lexicon 0.22, which
isn’t on cpan. I’ve uploaded a copy of it to
http://fsck.com/pub/rt/devel/
Actually, PAUSE wrecked my upload, so I changed the version number
and uploaded again. L:
:L 0.23 is on CPAN now.
Thanks,
/Autrijus/
At 4:42 PM +0800 4/28/03, Autrijus Tang wrote:
?On Sun, Apr 27, 2003 at 07:10:13PM -0400, Jesse Vincent wrote:
Autrijus Tang put in some heroic effort to attempt to resolve the utf8
bugs people have been experiencing. I’ve just rolled 3.0.2pre4 with his
patches. The new release needs Locale::Maketext::Lexicon 0.22, which
isn’t on cpan. I’ve uploaded a copy of it to
http://fsck.com/pub/rt/devel/Actually, PAUSE wrecked my upload, so I changed the version number
and uploaded again. L:Thanks,
/Autrijus/Content-Type: application/pgp-signature
Content-Disposition: inlineAttachment converted: Macintosh HD:Untitled 2 (???/----) (0011DE80)
IMHO: the CPAN network is seriously out of sync:
Tried to install L::L via a “perl -MCPAN -e shell” and did a “reload index”
(running perl 5.8.0 on a Solaris box)
On www.perl.com/CPAN it shows version 0.20 for L::L , index from
Sunday 13:15 PM
On www.cpan.org L::L isn’t available at all. (search via webmin
perlmodule installer interface, where webmin uses the index from
www.cpan.org)
Or is it just me doing somthing wrong ? ( Using the wrong repository ? )
(Perl newbie)
2 cents.
Brussels University
Pleinlaan 2
Computer Center VUB/ULB (VUBnet)
Ing. Robert Jansen
B-1050 Brussels
Belgium (Europe)
email: rjansen@vub.ac.be
Tel: +32-2-650.36.94
Secr: +32-2-650.37.38
Fax: +32-2-650.37.40
Tried to install L:
index”
(running perl 5.8.0 on a Solaris box)On www.perl.com/CPAN it shows version 0.20 for L:
Sunday 13:15 PMOn www.cpan.org L:
perlmodule installer interface, where webmin uses the index from
www.cpan.org)
PAUSE doesn’t love me, so I upped the revision to 0.24 and uploaded again.
It should be normal again after the normal 1-2 days of propagation.
/Autrijus/
so that it extracts the charset and pre-convert the whole mail
to utfstring before POSTing it to the REST receiver, or add a
special flag that inhibits utfstring conversion in autohandler,
and let the REST handler to do the dirty work.
So I went with the latter approach after Jesse’s approval.
This fix is tentative – it should work, but hadn’t been
tested outside Gedankenexperiment. I’d appreciate if somebody
can verify it.
Thanks,
/Autrijus/
Change 5508 by autrijus@autribsd on 2003/04/29 08:26:34
* fix utf8ification done in mail-gateway.
Affected files …
… //depot/RT/rt/html/REST/1.0/NoAuth/mail-gateway#6 edit
Differences …
==== //depot/RT/rt/html/REST/1.0/NoAuth/mail-gateway#6 (text) ====
@@ -31,6 +31,9 @@
use RT::Interface::Email;
my ( $status, $error, $Ticket ) = RT::Interface:
:Gateway( %ARGS);
</%init>
+<%flags>
+inherit => undef # inhibit UTF8 conversion done in /autohandler
+</%flags>
% if ($status) {
ok
% if ( $Ticket->Id ) {
Perhaps this is a different attachment bug, but I get the attached HTML
as an error message whenever I try to attach any file via the web
interface. Interestingly, email attachments seem to be incorporated
just fine. This is a new RT3 installation, 3.0.2pre3 updated to
3.0.2pre4 and now also with the patch, and I still get the same
behavior. I’m on a debain woody system, using MySQL and mod_perl 1. I
saw one report of seemingly the same bug in the list archives, which the
reporter then said he’d resolved by changing MySQL table types, but I
believe we are using modern tables, since these tables are all brand
new, so that seems unlikely to be the problem in this case. Any ideas?
Thanks,
Dan
rt-error.html (9.23 KB)
Perhaps this is a different attachment bug, but I get the attached HTML
as an error message whenever I try to attach any file via the web
interface. Interestingly, email attachments seem to be incorporated
just fine.
Even with iso8859-1 high bit characters? Great news then.
This is a new RT3 installation, 3.0.2pre3 updated to 3.0.2pre4 and now
also with the patch, and I still get the same behavior. I’m on a
debain woody system, using MySQL and mod_perl 1. I saw one report of
seemingly the same bug in the list archives, which the reporter then
said he’d resolved by changing MySQL table types, but I believe we are
using modern tables, since these tables are all brand new, so that
seems unlikely to be the problem in this case. Any ideas?
I am very sure that the update to -pre4 did not complete successfully,
since the -pre4 autohandler does not have an array dereference in line 31,
and I specfically put in a fix for that in -pre4.
Thanks,
/Autrijus/
Perhaps this is a different attachment bug, but I get the attached HTML
as an error message whenever I try to attach any file via the web
interface. Interestingly, email attachments seem to be incorporated
just fine.Even with iso8859-1 high bit characters? Great news then.
Um, hmm, maybe I misunderstood the nature of the bug. This was a
base64-encoded PDF file.
This is a new RT3 installation, 3.0.2pre3 updated to 3.0.2pre4 and now
also with the patch, and I still get the same behavior. I’m on a
debain woody system, using MySQL and mod_perl 1. I saw one report of
seemingly the same bug in the list archives, which the reporter then
said he’d resolved by changing MySQL table types, but I believe we are
using modern tables, since these tables are all brand new, so that
seems unlikely to be the problem in this case. Any ideas?I am very sure that the update to -pre4 did not complete successfully,
since the -pre4 autohandler does not have an array dereference in line 31,
and I specfically put in a fix for that in -pre4.
Hmm, I’ve since reinstalled -pre4, restarted apache, tried again, and
had exactly the same result. I’ve diffed the autohandler in our RT
directory (the path referred to in the error message is correct) with
the one in the -pre4 distribution, and they’re the same (and indeed
different than the one in the -pre3 distribution.) I feel like I must
be missing something obvious, but I haven’t yet figured out what. We
still get the same error.
(Grasping at straws here, is it conceivable that dynamically loaded
mod_perl is the problem?)
-Dan
I am very sure that the update to -pre4 did not complete successfully,
since the -pre4 autohandler does not have an array dereference in line 31,
and I specfically put in a fix for that in -pre4.Hmm, I’ve since reinstalled -pre4, restarted apache, tried again, and
had exactly the same result. I’ve diffed the autohandler in our RT
directory (the path referred to in the error message is correct) with
the one in the -pre4 distribution, and they’re the same (and indeed
different than the one in the -pre3 distribution.) I feel like I must
be missing something obvious, but I haven’t yet figured out what. We
still get the same error.
Interestingly, I have now managed to attach a file (a JPEG,
specifically, since that’s what I had handy) from the web UI by
replacing 3.0.2pre4’s autohandler with 3.0.0’s autohandler. This same
file could not be successfully attached with the web UI with the
autohandler from 3.0.2pre4.
This also serves as a sanity check that RT wasn’t secretly using a copy
of autohandler from another path, making my 3.0.2pre4 update
non-functional before. Not that I really thought this was happening,
but it’s nice to definitively eliminate the possibility.
I will leave the actual details of how the piece of perl on line 31 of
3.0.2pre4 could produce the error in question, since I am hardly a perl
guru.
-Dan
So I went with the latter approach after Jesse’s approval.
This fix is tentative – it should work, but hadn’t been
tested outside Gedankenexperiment. I’d appreciate if somebody
can verify it.
It works!
The message sent in 8bit Latin1 was accepted, the ticket text
is displayed correctly, and the autoreply has the correct encoding.
Bravo!
Stan
Hi,
while testing Atrijus’ patch, I found the following messages in
rt.log when I added the correspondence by e-mail (I am the requestor,
and nobody is the owner). I didn’t yet notice the side effects, perhaps
they will be seen when there’s an owner:
[Wed Apr 30 07:17:09 2003] [info]: Ticket 97 created in queue ‘rt’ by ssinyagin
(/opt/rt3/lib/RT/Ticket_Overlay.pm:598)
[Wed Apr 30 07:17:19 2003] [debug]: limiting to 50 rows (/opt/rt3/lib/RT/Interf
ace/Web.pm:567)
[Wed Apr 30 07:22:13 2003] [debug]: Found a ticket ID. It’s 97 (/opt/rt3/lib/RT
/Interface/Email.pm:156)
[Wed Apr 30 07:22:13 2003] [info]: RT::Scrip=HASH(0x10b1e80): Couldn’t prepare
Open Tickets (/opt/rt3/lib/RT/Scrip_Overlay.pm:338)
[Wed Apr 30 07:22:14 2003] [info]: <rt-3.0.2pre4-97-348.9.38339629810606@as8833
.net> #97/348 - Scrip 4 (/opt/rt3/lib/RT/Action/SendEmail.pm:91)
[Wed Apr 30 07:22:15 2003] [info]: <rt-3.0.2pre4-97-348.9.38339629810606@as8833
.net> No recipients found. Not sending.
(/opt/rt3/lib/RT/Action/SendEmail.pm:170)
[Wed Apr 30 07:22:15 2003] [info]: <rt-3.0.2pre4-97-348.8.99333280018581@as8833
.net> #97/348 - Scrip 5 (/opt/rt3/lib/RT/Action/SendEmail.pm:91)
[Wed Apr 30 07:22:16 2003] [info]: <rt-3.0.2pre4-97-348.8.99333280018581@as8833
.net> No recipients found. Not sending.
(/opt/rt3/lib/RT/Action/SendEmail.pm:170)
[Wed Apr 30 07:25:51 2003] [debug]: Converting ‘Windows-1252’ to ‘utf-8’ (/opt/
rt3/lib/RT/I18N.pm:204)
[Wed Apr 30 07:25:51 2003] [debug]: Found a ticket ID. It’s 97 (/opt/rt3/lib/RT
/Interface/Email.pm:156)
[Wed Apr 30 07:25:52 2003] [info]: RT::Scrip=HASH(0x15445d4): Couldn’t prepare
Open Tickets (/opt/rt3/lib/RT/Scrip_Overlay.pm:338)
[Wed Apr 30 07:25:52 2003] [info]: <rt-3.0.2pre4-97-349.2.93799292896246@as8833
.net> #97/349 - Scrip 4 (/opt/rt3/lib/RT/Action/SendEmail.pm:91)
[Wed Apr 30 07:25:53 2003] [info]: <rt-3.0.2pre4-97-349.2.93799292896246@as8833
.net> No recipients found. Not sending.
(/opt/rt3/lib/RT/Action/SendEmail.pm:170)
[Wed Apr 30 07:25:54 2003] [info]: <rt-3.0.2pre4-97-349.14.0524853344174@as8833
.net> #97/349 - Scrip 5 (/opt/rt3/lib/RT/Action/SendEmail.pm:91)
[Wed Apr 30 07:25:54 2003] [info]: <rt-3.0.2pre4-97-349.14.0524853344174@as8833
.net> No recipients found. Not sending.
(/opt/rt3/lib/RT/Action/SendEmail.pm:170)— Stanislav Sinyagin ssinyagin@yahoo.com wrote:
The message sent in 8bit Latin1 was accepted, the ticket text
is displayed correctly, and the autoreply has the correct encoding.
Bravo!
I will leave the actual details of how the piece of perl on line 31 of
3.0.2pre4 could produce the error in question, since I am hardly a perl
guru.
I’d really like to see what does line 31 on your 3.0.2pre4’s autohandler
says. 
Thanks,
/Autrijus/
I will leave the actual details of how the piece of perl on line 31 of
3.0.2pre4 could produce the error in question, since I am hardly a perl
guru.I’d really like to see what does line 31 on your 3.0.2pre4’s autohandler
says.
OK, now it is time for me to feel dumb. But still very puzzled, since I
haven’t figured out in the slightest what was really going on. First of
all, the autohandler in question was really a 3.0.2pre4 autohandler, bog
standard. I swear up and down. I had replaced the 3.0.2pre3
autohandler with it, I had restarted apache in all conceivable ways, it
didn’t fix anything. I had tried different web browsers. No luck
attaching things from the web form, with any attachment that I trid.
Then I replaced 3.0.2pre4’s autohandler with 3.0.0’s autohandler, and it
Just Worked. I’m pretty sure I didn’t even restart apache before I
tried this the first time, though that was really late last night and I
unfortunately can’t say for sure.
But now, of course, with 3.0.2pre4’s autohandler in place again, it
continues to work, both before and after apache restart.
One obvious question is whether there’s any chance for an old copy of
something like this to be cached by mod_perl? I would imagine that very
unlikely across an apache restart, but it’s hard to think of other
explanations for what I saw. And I’m pretty sure that I’m not just
hallucinating.
Also, as several people seem to have mentioned, attaching files from the
jumbo form seems to just silently ignore the files, but I imagine that’s
a different bug than the one we’re talking about here.
-Daniel
P.S. Just for kicks, the answer to your original question is that line
31 of my autohandler is the third line of code below. It certainly
doesn’t appear to have an array reference. I think it’s clear that this
wasn’t the problem.
my $type = ref($_);
(!$type)
? Encode::decode(utf8 => $_, Encode::FB_PERLQQ) :
($type eq 'ARRAY')
? [ map { ref($_) ? $_ : Encode::decode(utf8 => $_,
Encode::FB_PERLQQ) } @$_ ] :
($type eq ‘HASH’)
? { map { ref($) ? $ : Encode::decode(utf8 => $,
Encode::FB_PERLQQ) } %$ } : $_
} %ARGS;
Hmm, could PerlFreshRestart have something to do with this? It was
turned on, I guess from following the RT2 installation instructions, but
I notice the RT3 instructions don’t mention it. Also, I had forgotten
to add the AddDefauoltCharset UTF-8 directive, and I wonder if this
helped trigger the bug (though that’s more vague speculation.) I found
some generic warnings on the web about PerlFreshRestart, but they didn’t
really explain what the danger was. Do I want to keep this turned off
now?
Thanks,
Daniel
But now, of course, with 3.0.2pre4’s autohandler in place again, it
continues to work, both before and after apache restart.
With mod_perl, it’s more deterministic if you do an explicit apache
stop, apache start, instead of a restart which often just sends a
signal.
Hi,
while testing Atrijus’ patch, I found the following messages in
rt.log when I added the correspondence by e-mail (I am the requestor,
and nobody is the owner). I didn’t yet notice the side effects, perhaps
they will be seen when there’s an owner:[Wed Apr 30 07:17:09 2003] [info]: Ticket 97 created in queue ‘rt’ by ssinyagin
(/opt/rt3/lib/RT/Ticket_Overlay.pm:598)
[Wed Apr 30 07:17:19 2003] [debug]: limiting to 50 rows (/opt/rt3/lib/RT/Interf
ace/Web.pm:567)
[Wed Apr 30 07:22:13 2003] [debug]: Found a ticket ID. It’s 97 (/opt/rt3/lib/RT
/Interface/Email.pm:156)
[Wed Apr 30 07:22:13 2003] [info]: RT::Scrip=HASH(0x10b1e80): Couldn’t prepare
Open Tickets (/opt/rt3/lib/RT/Scrip_Overlay.pm:338)
[Wed Apr 30 07:22:14 2003] [info]: <rt-3.0.2pre4-97-348.9.38339629810606@as8833
.net> #97/348 - Scrip 4 (/opt/rt3/lib/RT/Action/SendEmail.pm:91)
[Wed Apr 30 07:22:15 2003] [info]: <rt-3.0.2pre4-97-348.9.38339629810606@as8833
.net> No recipients found. Not sending.
(/opt/rt3/lib/RT/Action/SendEmail.pm:170)
[Wed Apr 30 07:22:15 2003] [info]: <rt-3.0.2pre4-97-348.8.99333280018581@as8833
.net> #97/348 - Scrip 5 (/opt/rt3/lib/RT/Action/SendEmail.pm:91)
[Wed Apr 30 07:22:16 2003] [info]: <rt-3.0.2pre4-97-348.8.99333280018581@as8833
.net> No recipients found. Not sending.
(/opt/rt3/lib/RT/Action/SendEmail.pm:170)
[Wed Apr 30 07:25:51 2003] [debug]: Converting ‘Windows-1252’ to ‘utf-8’ (/opt/
rt3/lib/RT/I18N.pm:204)
[Wed Apr 30 07:25:51 2003] [debug]: Found a ticket ID. It’s 97 (/opt/rt3/lib/RT
/Interface/Email.pm:156)
[Wed Apr 30 07:25:52 2003] [info]: RT::Scrip=HASH(0x15445d4): Couldn’t prepare
Open Tickets (/opt/rt3/lib/RT/Scrip_Overlay.pm:338)
[Wed Apr 30 07:25:52 2003] [info]: <rt-3.0.2pre4-97-349.2.93799292896246@as8833
.net> #97/349 - Scrip 4 (/opt/rt3/lib/RT/Action/SendEmail.pm:91)
[Wed Apr 30 07:25:53 2003] [info]: <rt-3.0.2pre4-97-349.2.93799292896246@as8833
.net> No recipients found. Not sending.
(/opt/rt3/lib/RT/Action/SendEmail.pm:170)
[Wed Apr 30 07:25:54 2003] [info]: <rt-3.0.2pre4-97-349.14.0524853344174@as8833
.net> #97/349 - Scrip 5 (/opt/rt3/lib/RT/Action/SendEmail.pm:91)
[Wed Apr 30 07:25:54 2003] [info]: <rt-3.0.2pre4-97-349.14.0524853344174@as8833
.net> No recipients found. Not sending.
(/opt/rt3/lib/RT/Action/SendEmail.pm:170)
The message sent in 8bit Latin1 was accepted, the ticket text
is displayed correctly, and the autoreply has the correct encoding.
Bravo!
try this:
==== //depot/RT/rt/lib/RT/Action/SendEmail.pm#28 (text) ====@@ -392,9 +392,6 @@
else {
$self->SetHeader( ‘From’, $replyto );
}
# TODO: this "via RT" should really be site-configurable.
$self->SetHeader( 'From', "\"$friendly_name via RT\" <$replyto>" );
}
unless ( $self->TemplateObj->MIMEObj->head->get(‘Reply-To’) ) {
plasma
�_���I���ڦ^�a���A��
http://edm-prg.epaper.com.tw/click.php?ad_code=5649
PChome�ʪ��G�x�W�Ĥ@���ʪ������I
http://shopping.pchome.com.tw/