RT 3.0.2pre3: same problems with charsets

Hi all,

The problem needs some more debuggugging, and here’s the status:

– When the message comes with the headers as follows:
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The Latin characters are processed OK into the queue, and displayed
properly. But the autoreply message contains unconverted Latin1 text,
in a message marked with charset=“utf-8”. As a result, the recipient’s
mailer displays some nonsence.

– When the message comes with these headers:

Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 8bit

(the same way with charset=“iso-8859-1”) the message loses its content,

(sorry for my prevuos message, too eraly pressed “send”)

Hi all,

The problem needs some more debuggugging, and here’s the status:

– When the message comes with the headers as follows:
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The Latin characters are processed OK into the queue, and displayed
properly. But the autoreply message contains unconverted Latin1 text,
in a message marked with charset=“utf-8”. As a result, the recipient’s
mailer displays some nonsence.

– When the message comes with these headers, and some non-ASCII
characters in the body:

Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 8bit

(the same way with charset=“iso-8859-1”) the message loses its content,
subject, and requestor. As a result, the empty ticket is created.

Regards,
Stan

Content-Type: text/plain;
charset=“Windows-1252”
Content-Transfer-Encoding: 8bit

(the same way with charset=“iso-8859-1”) the message loses its content,
subject, and requestor. As a result, the empty ticket is created.

the way the charsets are processed now is wrong, wrong, wrong!

The whole message body is handed as-is to the web interface,
and share/html/autohandler tries to convert to Unicode something that
it has no idea about. Of course, it fails to do so on 8-bit message body,
and it becomes empty after
$ARGS{$key} = Encode::decode(‘utf-8’,$ARGS{$key}, Encode::FB_PERLQQ);

The message content encoding must be processed BEFORE giving it to
Mason. rt-mailgate process is the best place to do so.

By the way, does rt-mailgate defer the message if Apache isn’t running?
I couldn’t find anything like that in the code.

Regards,
Stanislav

Stanislav,

By the way, does rt-mailgate defer the message if Apache isn’t running?
I couldn’t find anything like that in the code.

Yes it does, however on RT 3.0.0, it was duplicating messages. It may be
fixed on 3.0.1 or 3.0.2.

I just experienced this. Tried to send a pdf attachment into one of my
queues and it looped on sendmail with the EX_TEMPFAIL. I now have 10
copies of this email in my box and 10 copies of the pdf attached to the
case. I finally manually removed the mail message from sendmails queue.

Running on linux (redhat 7.2 + some customization)
perl 5.6.1
sendmail 8.11.6
rav antivirus
RT 3.0.2pre3

Argh. Not a good thing for my customers to get multiple copies of
emails.

TedOn Wed, 2003-04-23 at 11:53, bill@daze.net wrote:

Stanislav,

By the way, does rt-mailgate defer the message if Apache isn’t running?
I couldn’t find anything like that in the code.

Yes it does, however on RT 3.0.0, it was duplicating messages. It may be
fixed on 3.0.1 or 3.0.2.

From is an excerpt from one of my messages to the rt-users list about it:

“RT correctly issued EX_TEMPFAIL responses, but when RT came back up, we
received one copy of the message for each EX_TEMPFAIL response that was
sent and one copy for the successful send.”

Ref: http://lists.fsck.com/pipermail/rt-users/2003-April/012951.html


rt-devel mailing list
rt-devel@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-devel
Ted Serreyn
Serreyn Network Services, LLC
http://www.serreyn.com/