How to disable forwarding of correspondence to requestor?

Hi,
With the default config, if a message is sent to RT with a ticket
identifier in the subject, but from an email address different than that
ticket’s requestor, RT will send a copy of the message to the requestor.
I want to prevent RT from sending the copy. I’ve tried deleting and
changing various ‘on correspond’ scrips with no luck.

I’ve recently had a vexing problem with a mail loop. RT received a spam
message with a bad from address. SpamAssassin marked it and an
automated spam reply was sent out by RT. The mail server identified by
the (bad) from address then returned a message indicating that it was
non-deliverable but which contained the RT ticket identifier string in
the subject. Since the from address was not the same as the requestor
address, RT sent a copy of this notification back to the requestor. RT
received another non-deliverable notification creating a mail loop.
Over a few days several thousand emails were sent back and forth before
I noticed the problem. This ticket had over 16000 transactions, which
caused httpd processes to lock up when attempting to view the ticket.

I want to prevent this from happening. If there is no way to disable
RT’s message forwarding in this instance, I will consider disabling the
autoreply for spam messages, though that could cause problems with false
positives. But I can imagine someone could easily cause a similar mail
loop by sending a couple of non-spam messages with forged headers, just
using the default RT autoreply.

This is a production RT 3.4.5 system that has been running for several
months. It is installed on a fedora core 5 server. Thanks for any
assistance or advice!

-Mike Bell

Hi Mike.

Mike Bell wrote:

Hi,
With the default config, if a message is sent to RT with a ticket
identifier in the subject, but from an email address different than
that ticket’s requestor, RT will send a copy of the message to the
requestor. I want to prevent RT from sending the copy. I’ve tried
deleting and changing various ‘on correspond’ scrips with no luck.

Interesting problem.

I think you need to rethink your spam strategy.
Why do you reply to a spam mail?
If you do, then change the subject of non-deliverable.

I had a similar case where I wanted to single out mail-from-requestors
that had the ticketID in the subject but were sent to a different queue
than the ticketID->queue. I manipulated procmail so that it checked what
the queue was and then either appended (to existing ticket if queue was
same) or created new ticket (if queue was different).

Procmail might be your answer.

Hope that helps.
Kind regards.
Luke.

I’ve recently had a vexing problem with a mail loop. RT received a
spam message with a bad from address. SpamAssassin marked it and an
automated spam reply was sent out by RT. The mail server identified
by the (bad) from address then returned a message indicating that it
was non-deliverable but which contained the RT ticket identifier
string in the subject. Since the from address was not the same as the
requestor address, RT sent a copy of this notification back to the
requestor. RT received another non-deliverable notification creating
a mail loop. Over a few days several thousand emails were sent back
and forth before I noticed the problem. This ticket had over 16000
transactions, which caused httpd processes to lock up when attempting
to view the ticket.

I want to prevent this from happening. If there is no way to
disable RT’s message forwarding in this instance, I will consider
disabling the autoreply for spam messages, though that could cause
problems with false positives. But I can imagine someone could easily
cause a similar mail loop by sending a couple of non-spam messages
with forged headers, just using the default RT autoreply.

This is a production RT 3.4.5 system that has been running for several
months. It is installed on a fedora core 5 server. Thanks for any
assistance or advice!

-Mike Bell


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical:
http://bestpractical.com/about/jobs.html

Luke Vanderfluit.
Analyst/Programmer.
Internode Systems Pty. Ltd.