Hello,
We’ve just noticed that emails are lost between two separate instances
of RT when the Subject line contains national special characters or
indeed anything that causes the Subject to be converted between the
actual text and its MIME representation.
The problem seems to be caused by the conversion back from the MIME
representation adding an extra space that usually happens in the middle
of a ticket ID, breaking the ticket ID. If the two RT addresses that
are corresponding with each other are the main addresses for their
respective queues, the only problem is that a new ticket is generated.
If either of the two addresses are comment aliases, we get a “comment
aliases require a TicketID to work on” and the only place the mail
shows up in is the root mailbox of the server that rejected the request
with a broken ticket ID.
Is there a way to get the MIME conversion not to add spurious spaces?
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
Request Tracker Wiki 8/29/05, Atro Tossavainen atossava@cc.helsinki.fi wrote:
Hello,
We’ve just noticed that emails are lost between two separate instances
of RT when the Subject line contains national special characters or
indeed anything that causes the Subject to be converted between the
actual text and its MIME representation.
The problem seems to be caused by the conversion back from the MIME
representation adding an extra space that usually happens in the middle
of a ticket ID, breaking the ticket ID. If the two RT addresses that
are corresponding with each other are the main addresses for their
respective queues, the only problem is that a new ticket is generated.
If either of the two addresses are comment aliases, we get a “comment
aliases require a TicketID to work on” and the only place the mail
shows up in is the root mailbox of the server that rejected the request
with a broken ticket ID.
Is there a way to get the MIME conversion not to add spurious spaces?
–
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
The rt-users Archives
Be sure to check out the RT Wiki at http://wiki.bestpractical.com
Buy your copy of our new book, RT Essentials, today!
Download a free sample chapter from http://rtbook.bestpractical.com
Best regards, Ruslan.
Is there a way to get the MIME conversion not to add spurious spaces?
If you can put together a test that shows off the bad behaviour, it
should be pretty easy to fix.
Ruslan,
we can’t help you unless you tell us about software you use.
Good point. Sorry to have missed that initially.
I still run RT 2.0.6…
The other end runs RT 3.0.9.
Jesse,
If you can put together a test that shows off the bad behaviour, it
should be pretty easy to fix.
It appears to be the case that every email with national special
characters above ASCII 127 in the subject causes this to happen.
If I send an email to the other RT while requesting replies to arrive
in our RT with an existing ticket number from our RT already included
in the subject line, and the subject contains the letters � or �
("a or "o for the TeX-minded and ISO8859 challenged?), the subject
line gets MIME-converted, and by the time it gets back to our RT, an
extra space has been added to a seemingly random point in the subject
line, most often causing corruption of the ticket ID for our RT,
thereby either causing a new ticket to be generated (if the mail
address for our RT is one of the normal aliases), or preventing
delivery of the correspondence to RT altogether (if I requested
replies to come to the comment alias).
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
Ruslan,
we can’t help you unless you tell us about software you use.
Good point. Sorry to have missed that initially.
I still run RT 2.0.6…
The other end runs RT 3.0.9.
And perl versions? Charset support in perl 5.6 is very rudimentary, so you
may need at least 5.8 and preferably 5.8.3 or newer, as there may be some
bugs in the earlier ones.
Jan 'Bulb' Hudec <bulb@ucw.cz>
signature.asc (189 Bytes)
[ I just subscribed to the list, so I do not have previous messages
and threfore I cannot build the correct References-header. Sorry
for the incovenience this may cause. ]
Atro Tossavainen wrote:
subject line [ containing non-ASCII characters] gets MIME-converted,
and by the time it gets back to our RT, an extra space has been
added to a seemingly random point in the subject line
At the moment, I manage the RT 3.0.9 that sends messages having
sometimes encoded headers to Atro’s RT 2.0.6.
I tried analysing this problem. I found that RFC 2047 says
“An ‘encoded-word’ may not be more than 75 characters long”.
This has been taken care of in RT’s SendEmail.pm where the subject
line is split to parts having appropriate size. Then each part is
encoded and the encoded parts are catenated together using whitespace
as a delimeter. This is how the RFC tells it should be done.
Now, I think it is the decoding in 2.0.6 that’s not working properly.
Atro sees extra whitespace charachters in Subject header. Those
whitespaces are excatly at the same place where SendEmail has split
the Subject header. About decoding, RFC 2047 says
“When displaying a particular header field that contains multiple
'encoded-word’s, any ‘linear-white-space’ that separates a pair of
adjacent 'encoded-word’s is ignored.”
I think some component in RT 2.0.6 or some perl module Atro’s
installation uses does not do the decoding of encoded header lines
correctly.
Cheers,
I think some component in RT 2.0.6 or some perl module Atro’s
installation uses does not do the decoding of encoded header lines
correctly.
I could easily believe this. It’s probably worth upgrading that 2.0.6 to
a newer RT.
I could easily believe this. It’s probably worth upgrading that 2.0.6 to
a newer RT.
I’ve been holding back on this for such a long time… Maybe I should,
then. 
Atro Tossavainen (Mr.) / The Institute of Biotechnology at
Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
+358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own.
< URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS