Skip to content
            Subscribe (RSS | E-Mail)

Configuring Kayako SupportSuite to Close Tickets via Email

If you’re using Kayako SupportSuite to process emails and turn them into tickets, you might also be interested in being able to close tickets via email. This would allow a staff or regular users to close tickets by simply responding to the email notification with something like “close this request” in the body of the message. Using a mail parsing rule, this is relatively easy to set up in SupportSuite.

First, login to the admin section of your SupportSuite installation. Now insert a new mail parser rule by selecting Mail Parser » Manage Rules » Insert New Parser Rule in the left navigation menu. Now configure the parsing rule as follows:

Rule Title: Close Ticket via Email
Stop processing rules: No
Execution Order: 1

Now add three criteria (press the green plus icon to add more than one criteria).

Body » Contains » close this request
Plain-text Body » Contains » close this request
HTML Body » Contains » close this request

You can change ‘close this request’ to whatever you like, but keep in mind it should be something that isn’t likely to occur in a ticket response (i.e., ‘close’ would probably be too generic).

If you have more than one email queue and you only want this mail parser rule to apply to a specific queue, you can add a forth (optional) criteria:

Destination E-mail Address: [mail queue address, i.e., support@mycompany.com]

Now finish configuring this parser rule:

Select Match Any Criteria
Set Rule Type: Post Parse
Change Ticket Status: Closed

That’s it! Now press Insert and you’re done.


Posted in Kayako SupportSuite, Software.

No comments

By Raam – June 20, 2009

Adding a Google Calendar with iPhone 3.0

One of the nice new features of the iPhone 3.0 software is the ability to add a custom CalDAV account. Since Google Calendar supports CalDAV, this means that you can now add your Google Calendar account to your iPhone! And not only are you able to view calendar entries, but you can add, delete, and modify them too!

To get started, navigate to to the following screen by choosing Settings -> Mail, Contacts, Calendars -> Add Account… -> Other:

iphone-gcal1

Now choose Add CalDAV Account and enter your Google Calendar account login details. The server should be set to www.google.com. When you’re done, press Next and wait for the iPhone to verify the information:

iphone-gcal2

When it finishes, go back to your home screen and open your calendar. Press the Calendars button at the top left to view a list of all available calendars. You will now see an All Google option listed:

iphone-gcal3

If you only want to view your Google calendars, you can select the All Google option. Otherwise, choose All Calendars to view all of them. Now when you add, delete, or modify an entry on any of your Google calendars from your iPhone, they will automatically be synced with Google!


Posted in iPhone.

No comments

By Raam – June 18, 2009

Alert to All Mac OS X Users: Protect Yourself from CVE-2008-5353!

Update: TidBITS writes that Apple has released a patched version of Java that fixes this issue. It is available through Software Update.

CVE-2008-5353 is a critical Java vulnerability that was discovered back in August 2008 and patched by Sun Microsystems a few months later. However, Apple has failed to release a patched version of Java, even in the latest 10.5.7 update! CVE-2008-5353 is described as follows:

Unspecified vulnerability in Java Runtime Environment (JRE) for Sun JDK and JRE 6 Update 10 and earlier; JDK and JRE 5.0 Update 16 and earlier; and SDK and JRE 1.4.2_18 and earlier allows untrusted applets and applications to gain privileges via unknown vectors related to “deserializing calendar objects.”

Since Apple failed fix this vulnerability in the latest update to OS X (10.5.7), Landon Fuller, a programmer and former Apple Engineer, released a proof-of-concept demonstrating the exploit. The demonstration is done by launching a Java applet in your web browser and using the exploit to run the /usr/bin/say command on your Mac to “speak” some words through your speakers. This may not sound very dangerous, but this same exploit could be used to run malicious code on your Mac without your even knowing it!

So, how can I protect myself?

For now, all you can do is entirely disable Java in your browsers to ensure no Java applets are allowed to run. The good news is that chances are you probably don’t depend on Java anyway (remember, Java is not JavaScript). And if you find yourself needing to run something that does require Java (the browser will alert you with a message saying the Java plugin isn’t installed), you can always re-enable Java in your browser while you’re using the applet, and then disable it again when you’re done. Inconvenient, yes, but worth it. This is one nasty vulnerability, and with all the publicity it’s been getting lately, there’s bound to be more malicious code in the wild just waiting to hijack your system.

Disabling Java in Firefox

In Firefox, choose from the menu, Firefox -> Preferences. Then select the Content tab and un-check the Use Java option:

Firefox Content Preferences, Use Java option

Disabling Java in Safari

(applies to both Safari 3 and Safari 4 Beta)

In Safari, choose from the menu, Safari -> Preferences. Then select the Security tab and un-check the Enable Java option:

Safari 4 Beta Security Preferences, Enable Java option

Update: TidBITS writes that Apple has released a patched version of Java that fixes this issue. It is available through Software Update.


Posted in Exploits, Firefox, OS X, Safari, Security.

4 comments

By Raam – May 20, 2009

Saving Files as root From Inside VIM

Oftentimes I will be editing a Linux configuration file using vim only to discover that I cannot save it because the file requires root permission to write to it. This ends up looking something like this:

