One the many problems I have found with Kayako SupportSuite is that it only checks the TO and CC addresses, this applies to email queues, parser rules and catch-all rules.
This means that if you have emails that are BCC'd into your ticket system, they wont work. Situations where this may be required is where you have an automated system that sends out overdue invoice alerts/reminders to customers and BCC's them to you so that you can action them.

The way round this is to tell the parser to check additional email headers, which headers you need will depend on your mail server. Google Apps for example uses a "delivered-to" header to record the final destination of the email.
To find out which header the destination email address is stored in, simply check your parser log and check the headers for a rejected email.

To add additional headers edit the file "<installation folder>\includes\functions_mime.php

Around line 130 find the following line

foreach (array('to', 'cc', 'x-rcpt-to') as $header)

and change it to

foreach (array('to', 'cc', 'x-rcpt-to', 'bcc','delivered-to') as $header)

Obviously you can add any number of additional headers in the same way.
I have also discovered that the CATCH-ALL rules do not work on the FROM address, presumably because the catch-all parser also uses the above code.
You may also be interested to know that the parser rules are post processors and will only parse emails that have already been accepted into a queue, so a queue must exist for the destination address.
The catch-all rules are pre-processors and will parse emails BEFORE processing them into a queue, so you can use these to process emails that would not otherwise be accepted as tickets.
Unfortunately resolving this issue was another painful battle with Kayako support, requiring screen shots, multiple repeat explanations and explaining how their own software works yet again.
As has been the case many times, their original work around/suggestion was to create a catch all rule with the following regex "(.)*", which will basically bypass all rules and queues and accept any email into the system, including every bit of spam.
I really wish their support staff would use a bit of common sense.

I have recently been having a right nightmare with Kayako SupportSuite as tickets have been coming in to email addresses that we do not use or do not exist and have thus been getting rejected and we never see them.

It turns out this is actually an old *issue* that I discovered long ago but had since forgotten about.

 

As you will know if you use Kayako SupportSuite/eSupport ( or Fusion as it is now called ) you create email queues, a queue must exist in order to process incoming email sent to that address, and you can also specify the FROM address that the queue uses when sending replies.

So you may wish to accept incoming email to:-

 

sales@yourdoamin.com

support@yourdomain.com

complaints@yourdomain.com

 

In which case you need a queue for each address for each dept, and you would of course expect that when email is sent OUT from the system, it will use the same queue and will either send from the original queue address or the alternate "From Email" address if you have specified one.

 

This unfortunately IS NOT what happens. It turns out that the queue that an email came in on bears no relevance to the queue used outgoing mail. When SupportSuite sends an email out, it simply uses the last queue in the list assigned to the tickets current dept, I.E. the most recently created queue, and then sends emails from that address.

 

This is a major issue for many reasons.

 

1. You may not want ALL QUEUES to be used for outgoing mail, some of them may just be for processing incoming mail only.
2. That queue may have the wrong email address for the dept. the ticket resides in
3. That queue may be using an email address that you do not want to be made public or used by customers, such as it might be used to bring automated emails in to the ticket system
4. You may be using that queue for testing and the email address will never be used outside of that, so you of course do not want tickets being assigned to that address or customers replying to it.
5. You may lose email as a result.

 

Not to mention the fact that this also rather defeats the whole point in having email queues for me, you would be better off just creating rules to parse the emails, but alas this does not work.

 

We have had all of these scenarios without realising, and I suspect many other users of this product have also had the same issue, believing as you would that the correct queue is being used for outgoing emails.

 

the problem is that there is no easy way to work around this problem, all you can do is make sure that the last queue in the list is a valid email address that you do not mind sending email from, there is no way to force the correct queue for the correct dept.

Even if you do this, you may still have a bunch of tickets out there that were sent from the wrong address. So if you were in scenario 3 above and doing some testing with a new queue which you have since deleted, then your customers will be replying to a non existent email address/queue and their emails will thus get rejected by the parser and you will never see them.

 

The only solution to this, is to a) delete the queue, or b)create a catch-all rule to redirect the emails to another queue or dept.

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.