Filtering incoming emails

RT Users
1

We are using 3.6.1 with postfix and procmail. It isn’t a complicated setup but
a new configuration we’re testing has an interesting “feature” which needs some
special attention.

We have five customer-facing queues (Triage, Network, Systems, Operations and
Sales). Triage is the only one in which tickets can be created by outside
parties. The other four support correspondence but cannot have new tickets
created within by outside parties. In to facilitate this, we run a cron job
which polls our customer database and builds a procmail script listing all of
the allowed “from” addresses. Any incoming email is parsed through the script
and if allowed is then handed off to rt-mailgate.

In the /etc/aliases file, we alias the four non-triage queues to Triage which,
again, allows new ticket creation. This serves to place all new ticket requests
in Triage as a new ticket while allowing RT to do it’s thing by parsing the
subject and placing all correspondence for existing tickets in the right place.

On the surface this is a wonderful setup. We guarantee that all new tickets are
only in the new ticket queue while all existing tickets get updated
appropriately. However, I have discovered a fault which I’m hoping the RT
Faithful can help me with.

I have a monthly cron job which generates an email to be sent to one of the four
other queues; one of the four which doesn’t allow new ticket creation. However,
the “from” address for this email is internal. The ticket that it generates is
intended to spawn three child tickets. The problem is that, since this is a new
ticket, it gets trapped in the Triage queue and isn’t allowed to move on to the
queue it is intended for.

What I need help with is finding a method that will allow this one email (or any
internal email, actually) to be allowed to bypass Triage and go directly to its
intended queue.

I’ve considered not aliasing the one queue to Triage. This will lead to an
unwanted side-effect. Right now, by trapping all new ticket requests in Triage,
we are preventing the automatically generated email which confusingly states
that a person is not allowed to create a ticket. Instead, the ticket is created
in Triage and the auto-reply is sent stating this. Should I cease the aliasing,
if a person decides to send a ticket to Systems (the non-Triage queue which the
email cron job is sending to) then they will receive the reply stating that a
user could not be found or whatever the confusing reply is. I’d like to avoid this.

So, if I haven’t convoluted this yet and someone has been able to follow what
I’m trying to say, can that person help me figure out how to allow incoming,
internal emails to avoid this trap I’ve created?

Keep up with me and what I’m up to: http://theillien.blogspot.com

2

Hi Mathew,

Sounds like a slick setup. Can’t you just add your internal addresses
either directly to the procmail filter script or to your customer database
with “approved to bypass triage” status?

Regards,
Gene

At 04:18 AM 11/4/2007, Mathew Snyder wrote:

We are using 3.6.1 with postfix and procmail. It isn’t a complicated
setup but
a new configuration we’re testing has an interesting “feature” which
needs some
special attention.

We have five customer-facing queues (Triage, Network, Systems, Operations and
Sales). Triage is the only one in which tickets can be created by outside
parties. The other four support correspondence but cannot have new tickets
created within by outside parties. In to facilitate this, we run a cron job
which polls our customer database and builds a procmail script listing all of
the allowed “from” addresses. Any incoming email is parsed through the script
and if allowed is then handed off to rt-mailgate.

In the /etc/aliases file, we alias the four non-triage queues to Triage which,
again, allows new ticket creation. This serves to place all new ticket
requests
in Triage as a new ticket while allowing RT to do it’s thing by parsing the
subject and placing all correspondence for existing tickets in the right
place.

On the surface this is a wonderful setup. We guarantee that all new
tickets are
only in the new ticket queue while all existing tickets get updated
appropriately. However, I have discovered a fault which I’m hoping the RT
Faithful can help me with.

I have a monthly cron job which generates an email to be sent to one of
the four
other queues; one of the four which doesn’t allow new ticket
creation. However,
the “from” address for this email is internal. The ticket that it
generates is
intended to spawn three child tickets. The problem is that, since this is
a new
ticket, it gets trapped in the Triage queue and isn’t allowed to move on
to the
queue it is intended for.

What I need help with is finding a method that will allow this one email
(or any
internal email, actually) to be allowed to bypass Triage and go directly
to its
intended queue.

I’ve considered not aliasing the one queue to Triage. This will lead to an
unwanted side-effect. Right now, by trapping all new ticket requests in
Triage,
we are preventing the automatically generated email which confusingly states
that a person is not allowed to create a ticket. Instead, the ticket is
created
in Triage and the auto-reply is sent stating this. Should I cease the
aliasing,
if a person decides to send a ticket to Systems (the non-Triage queue
which the
email cron job is sending to) then they will receive the reply stating that a
user could not be found or whatever the confusing reply is. I’d like to
avoid this.

