How do I disable RT from sending requestor copies of their emails?

When a requestor responds to a ticket by email, they are being sent a copy of their own email. How do I disable this and still be able to send replies from my gui account? From what I have read thats just how “On Correspond Notify Requestors and Ccs” works, but my old system 3.8.1 didn’t do this (it was set up 15 years ago by someone else so I have no idea if it was custom or thats just how it used to work back then).

I need to be able to have requestors respond from email clients without sending extraneous copies back to themselves, but still get the new ticket autoreply and my web replies.

fwiw, I checked and both systems are Set($NotifyActor, 0) in RT_Config.pm (not set in RT_SiteConfig.pm).

1 Like

well nevermind, i think things might be working correctly after all

NotifyActor is the correct config option to manage whether a person gets email for updates they make. This option can be set as a personal user preference also, so it’s possible for one user to enable this for themselves and see email, and maybe even forget they did it.

It sounds like the behavior you’re observing is due to how the “On Correspond Notify Requestors and Ccs” scrip is functioning in your current setup. The setting Set($NotifyActor, 0) is supposed to prevent the actor (the person initiating the action) from receiving notifications about their own actions. However, if the requestor is still getting copies of their own email, it might be worth checking the following:

  1. Review Scrip Behavior: Confirm whether the “On Correspond Notify Requestors and Ccs” scrip is customized. Older systems may have had customizations or alternate configurations that bypassed this behavior. Compare the scrips in your current system to those in your old system, especially if you have a backup of the previous configuration.

  2. Check Custom Templates: It’s possible that the email templates associated with the scrips are configured to include the actor’s email explicitly. Look at the templates used for correspondence and notifications to see if they are referencing the requestor’s email in a way that causes the issue.

  3. Debug Notifications: Enable debug logging to see exactly what the system is doing when a requestor responds by email. This might help identify if the NotifyActor setting is being overridden or ignored in specific cases.

  4. Modify Scrip Conditions: If the behavior is tied to the default scrip, consider creating a custom condition for the scrip. For example, you could add a condition to exclude the requestor from receiving notifications when they are the actor.

  5. Consider Upgrading: If feasible, upgrading to the latest version of RT might provide more granular control over notification settings and address any quirks in the older version you are currently using.