sys·ad·min·ol·o·gy [sis-ad-mih-nol-uh-jee]

noun

  1. The scientific study of system administration and related phenomena.

Tuesday, 24 June 2014

Kayako version 4.x "Email rejected as the source email address is the same as an email queue address in the helpdesk"

Kayako version 4.x has been out for a while now, I recently got tasked with updating our old version 3 install.

This post deals with a particular problem caused by a change of behaviour from version 3 to version 4. Specifically, it deals with how Kayako deals with tickets that arrive via email.


Kayako version 4 will no longer process emails where the "From" address is that of another Kayako queue.

You can get details on this Kayako forum post.

In the Kayako email parser log you may see a lot of these
"Email rejected as the source email address is the same as an email queue address in the helpdesk"

While you can change the Kayako code to disable this behaviour, it actually seems like a good check to make to avoid responder loops, and also changing someone else's core code is almost always a bad idea.

Since our environment is almost 100% Linux, I opted to create some procmail rules, which changed the from address accordingly.

In my case, the email affected were internal, so there was no chance anyone was going to need to reply to them, but if they had, we could have used this rule to set the reply to address as well. This way, the customer could reply to the email in the usual way, and Kayako continues to function as normal.

As it stands, I implemented the following .procmailrc file in the relevant home folders

MAILDIR=$HOME/.maildir/
DEFAULT=$MAILDIR
LOGFILE=$MAILDIR/from
VERBOSE=yes
SHELL=/bin/bash

# kayako isnt too keen on emails arriving in kayako queues that have the same address as the same (or another) kayako queue.
:0 wf:
* ^From: .*\<(email1|email2|email2)@example.com\>
| formail -i "From: no-reply@example.com"

Starting at :0, the w means wait for the filter or program to finish & check it's exitcode. Essentially, this means that should formail fail for any reason, then the output will not be affected. Probably not needed, but a wise precaution.

The f says that procmail should take the output of formail, and carry on executing any other rules which might exist. In this instance there aren't any, but this flag is still needed so that the mail actually ends up in the mailbox! Without it, the mail would be delivered to formail, and just dropped!

More information on available flags can be gleaned from the procmailrc man page:

man procmailrc

The regular expression is pretty self explanatory; It says, if there's a From header in the email, and it has "<emailX@example.com> where X can be 1,2 or 3 then assume that we want to re-write the From address.
Note that email1,email2 and email3 are only placeholders for the actual email addresses, they were not sequential in any way. If they were I would have used:

From:.*\<email[1-3]@example.com\>

But thats another regular expression story!

The last line is what does the replacement.

formail -i "From: no-reply@example.com"


1 comment:

  1. I would like to say that this blog really convinced me to do it! Thanks, very good post. email address

    ReplyDelete