Hello!
At our site we have several PINE users, which send email into the RT
Mailgateway. Some of them mis configured there system to use UTF-8,
even if there System don’t support it.
So this i think is the cause for the mails we got.
Bug: RT-Mailgateway receives the email, and without a line in the log
it just kills the whole content of the mail. The result is an empty
ticket.
My mailclient (alpine and evolution) can show the ticket content.
regards!
sven
PS: i reduced a real email as sample to show the effect
broken_test_message2.gz (359 Bytes)
I’ve just tried this with my RT 3.6-HEAD development system and it
works just fine. Anyone else?On May 21, 2007, at 12:59 PM, Sven Sternberger wrote:
Hello!
At our site we have several PINE users, which send email into the RT
Mailgateway. Some of them mis configured there system to use UTF-8,
even if there System don’t support it.
So this i think is the cause for the mails we got.
Bug: RT-Mailgateway receives the email, and without a line in the log
it just kills the whole content of the mail. The result is an empty
ticket.
My mailclient (alpine and evolution) can show the ticket content.
regards!
sven
PS: i reduced a real email as sample to show the effect
<broken_test_message2.gz>
List info: lists.bestpractical.com Mailing Lists
rt-devel
PGP.sig (186 Bytes)
Any other mail servers in there? Is there any possibility that some
other MTA is involved that is unhappy with the UTF-8? (Just
guessing, but part of the reason mail misbehaviour is usually so hard
to debug is because of the possibility of intermediate MTAs doing
relaying.)
AOn Wed, May 23, 2007 at 02:39:50PM -0400, Jesse Vincent wrote:
I’ve just tried this with my RT 3.6-HEAD development system and it
works just fine. Anyone else?
On May 21, 2007, at 12:59 PM, Sven Sternberger wrote:
Hello!
At our site we have several PINE users, which send email into the RT
Mailgateway. Some of them mis configured there system to use UTF-8,
even if there System don’t support it.
So this i think is the cause for the mails we got.
Bug: RT-Mailgateway receives the email, and without a line in the log
it just kills the whole content of the mail. The result is an empty
ticket.
My mailclient (alpine and evolution) can show the ticket content.
regards!
sven
PS: i reduced a real email as sample to show the effect
<broken_test_message2.gz>
List info: lists.bestpractical.com Mailing Lists
rt-devel
List info: The rt-devel Archives
Andrew Sullivan | ajs@crankycanuck.ca
A certain description of men are for getting out of debt, yet are
against all taxes for raising money to pay it off.
–Alexander Hamilton
Any other mail servers in there? Is there any possibility that some
other MTA is involved that is unhappy with the UTF-8? (Just
guessing, but part of the reason mail misbehaviour is usually so hard
to debug is because of the possibility of intermediate MTAs doing
relaying.)
Just a clarification, as I was contacting the user who had problems with
that mail, Sven was sending. The mail itself is perfectly ok, but the way
how this mail was sent is not. The user had misconfigured his
terminal/mail client combo.
He used pine and stated that the charset he is using is UTF8. The actual
mail however does contain umlauts coded in ISO8859-1. The mime attachment
announced therefore Text in UTF8 while the content contained chars coded
in ISO8859-1.
While this misconfiguration is rare among our users, it was not the first
time that this combo produced empty or incomplete tickets inside RT.
Sending the mail without involving RT does work (except for some weird
chars init.)
Best regards
Wolfgang Friebel Deutsches Elektronen-Synchrotron DESY
Phone/Fax: +49 33762 77372/216 Platanenallee 6
Mail: Wolfgang.Friebel AT desy.de D-15738 Zeuthen Germany
Hello!
Any other mail servers in there? Is there any possibility that some
I don’t think that this is related to the mta (in our case
postfix). I simply piped my example into
rt-mailgate and the resulting entry had no body!> On Wed, May 23, 2007 at 02:39:50PM -0400, Jesse Vincent wrote:
I’ve just tried this with my RT 3.6-HEAD development system and it
so could it be a problem of the under laying perl library?
Attached you will find our version, which are the defaults
for a RHEL/Centos/SL 4 system.
I forgot to mention that we use RT 3.6.3
best regards!
sven
Mail::Address v1.62;
Mail::Field v1.62;
Mail::Field::AddrList v1.62;
Mail::Field::Date v1.62;
Mail::Header v1.62;
Mail::Internet v1.62;
MIME::Base64 v3.01;
MIME::Body v5.403 ;
MIME::Decoder v5.403 ;
MIME::Decoder::Base64 v5.403 ;
MIME::Decoder::Binary v5.403 ;
MIME::Decoder::NBit v5.403 ;
MIME::Decoder::QuotedPrint v5.403 ;
MIME::Entity v5.404 ;
MIME::Field::ContDisp v5.403 ;
MIME::Field::ConTraEnc v5.403 ;
MIME::Field::ContType v5.403 ;
MIME::Field::ParamVal v5.403 ;
MIME::Head v5.403 ;
MIME::Parser v5.406 ;
MIME::QuotedPrint v3.01;
MIME::Tools v5.411 ;
MIME::Words v5.404 ;
Hello!
Any other mail servers in there? Is there any possibility that some
I don’t think that this is related to the mta (in our case
postfix). I simply piped my example into
rt-mailgate and the resulting entry had no body!
Hm. Can you turn RT’s LogLevel to ‘debug’ and capture the RT logs as
it processes this message?
(Also, run rt-mailgate with the --debug flag)>> On Wed, May 23, 2007 at 02:39:50PM -0400, Jesse Vincent wrote:
I’ve just tried this with my RT 3.6-HEAD development system and it
so could it be a problem of the under laying perl library?
Attached you will find our version, which are the defaults
for a RHEL/Centos/SL 4 system.
I forgot to mention that we use RT 3.6.3
best regards!
sven
Mail::Address v1.62;
Mail::Field v1.62;
Mail::Field::AddrList v1.62;
Mail::Field::Date v1.62;
Mail::Header v1.62;
Mail::Internet v1.62;
MIME::Base64 v3.01;
MIME::Body v5.403 ;
MIME::Decoder v5.403 ;
MIME::Decoder::Base64 v5.403 ;
MIME::Decoder::Binary v5.403 ;
MIME::Decoder::NBit v5.403 ;
MIME::Decoder::QuotedPrint v5.403 ;
MIME::Entity v5.404 ;
MIME::Field::ContDisp v5.403 ;
MIME::Field::ConTraEnc v5.403 ;
MIME::Field::ContType v5.403 ;
MIME::Field::ParamVal v5.403 ;
MIME::Head v5.403 ;
MIME::Parser v5.406 ;
MIME::QuotedPrint v3.01;
MIME::Tools v5.411 ;
MIME::Words v5.404 ;
List info: lists.bestpractical.com Mailing Lists
rt-devel
PGP.sig (186 Bytes)
He used pine and stated that the charset he is using is UTF8. The actual
mail however does contain umlauts coded in ISO8859-1. The mime attachment
announced therefore Text in UTF8 while the content contained chars coded
in ISO8859-1.
Hmm. I can see why you get no body then, because the mailer is
presumably sending that as an inlined mime attachment (I don’t have
pine installed here to look). Anyway, from my recentish glance at
those, if you declare a charset, the other end may try to enforce it,
and you might get some surprises when the declaration and the data
don’t match.
A
Andrew Sullivan | ajs@crankycanuck.ca
In the future this spectacle of the middle classes shocking the avant-
garde will probably become the textbook definition of Postmodernism.
–Brad Holland
He used pine and stated that the charset he is using is UTF8. The actual
mail however does contain umlauts coded in ISO8859-1. The mime attachment
announced therefore Text in UTF8 while the content contained chars coded
in ISO8859-1.
Hmm. I can see why you get no body then, because the mailer is
presumably sending that as an inlined mime attachment (I don’t have
pine installed here to look). Anyway, from my recentish glance at
those, if you declare a charset, the other end may try to enforce it,
and you might get some surprises when the declaration and the data
don’t match.
Sure. But if the Charset is in agreement with the content, the message
looks formally identical (with or without inlined mime) and we do not have
problems with the ticket contents. Therefore I would expect weird chars
being transferred to the ticket body in case of disagreement, but not an
empty or truncated body.
To me it looks like a bug in the UTF8 handling code. In any case I would
like to see as much text as possible.
BTW it looks like a similar flaw in the program iconv:
If I convert the message with the wrong encoding (it was ISO8859-1)
iconv -f utf8 broken_test_message2
then I get a shortened message and an error message:
iconv: illegal input sequence at position 434
Only if I am using the additional -c flag
iconv -c -f utf8 broken_test_message2
then I do see (almost, a few chars are missing) the full message
Wolfgang Friebel Deutsches Elektronen-Synchrotron DESY
Phone/Fax: +49 33762 77372/216 Platanenallee 6
Mail: Wolfgang.Friebel AT desy.de D-15738 Zeuthen Germany
Hello!
Hm. Can you turn RT’s LogLevel to ‘debug’ and capture the RT logs as
it processes this message?
[Thu May 24 14:46:11 2007] [debug]: Guessed encoding: ascii
(/opt/rt3/lib/RT/I18N.pm:399)
[Thu May 24 14:46:11 2007] [debug]: Guessed encoding: ascii
(/opt/rt3/lib/RT/I18N.pm:399)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023617 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023618 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023619 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023620 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023621 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to prepare scrips for
transaction #1023621 (/opt/rt3/lib/RT/Transaction_Overlay.pm:169)
[Thu May 24 14:46:11 2007] [debug]: Found 0 scrips
(/opt/rt3/lib/RT/Scrips_Overlay.pm:363)
[Thu May 24 14:46:11 2007] [debug]: About to commit scrips for
transaction #1023621 (/opt/rt3/lib/RT/Transaction_Overlay.pm:178)
[Thu May 24 14:46:11 2007] [info]: Ticket 220106 created in queue
‘testq-operating’ by xxxx@xxxxx.de
(/opt/rt3/lib/RT/Ticket_Overlay.pm:754)
(Also, run rt-mailgate with the --debug flag)
[root@rt34 ~]# cat broken_test_message | /opt/rt3/bin/rt-mailgate -debug
–queue testq-operating --action correspond --url http://localhost/
Connecting to http://localhost//REST/1.0/NoAuth/mail-gateway
at /opt/rt3/bin/rt-mailgate line 100, <> line 1.
okTicket: 220107Queue: Owner: NobodyStatus: newSubject: Hardware
failureRequestor: xxxx@xxxxxx.de at /opt/rt3/bin/rt-mailgate line 109,
<> line 1.
so could it be a problem of the under laying perl library?
Attached you will find our version, which are the defaults
for a RHEL/Centos/SL 4 system.
I added the DAG and atrpms repository , which gives me more
recent versions of the library
So now I use:
Mail::Address v1.76;
Mail::Field v1.76;
Mail::Field::AddrList v1.76;
Mail::Field::Date v1.76;
Mail::Header v1.76;
Mail::Internet v1.76;
MIME::Base64 v3.01;
MIME::Body v5.420;
MIME::Decoder v5.420;
MIME::Decoder::NBit v5.420;
MIME::Entity v5.420;
MIME::Field::ContDisp v5.420;
MIME::Field::ConTraEnc v5.420;
MIME::Field::ContType v5.420;
MIME::Field::ParamVal v5.420;
MIME::Head v5.420;
MIME::Parser v5.420;
MIME::QuotedPrint v3.01;
MIME::Tools v5.420;
MIME::Words v5.420;
but it still has an empty body!
best regards!
Can you test against the 3.6.4 prerelease? It’s ocming out clean here.On May 24, 2007, at 11:01 AM, Sven Sternberger wrote:
Hello!
On Thu, 2007-05-24 at 10:04 -0400, Jesse Vincent wrote:
Hm. Can you turn RT’s LogLevel to ‘debug’ and capture the RT logs as
it processes this message?
[Thu May 24 14:46:11 2007] [debug]: Guessed encoding: ascii
(/opt/rt3/lib/RT/I18N.pm:399)
[Thu May 24 14:46:11 2007] [debug]: Guessed encoding: ascii
(/opt/rt3/lib/RT/I18N.pm:399)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023617 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023618 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023619 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023620 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to think about scrips for
transaction #1023621 (/opt/rt3/lib/RT/Transaction_Overlay.pm:165)
[Thu May 24 14:46:11 2007] [debug]: About to prepare scrips for
transaction #1023621 (/opt/rt3/lib/RT/Transaction_Overlay.pm:169)
[Thu May 24 14:46:11 2007] [debug]: Found 0 scrips
(/opt/rt3/lib/RT/Scrips_Overlay.pm:363)
[Thu May 24 14:46:11 2007] [debug]: About to commit scrips for
transaction #1023621 (/opt/rt3/lib/RT/Transaction_Overlay.pm:178)
[Thu May 24 14:46:11 2007] [info]: Ticket 220106 created in queue
‘testq-operating’ by xxxx@xxxxx.de
(/opt/rt3/lib/RT/Ticket_Overlay.pm:754)
(Also, run rt-mailgate with the --debug flag)
[root@rt34 ~]# cat broken_test_message | /opt/rt3/bin/rt-mailgate -
debug
–queue testq-operating --action correspond --url http://localhost/
Connecting to http://localhost//REST/1.0/NoAuth/mail-gateway
at /opt/rt3/bin/rt-mailgate line 100, <> line 1.
okTicket: 220107Queue: Owner: NobodyStatus: newSubject: Hardware
failureRequestor: xxxx@xxxxxx.de at /opt/rt3/bin/rt-mailgate line 109,
<> line 1.
so could it be a problem of the under laying perl library?
Attached you will find our version, which are the defaults
for a RHEL/Centos/SL 4 system.
I added the DAG and atrpms repository , which gives me more
recent versions of the library
So now I use:
Mail::Address v1.76;
Mail::Field v1.76;
Mail::Field::AddrList v1.76;
Mail::Field::Date v1.76;
Mail::Header v1.76;
Mail::Internet v1.76;
MIME::Base64 v3.01;
MIME::Body v5.420;
MIME::Decoder v5.420;
MIME::Decoder::NBit v5.420;
MIME::Entity v5.420;
MIME::Field::ContDisp v5.420;
MIME::Field::ConTraEnc v5.420;
MIME::Field::ContType v5.420;
MIME::Field::ParamVal v5.420;
MIME::Head v5.420;
MIME::Parser v5.420;
MIME::QuotedPrint v3.01;
MIME::Tools v5.420;
MIME::Words v5.420;
but it still has an empty body!
best regards!
List info: lists.bestpractical.com Mailing Lists
rt-devel
PGP.sig (186 Bytes)