We have a situation where one of our suppliers also uses RT, but when either
of us send an e-mail from RT to the other (with the purpose of creating a
new ticket) we don’t receive an Autoreply with the ticket number of hte
other side.
The ticket however is created, RT simply doesn’t reply.
We believe it’s because of the headers that the sending RT system sends
(assumption), mainly these headers are suspect:
Precedence: bulk
RT-Squelch-Replies-To
We have no idea on where to look. We did however try this option in the
RT_SiteConfig.pm but that didn’t seem to change anything (although we might
be wrong about that):
Should RT redistribute correspondence that it identifies as machine
generated? A 1 will do so; setting this to 0 will cause no
such messages to be redistributed. You can also use ‘privileged’ (the
default), which will redistribute only to privileged users. This helps
to protect against malformed bounces and loops caused by auto-created
requestors with bogus addresses.
We have a situation where one of our suppliers also uses RT, but when either
of us send an e-mail from RT to the other (with the purpose of creating a
new ticket) we don’t receive an Autoreply with the ticket number of hte
other side.
The ticket however is created, RT simply doesn’t reply.
We believe it’s because of the headers that the sending RT system sends
(assumption), mainly these headers are suspect:
Precedence: bulk
RT-Squelch-Replies-To
We have no idea on where to look. We did however try this option in the
RT_SiteConfig.pm but that didn’t seem to change anything (although we might
be wrong about that):
Should RT redistribute correspondence that it identifies as machine
generated? A 1 will do so; setting this to 0 will cause no
such messages to be redistributed. You can also use ‘privileged’ (the
default), which will redistribute only to privileged users. This helps
to protect against malformed bounces and loops caused by auto-created
requestors with bogus addresses.
We’ve set that one to 1 to always redistribute, but it didn’t seem to do
much good (so we’ve set it back to default).
We’d like to solve this, would be nice to know each others ticket number
upon creation
Any ideas?
For sure you don’t autoreplies to go back into original system as
those would be treated as replies and may create loops. Id as well can
be extracted from subject on reply. If you really need remote id right
away when ticket created in remote instance then it’s possible to do
with a scrip on remote end that pings back via web and sets id. Never
played with RTs talking to each other, but it’s doable, but might
require some hacking to be cool.
We have a situation where one of our suppliers also uses RT, but when either
of us send an e-mail from RT to the other (with the purpose of creating a
new ticket) we don’t receive an Autoreply with the ticket number of hte
other side.
The ticket however is created, RT simply doesn’t reply.
We believe it’s because of the headers that the sending RT system sends
(assumption), mainly these headers are suspect:
Precedence: bulk
RT-Squelch-Replies-To
We have no idea on where to look. We did however try this option in the
RT_SiteConfig.pm but that didn’t seem to change anything (although we might
be wrong about that):
Should RT redistribute correspondence that it identifies as machine
generated? A 1 will do so; setting this to 0 will cause no
such messages to be redistributed. You can also use ‘privileged’ (the
default), which will redistribute only to privileged users. This helps
to protect against malformed bounces and loops caused by auto-created
requestors with bogus addresses.
We’ve set that one to 1 to always redistribute, but it didn’t seem to do
much good (so we’ve set it back to default).
You should check if RT is setting RT-DetectedAutoGenerated which is
what could trigger the autogenerated messages codepath.
RT should also be logging what it found and what it’s doing based on
your RedistributeAutoGeneratedMessages settings. The specifics of how
RT is going to act depends a lot on your versions.
There’s actually a lot going on here to prevent RT from looping with
another RT via the autoreplies, although normal correspondence should
work fine.
