OK, so $BOSS wants to enable ParseNewMessageForTicketCcs. We
have a lot of addresses that forward into RT, and maintaining
IsRTAddress() to know about them all is infeasible. (Specially
when at least one customer has a tracking address that also
forwards back to our RT system…)
What I’m wondering is… is the big warning about not updating
IsRTAddress really still relevant? Surely if you send a message
to RT CC’ed to another RT address, any correspondence back out
from RT will have the X-RT-Loop-Prevention header in place, in
which case RT:
:CheckForLoops() should squelch any reply
bombs?
Or am I missing something fundamental here?
Phil Homewood wrote:
What I’m wondering is… is the big warning about not updating
IsRTAddress really still relevant? Surely if you send a message
to RT CC’ed to another RT address, any correspondence back out
from RT will have the X-RT-Loop-Prevention header in place, in
which case RT:
:CheckForLoops() should squelch any reply
bombs?
OK, don’t blame me if this drags your mailserver down screaming,
but a quick test seems to bear out my suspicions. The bounce/loop
detector kicks in and sends a copy of the correspondence to
$OwnerEmail. (This is with $LoopsToRTOwner = 1; changing that may
cause different behaviour.) So as long as you’re not setting
$OwnerEmail to an RT address, doing this shouldn’t burn you too
badly.
Note, if you want to avoid the bounce notifications entirely, you
still need to hack up IsRTAddress(). This should result in the
RT address never being added as watcher, so no email goes to it
and no bounce detection ever occurs.
The big warning comment apparently comes from the days before the
bounce squelcher was functional.
Thanks to Jesse for confirming this. (Hint, folks: you get a quick
turnaround if you shower him with gifts and/or money. 
“PH” == Phil Homewood pdh@snapgear.com writes:
PH> What I’m wondering is… is the big warning about not updating
PH> IsRTAddress really still relevant? Surely if you send a message
PH> to RT CC’ed to another RT address, any correspondence back out
PH> from RT will have the X-RT-Loop-Prevention header in place, in
PH> which case RT::CheckForLoops() should squelch any reply
PH> bombs?
No, if you miss just a single address that ends up back at RT in
that routine, you will cause a massive bounce-o-rama resulting in
some poor customer having 1500 or so auto-responses in their mailbox,
and your RT ticket with the same number of correspondences attached to
it. This will happen until you notice it and shut down your mail
server until you can clean it all up.
Been there. Wasn’t pretty.
Speaking of which, how does one go about cleaning out that massive
looped correspondence from RT’s database?
Vivek Khera wrote:
No, if you miss just a single address that ends up back at RT in
that routine, you will cause a massive bounce-o-rama resulting in
some poor customer having 1500 or so auto-responses in their mailbox,
and your RT ticket with the same number of correspondences attached to
it. This will happen until you notice it and shut down your mail
server until you can clean it all up.
Been there. Wasn’t pretty.
What version of RT was that? How did you trigger it?
I can’t duplicate it with 2.0.12. Using an untouched IsRTAddress()
the worst I can get is the bounce detector kicking in.
There were some bugs in the loop detection fixed around 20 Sep 2001
(RT 2.0.8); could you have been bitten before then?
Speaking of which, how does one go about cleaning out that massive
looped correspondence from RT’s database?
http://www.fsck.com/pub/rt/contrib/2.0/rt-addons/Censorware/ maybe?
(And yay for all the &(&% autoresponders out there which neither
honour nor preserve Precedence headers…)
“PH” == Phil Homewood pdh@snapgear.com writes:
Been there. Wasn’t pretty.
PH> What version of RT was that? How did you trigger it?
Don’t recall, but my ticket numbers were in the 300 range, and they’re
now in the 4000 range so it was a good long while ago. Some 1500 of
those ticket numbers were from accidentally forwarding postmaster@
mail into my abuse@ queue, and then filling up a spool disk…
PH> There were some bugs in the loop detection fixed around 20 Sep 2001
PH> (RT 2.0.8); could you have been bitten before then?
Must have been 2.0.7, since that’s the prior version sitting on my
disk.
Speaking of which, how does one go about cleaning out that massive
looped correspondence from RT’s database?
PH> http://www.fsck.com/pub/rt/contrib/2.0/rt-addons/Censorware/ maybe?
Is that something I can use after the fact to purge the repeated
messages from the ticket? It doesn’t seem to be…
Thanks for your response.