How do I prevent messages from Request Tracker to specific users?

• How do I prevent messages from Request Tracker to specific users?
• How do I block spammers from sending mail to RT?
• How do I filter replies to a particular address in Request Tracker?

Context

• Request Tracker (RT)
• Email loop prevention

Answer

Request Tracker (RT) has several mechanisms for preventing email to certain addresses ("squelching") depending on the desired outcome. This can be useful in several scenarios:

1. Disabling specific users
   To prevent new tickets from being created by certain senders, especially originators of spam
2. User-level squelching
   To prevent auto-replies from being generated to certain addresses, especially to prevent mail loops or "conversations" between auto-responders
3. Ticket-level squelching
   To prevent email to certain watchers or other human parties associated with a ticket for all correspondence related to a ticket
4. Transaction-level squelching
   To prevent email to certain watchers or other human parties associated with a ticket for a specific reply or comment
5. Creating a content filter on the Brightmail appliances
   To block mail from specific senders before it ever reaches RT

We will describe each scenario and the necessary steps in RT in turn below. In addition to blocking inside RT, we also have some limited ability to block entire domains at the Brightmail spam appliance level, which front-ends RT for all incoming mail. This feature is used sparingly, as it applies to all of RT and can easily lead to unintentionally blocking legitimate mail.

1. Disabling specific users

The following steps need to be done by a central RT administrator. Steps are shown for documentation purposes. If you are not a central RT administrator, please send mail to tooltime@mit.edu.

Request Tracker creates a user record for every email address it received mail from. It is therefore possible to disable such a generated user in RT, preventing that email address from accessing RT. This means any email received from that address will be ignored, and no tickets will be generated based on mail sent from that account.

1. Go to Tools > Configuration > Users
2. In the Go to user box at the top of the page, enter the email address in question and hit return; you'll be taken to that user record's basic configuration page
3. In the Access control section un-check the checkbox labeled Let this user access RT
4. Click Save Changes at the bottom of the page

• Result: This will result in an error message being returned to the sender on incoming mail from that address. This error will indicate that they do not have permission to access RT.

Do not use this for blocking automated high-volume senders This is generally fine for spammers and other malicious senders. However, if the messages come from a fake domain or a domain that rejects email these errors will accumulate in RT's outgoing mail queue because they can't be delivered. Instead, see Creating a content filter on the Brightmail appliances.

2. User-level squelching

Technically there is no user-level squelching functionality in RT. By this we mean that there is no specific feature that tells RT to allow incoming mail from a user, but to never reply to that user. However, there's a kludge that can be used to achieve this behavior.

1. Go to Tools and select Configuration, then Users
2. In the Go to user box at the top of the page, enter the email address in question and hit return; you'll be taken to that user record's basic configuration page
3. In the Email field, completely blank out the email address listed there (but leave the email address in the Username field)
4. Click Save Changes at the bottom of the page

This will basically set a blank email address for that user, but still allow RT to identify the user record on incoming mail via the Username field, and accept messages. It is smart enough to not send outgoing mail to blank addresses, though, and will therefore not send messages to this user.

3. Ticket-level squelching

Not yet documented.

4. Transaction-level squelching

Not yet implemented.