[rt-users] Filtering incoming emails

[Gene LeDuc]

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
>_______________________________________________
>http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
>
>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 at bestpractical.com or call us at +1 617 812 0745.
>
>
>Community help: http://wiki.bestpractical.com
>Commercial support: sales at 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