RT-to-RT communication

hi,
first of all: hello to everyone, especially old friends: Jesse and Ruslan.
it has been almost 10 years since I played with RT for the last time! ((-:
I am amazed how many changes were implemented - great job!

unfortunately I run into some problem with fresh installation of 4.0.4,
and maybe some RT user can help me out.
my RT instance receives emails both from regular user and other RT
instances (customer’s). when ticket is opened by regular user every
scrip works as expected, autoreply and notifications are sent. when the
ticket is opened by ticket from other RT - no autoreply is sent.
I checked debug logs - it shows that all scrips are run, but no email is
generated…

  1. could somebody point me to piece of documentation which talks about
    logic of system when dealing with RT tags and subject fields generated
    by other RT instance?
  2. did I miss something and there is an obvious reason for this behaviour?

best regards,
Alek

notifications are sent. when the ticket is opened by ticket from other RT - no autoreply is
sent.
I checked debug logs - it shows that all scrips are run, but no email is generated…

  1. could somebody point me to piece of documentation which talks about logic of system when
    dealing with RT tags and subject fields generated by other RT instance?
  2. did I miss something and there is an obvious reason for this behaviour?

My guess is that RT sees that it is an Autogenerated message and
doesn’t want to cause a loop with more autogenerated mail.

There’s a branch to make this path even chattier, which should make it
into 4.0.6, but you can check by looking at the incoming headers and
comparing them to the checks in _HandleMachineGeneratedMail in
lib/RT/Action/SendEmail.pm to figure out what is triggering.

-kevin

Kevin Falcone pisze, W dniu 2012-01-25 18:51:

My guess is that RT sees that it is an Autogenerated message and
doesn’t want to cause a loop with more autogenerated mail.

There’s a branch to make this path even chattier, which should make it
into 4.0.6, but you can check by looking at the incoming headers and
comparing them to the checks in _HandleMachineGeneratedMail in
lib/RT/Action/SendEmail.pm to figure out what is triggering.

thanks Kevin. will check and get back with results.

regards,
Alek

Alek Cesarz pisze, W dniu 2012-01-25 21:48:

thanks Kevin. will check and get back with results.

I tried to review the code but with no success. nothing found in
incoming mail looks like it should trigger any special behaviour, but…
I am not a Perl hacker so my understanding of RT’s code is limited.
what I found is that during ticket creation RT adds following headers to
first transaction:

RT-Squelch-Replies-To: request@blahblah.net.pl
RT-DetectedAutoGenerated: true

which may block autoresponder.
request@blahblah.net.pl is the address from which other instance of RT
is sending mails.

below are original headers from incoming email and headers recorded in
RT’s first transation (“Ticket created”)

original headers:

Subject:
=?UTF-8?B?W2RpYWxvZyAjMTE5MjE1MV0gVEVTVDogemfFgm9zemVuaWUgdGVzdG93ZSBm?=
=?UTF-8?B?cm9tIHJlcXVlc3Q=?=
In-Reply-To:
References: RT-Ticket-1192151@blahblah.net.pl
Message-ID: rt-3.6.7-2530-1328097677-438.1192151-43-0@blahblah.net.pl
Precedence: bulk
X-RT-Loop-Prevention: blahblah
RT-Ticket: blahblah #1192151
Managed-by: RT 3.6.7 (Request Tracker... So much more than a help desk — Best Practical Solutions)
RT-Originator: someuser@blahblah.net.pl
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset=“utf-8”
X-RT-Original-Encoding: utf-8

headers recorded by RT:

CC: some.user@blahblah.pl
MIME-Version: 1.0
In-Reply-To: rt-3.6.7-19027-1328172472-527.1192151-44-0@blahblah.net.pl
References: RT-Ticket-1192151@blahblah.net.pl
RT-Ticket-61@support.s4tech.pl
rt-3.6.7-2530-1328097677-438.1192151-43-0@blahblah.net.pl
rt-4.0.4-2156-1328172181-1268.61-6-0@support.s4tech.pl
rt-3.6.7-19027-1328172472-527.1192151-44-0@blahblah.net.pl
Typ zawartoďż˝ci: text/plain; charset=“utf-8”
Message-ID: rt-3.6.7-19027-1328176621-233.1192151-44-0@blahblah.net.pl
X-RT-Original-Encoding: utf-8
RT-Originator: someuser@wroclaw.blahblah.net.pl
Received: from mail-1-out.blahblah.net.pl ([1.2.3.4]
helo=srv-1.blahblah.net.pl) by support.s4tech.pl with esmtp (Exim 4.72)
(envelope-from cdsrt@tracker-1.blahblah.net.pl) id 1RstL7-0002rf-GS
for blahblah@support.s4tech.pl; Thu, 02 Feb 2012 10:52:25 +0100
Received: from [5.6.7.8] (port=39720 helo=tracker-1.blahblah.net.pl) by
srv.blahblah.net.pl with esmtp (blahblah SMTP) id 1RstMA-00001k-Q5
(envelope-from cdsrt@tracker-1.blahblah.net.pl); Thu, 02 Feb 2012
10:53:30 +0100
Received: from cdsrt by rt-cds.int with local (Exim 4.63)
(envelope-from cdsrt@tracker-1.blahblah.net.pl) id 1RstPZ-0005X3-N9;
Thu, 02 Feb 2012 10:57:01 +0100
Managed-BY: RT 3.6.7 (Request Tracker... So much more than a help desk — Best Practical Solutions)
Temat: [blahblah #1192151] TEST: zg�oszenie testowe from request
RT-Ticket: blahblah #1192151
Precedence: bulk
X-RT-Loop-Prevention: blahblah
Do: blahblah@support.s4tech.pl
Content-Transfer-Encoding: 8bit
RT-Squelch-Replies-To: request@blahblah.net.pl
RT-DetectedAutoGenerated: true
Content-Length: 2786

any ideas?

Alek Cesarz pisze, W dniu 2012-01-25 21:48:

thanks Kevin. will check and get back with results.

I tried to review the code but with no success. nothing found in
incoming mail looks like it should trigger any special behaviour, but…
I am not a Perl hacker so my understanding of RT’s code is limited.
what I found is that during ticket creation RT adds following headers to
first transaction:

RT-Squelch-Replies-To: request@blahblah.net.pl
RT-DetectedAutoGenerated: true

which may block autoresponder.
request@blahblah.net.pl is the address from which other instance of RT
is sending mails.

below are original headers from incoming email and headers recorded in
RT’s first transation (“Ticket created”)

original headers:

Precedence: bulk

This one ^ is going to cause the CheckForAutoGenerated method to
return true, which will cause those headers you saw and turn off
outgoing mail back to the auto generated user. I’m not sure if there
is a config you could use to turn this off unfortunately, since RT is
trying to avoid having a mail loop.

Do further correspondences on your local ticket sent to the external
RT?

-kevin

Kevin Falcone pisze, W dniu 2012-02-03 18:42:

Precedence: bulk

This one ^ is going to cause the CheckForAutoGenerated method to
return true, which will cause those headers you saw and turn off
outgoing mail back to the auto generated user. I’m not sure if there
is a config you could use to turn this off unfortunately, since RT is
trying to avoid having a mail loop.

maybe I can add a custom scrip which will “unsquelch” this email
address? the only question is if it will be fired before autoreply is
being sent…

Do further correspondences on your local ticket sent to the external
RT?

yes.

Alek