We are using RT5, and so far while it’s in testing/dev it works okay, but the deadline looms closer and we are tackling incoming email handling/ticket creation.
Our goal is to be able to parse incoming emails, maybe filter to queues based on parsing, and populate RTIR fields - both built-in and custom fields.
Some emails would come from a known email address “Tool1”, “Tool2”, and others would come from users, so we would need to accommodate all/most cases.
We are using app-wsgetmail to fetch emails from O365 and have stopped at deciding what should we do next:
Pass the fetched emails to rt-mailgate and somehow add parsing to rt-mailgate?
a. Found issue: what will happen to replies from users which should not create a new ticket, would we have to create X amount of rules within the parsing section?
Pass the fetched emails to a separate parsing script (for example python) which then would pass it to rt-mailgate using commandbymail to populate required fields?
a. Found issue: as above, but it would be handled in the separate script and not “somewhere in rt-mailgate”
Similar as 1 but use the scrips on “create ticket via email”
a. one question - can user defined actions be stored as perl scripts on RT disk? Alternatively, could we create our own actions as perl scripts that way?
One thing to note about option 3 is that once a ticket is created in a queue, a set of scrips is marshalled to run. Those scrips might have templates that cause other scrips to run, but what you can’t do is have a scrip that cancels all the other scrips that haven’t yet run. So for example if you have scrips to send out notifications to requestors, members of groups looking after a queue, set AdminCc’s, etc, this will still run even if you have a scrip that you think runs first that decides the ticket is a duff one that you don’t want and tries to reject it.
So if you’ve got some emails coming into RT that you don’t want tickets for, you need to handle those outside RT, before rt-mailgate gets hold of them.
To answer this bit, yes, you can create custom conditions and actions for the scrips that are Perl module libraries (rather than scripts) sitting in the file system. See the “Custom Condition Modules” and “Custom Action Modules” sections in this bit of the documentation: Customizing/Scrip conditions and action - RT 5.0.7 Documentation - Best Practical
We don’t necessarily (yet?) want to filter (out) emails initially, mostly for now, to present a PoC to be able to direct emails to their queues based on, let’s say, sender, subject keyword, and some fields in the body: hostname, location, etc.
In relation to which email parsing option would be the best? Do you have any suggestions?
I think you’re fine using On Create and then having a custom action that checks for moving the ticket into a new queue. Since you have the ticket object you can check all these things sender, subject keyword, and some fields in the body: hostname, location, etc with your Perl logic and decide what to do!
Option 1: don’t do it, as it will need local mods/version of rt-mailgate which might become a headache for you (or your successors) when you need to update the RT version.
Option 2: reasonable idea and means you can write it in whatever language you like if you aren’t comfy with Perl or RT. Also means you can keep unwanted tickets out of RT.
Option 3: I’d probably only go for this if you find option 2 too tricky. Custom conditions/actions are easily maintainable, but probably more involved than just a single simple script that sits between your mail system and rt-mailgate. It also means that if you move to a proper mail transfer agent in the future, your RT logic/set up won’t have to change as you’ll just put this script into something like /etc/aliases instead of rt-mailgate (or filter directly in the MTA of course).