vi /path/to/some/file.conf
[make some edits]
:w
VIM Message: E45: 'readonly' option is set (add ! to override)
:q!
$ sudo vi /path/to/some/file.conf
[make all my edits AGAIN]
:w

I have gone through this process so many times that I knew there must be an easy fix for it. (I know about sudo !! for running the previous command, but I only recently started developing the habit of using it.) After forgetting to use sudo while editing a configuration file yet again this morning, I finally decided to search Google and find a solution. Here it is:

vi /path/to/some/file.conf
[make some edits]
:w
VIM Message: E45: 'readonly' option is set (add ! to override)
:w !sudo tee %

The :w !sudo tee % command tells VIM to write the file (w) but run the sudo command first (!sudo) and read the writing of the file from standard input to standard output (tee) using the same filename as the one we’re editing (%).

After saving the file as root, you’ll get this message: “W12: Warning: File “/private/etc/smb.conf” has changed and the buffer was changed in Vim as well”. You’ll be given the option to reload it, but since you were already looking at the new version it doesn’t much matter which option you choose (OK or Reload).

And last but not least, if you don’t want to remember the syntax for this command, you can map the command in your ~/.vimrc file:

cmap w!! w !sudo tee % >/dev/null

Now, if you forget to edit a file with sudo, you can simply type :w!! to fix the problem!


Posted in Linux, VIM.

3 comments

By Raam – May 8, 2009

Internet Explorer: Incorrect Password During Certificate Import

While importing a P12 certificate into Internet Explorer today, I got a message saying “The password you entered is incorrect.”:

Internet Explorer - Incorrect certificate password

However, I successfully imported this same certificate, using the same password, on Firefox and Safari. But Internet Explorer (both IE7 and IE8) continued to tell me I was using the wrong password. After checking, double-checking, and quadruple-checking the password, I was 1000% sure the private key password that I was using was correct and that Internet Explorer itself was to blame.

After much trial and error, I discovered the problem: Internet Explorer has a maximum private key password length! The password I was using (modified for security purposes, but identical in length) was as follows:

603979ba15c2097f8f7fy35ec0ucfbeb

That’s 32 characters, the same length as an MD5. However, Internet Explorer appears to have a problem with that! I changed the password to the following 26 character password and the certificate imported with no complaints from IE!

ae869d263e267593286188b638

If you’re having the same problem, you may be wondering how to change the password on your P12 file. To do this, you’ll need access to OpenSSL. If you have a Mac, you might be able to find OpenSSL in /opt/local/bin/openssl. But more likely you’re on Windows and you will need to download and install the OpenSSL binary for Windows.

You can use the OpenSSL program to convert the P12 file to PEM format, and then convert the PEM certificate back into a P12 file, using a shorter 26-character password when prompted. Here’s how:

First, convert the original P12 file to PEM format:

openssl pkcs12 -in my-original.p12 -out certkey.pem -nodes -clcerts

This should give you a file called certkey.pem. This file contains both the certificate and the private key. However, the next command requires that the key be contained in a separate key.pem file, so you’ll want to edit certkey.pem with a text editor and extract the private key portion (it should be the bottom half of the file). The key.pem file should look somewhat like this:

Bag Attributes
    localKeyID: EE 35 CB 41 81 23 4C 89 FF 43 42 E0 3C 3B FF 93 9E 0E B7 AA
Key Attributes: <No Attributes>
-----BEGIN RSA PRIVATE KEY-----
MIIoOwLBAAJBANSdWgmhySZsCD/koC6nST/JzH/Uqjm6NXsQwtTwx493rhM/90BB
JyfdkfDQCHR/XP0szI1LqS/AXfSx1q25/3MCAwEAAQJBAM0Iu+Mm7zJTT7nqDgfv
VW+4RaRVp05JHaWQdeerpBnWJI+2NDsiKrovyrvYjglJcdpXHhoM95T5qm8x65XP
MhkCIQD5vQ2dNGoFGn0yL0ELDU39PrVvfZyJV3wXedjrQm9utwIhAN0FRk/qIWzz
p9ZP9DjIpIRj6BdWLRrZmLqxdnUXifSlAiBy6fb1u0RJjK7HBM9dPK7+NHiQEJCS
8dp7wZl5d1xnCSIhANLoF6pmnyLil4QwgVlOTv9ufqjSZ+w5GD7a3Vj678RpAiAV
6rTJ3mAZAeQiaRHhgRP7SuvQS6EDWDPxbMBMwYklfA==
-----END RSA PRIVATE KEY-----

With these files in place, you can run the following command to convert the PEM certificate back into a P12 format, providing a new password (maximum 26 characters) when prompted for the Export Password:

$ openssl pkcs12 -export -in certkey.pem -inkey key.pem -out my-new-certificate.p12 -rand /dev/random
2048 semi-random bytes loaded
Enter Export Password:
Verifying - Enter Export Password:

That’s it! Now you should be able to install the certificate in Internet Explorer without any “incorrect password” complaints.


Posted in Internet Explorer, Windows.

No comments

By Raam – May 1, 2009