Background

We use Kayako Support Suite for our support helpdesk over at Bluethunder and while it is an awesome product, and generally considered the best of its kind on the market, it is not without its issues. I have discovered quite a few bugs in the years  we have been using it and have been surprised that they could have existed so long and not been noticed by others as they were real show stoppers, as a result I have come to the conclusion that most other companies using this product must use it in a very simple way and do not use as many of the cool and useful features of this product as we do, this feeling is backed up by the fact that the Kayako community forums are also no help either.

The other BIG issue is Kayako's support, which is frustrating to put it kindly. They regularly give incorrect advise as the support staff do not really know how their own product works which results in your being told something is not possible when it is, or being given a solution which may screw up your whole system and lose emails. I regularly end up having to explain how their product works in order to prove that the advise given is wrong, if you are lucky this will then result in your ticket being escalated to a senior staff member or developer. This is no doubt partly due to the fact that they are an Indian company, and so there are some communication issues as well, which most people have likely experienced these days with so many companies out sourcing their support and customer service to India it is an experience hard to avoid.

 

As a result I have decided to add this new category to my blog and start posting hints and tips for using Kayako SupportSuite and solving issues.

 

The BCC Problem

We recently migrated to a new installation of SupportSuite and have had a few issues with things not working how they did before, which is most cases has been down to the mail server. One of these issues was that the automated emails form our control panel were no longer arriving in the ticket system.

Checking the parser log I found the reason:-

 

"Result: No assigned queues found for mail recipients".

 

Now the reason for this is actually valid, when the control panel sends out emails to customers it BCC's them us, and when you do this the BCC address is removed by the receiving mail server for privacy as this is the whole point in a BCC, so that the other recipients addresses cannot be seen.

But the odd thing is that it worked fine on the old system, so I opened a ticket with Kayako.

The answer I got from them was that BCC emails will not work as the parser will only look at the TO address and that I must setup a catch-all rule to allow ALL/ANY email into the system.

Clearly I knew their answer was not true and the solution was of course not viable as it would make the whole system unusable and override all our existing settings and rules and allow every bit of spam into the ticket system.

 

So I sent a test email BCC'd to each system and checked the parser log to see the difference between them both.

 

What I noticed was on the old system a "X-Rcpt-To: " header was added to the email by the mail server (Mdaemon) which is populated with the final destination address, and obviously the parser was picking this up and putting the email into the correct queue.

 

On the new system the email had far less headers and did not have any "X-Rcpt-To: ", instead it had a "Delivered-To:" header created by the mail server (HMail) so obviously the parser did not look for this header and thus why it failed.

 

With a bit of coercion Kayako support finally accepted and agreed with my findings and came to the same conclusion.

 

The Solution

The best solution would be to use a mail server that creates the "X-Rcpt-To: " header, but this is probably not a satisfactory solution for many, and not for us either.

So the work around is to make sure that the BCC emails are always sent from a specific address and to create a catch-all rule that will accept all emails from that address and put them into the desired queue. Now obviously you need to make sure the address used is not a public address or a common address that is generally targeted by spammers otherwise you will get bucket loads of spam.

The catch all rule looks like this.

 

/something\@yourdomain\.com/

 

I have suggested to kayako that they update their parser to look at *ALL* the headers for the queue addresses, which would resolve this issue on any mail servers that create a header for the destination address.