So, if I haven’t convoluted this yet and someone has been able to follow what
I’m trying to say, can that person help me figure out how to allow incoming,
internal emails to avoid this trap I’ve created?

–
Keep up with me and what I’m up to: http://theillien.blogspot.com

The rt-users Archives

SAVE THOUSANDS OF DOLLARS ON RT SUPPORT:

If you sign up for a new RT support contract before December 31, we’ll take
up to 20 percent off the price. This sale won’t last long, so get in touch
today.
Email us at sales@bestpractical.com or call us at +1 617 812 0745.

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

Gene LeDuc, GSEC
Security Analyst
San Diego State University

3

Mathew,

We have a setup here that seems to accomplish what you are looking to

do but we don’t do it with all the complications you seem to be stuck
with in terms of your email. We have over 50 queues for the support of
various application software groups but do NOT let anyone outside those
technical support groups create any tickets in them. We set up one queue
to act as an “Approval” (front-end request waiting room) queue and we
granted privileges for ONLY that queue to allow the creation of tickets
from self-service or any number of defined groups that are NOT technical
support groups. We then defined an approval group to be the only group
that can approve a request ticket in that queue and move it to the
appropriate support queue for work. They have a Custom Field defined
that allows them and ONLY them to modify it and some scrips that
evaluate that CF modification during a transaction and THAT modification
will trigger any number of other modifications to “Owner”, other data
fields, AND send out notifications of ticket movement or promotions to
the appropriate watchers/requesters/Admin people. This way, the ticket
number is always the same and ALL it’s history goes with it to whatever
queue it ends up in. But most importantly, we can stay with the
flexibility design of the RT code and NOT have to maintain a whole bunch
of complicated modifications to base code or to mess with the simplicity
of the email/alias functionality. This may not be your cup of tea, but
for restricting requests and single-threading approvals, it certainly
works for us. Hope this helps.

Kenn
LBNLOn 11/4/2007 4:18 AM, Mathew Snyder wrote:

We are using 3.6.1 with postfix and procmail. It isn’t a complicated setup but
a new configuration we’re testing has an interesting “feature” which needs some
special attention.

We have five customer-facing queues (Triage, Network, Systems, Operations and
Sales). Triage is the only one in which tickets can be created by outside
parties. The other four support correspondence but cannot have new tickets
created within by outside parties. In to facilitate this, we run a cron job
which polls our customer database and builds a procmail script listing all of
the allowed “from” addresses. Any incoming email is parsed through the script
and if allowed is then handed off to rt-mailgate.

In the /etc/aliases file, we alias the four non-triage queues to Triage which,
again, allows new ticket creation. This serves to place all new ticket requests
in Triage as a new ticket while allowing RT to do it’s thing by parsing the
subject and placing all correspondence for existing tickets in the right place.

On the surface this is a wonderful setup. We guarantee that all new tickets are
only in the new ticket queue while all existing tickets get updated
appropriately. However, I have discovered a fault which I’m hoping the RT
Faithful can help me with.

I have a monthly cron job which generates an email to be sent to one of the four
other queues; one of the four which doesn’t allow new ticket creation. However,
the “from” address for this email is internal. The ticket that it generates is
intended to spawn three child tickets. The problem is that, since this is a new
ticket, it gets trapped in the Triage queue and isn’t allowed to move on to the
queue it is intended for.

What I need help with is finding a method that will allow this one email (or any
internal email, actually) to be allowed to bypass Triage and go directly to its
intended queue.

I’ve considered not aliasing the one queue to Triage. This will lead to an
unwanted side-effect. Right now, by trapping all new ticket requests in Triage,
we are preventing the automatically generated email which confusingly states
that a person is not allowed to create a ticket. Instead, the ticket is created
in Triage and the auto-reply is sent stating this. Should I cease the aliasing,
if a person decides to send a ticket to Systems (the non-Triage queue which the
email cron job is sending to) then they will receive the reply stating that a
user could not be found or whatever the confusing reply is. I’d like to avoid this.

So, if I haven’t convoluted this yet and someone has been able to follow what
I’m trying to say, can that person help me figure out how to allow incoming,
internal emails to avoid this trap I’ve created?