I've been using Maximo's email listener to help shift requests getting emailed directly to the Maintenance Manager and Supervisors and into an inbox that can be managed by the entire maintenance department. Maximo has an out of the box workflow ¹ to handle inbound emails from an email listener. There are several help documents on IBM developerWorks, IBM Maximo Help, and an IBM developerWorks PDF download.

One of the problems I've had with this transition was the occasional employee adding the request email address into a email thread so whatever issued would get added as a request into Maximo. This caused two problems. First, the email that came into Maximo did nothing to direct a Planner on what the issue was because of the long discussion thread. Second, we started getting error alerts like this:

Psdi.util.MXApplicationException BMXAA4049E – The value specified ….. exceeds the maximum field length.
at psdi.util.MaxType.checkLength(MaxType.java 517)
at psdi.util.MaxType.setvalue(MaxType.java 439)
at psdi.umbo.MboValue._setvalue(MboValue.java 439)
at psdi.mbo.MboValue.setValue(MboValue.java 1171)

What I found was the 'cc' recipient list was too big for the INBOUNDCOMM.CC field. IBM has a tech note on how to fix, but that still left us with problem number - garbage getting into the request process.

My original thought was to modify the LSNRBP workflow to bounce messages that had a large 'to' or 'cc' recipient list - say more than 100 characters to indicate multiple email addresses. As I researched the issue I realized this wouldn't work because I'd still get the Psdi.util.MXApplicationException BMXAA4049E error.

Why?

Workflow will only take actions on records already in the Maximo database. So to limit/bounce an email that was too chatty meant that the record had to be on the INBOUNDCOMM table. This meant I needed to expand the INBOUNDCOMM.CC and INBOUNDCOMM.BCC fields to 1000 characters like the KB document recommended.

Bounce email listener messages

So now all emails will get written to the INBOUNDCOMM table, but I still wanted the chatty messages to not get processed by the LSNRBP workflow. When you look at the original workflow, the inbound communication record is checked to see if it has formatted actions in the ACTIONNULL step. This steps checks for the preprocessor characters like ##. If the message does, it will be pushed into other sections of the workflow. We don't use the preprocessor characters - yet.

So to bounce messages, I added a new conditional check before the ACTIONNULL condition step.

The condition node has the following properties.

The concept here is to bounce any message that has more than one sendto, one cc or one bcc recipients.

len(:sendto) > 35 or len(:cc) > 40 or len(:bcc) > 40

This will check the new INBOUNDCOMM record and look at the length of the 'to', 'cc', and 'bcc' fields. If any of the fields are exceeded, the workflow will divert the record and send out an email using the following template. ²

So now when someone essentially spams the email request address, they'll get this reply back.

So do you have any other ways to protect your email listeners? Feel free to share your ideas in comments below.