Re: Send Gmail to Evernote

February 13, 2013


Harry Oosterveen published today this nice review:

Send Gmail to Evernote: an overview of the tools

The review mentioned our InQloud service that is available in Evernote trunk.

The summary table says “only notebooks” in the notebook/tags column, and that needs to be corrected. Harry posted the correction in the comments. Tagging is easy with inQloud:


BigDripper is our new follow-up robot that leverages Yoxel email conversation tracking. Currently it is only available for Gmail users. You will need to configure at least one Google Apps service in Yoxel Portal to be able to use BigDripper.

To see BigDripper in action please visit the blog post written by an early adopter.


Yoxel Portal is doing automatic email conversation discovery and logging for Highrise CRM users (read this article for details In this automatic mode a conversation is filed under one contact in Highrise and then is tracked by Yoxel Portal.

Now Gmail users can also use Gmail labels to direct the logging to a deal or case in Highrise. For that a gmail convo needs to be labeled with a Yoxel/<label> matching the deal/case name. So, create a parent folder/label ‘Yoxel’ in your Gmail account and then also create nested labels for deals/cases that you want to attach emails to:




An email convo labeled with any of these labels will be noticed by Yoxel Portal and logged in Highrise under the corresponding deal/case. Also the drip-rule labels can be used to active the BigDripper tool, our new follow-up robot (see this article for more details

Write me a line if you need any help with this. This capability will be available for our Outlook users later on.


I’ve been working with Gmail using javamail library for a long time now, the standard IMAP/SMTP capabilities were quite enough, even to deal with the labels. But recently I decided to also pull the gmail custom attributes: X-GM-THRID and X-GM-LABELS (see Gmail Imap Extensions).

At first it looked like there was no easy way to fetch those custom attributes using the standard javamail FetchProfile mechanism so I went searching in Google.

I found the  java-gmail-imap project which was quite encouraging but after studying it more I figured that I did want to use it:

  1. It incorporated javamail 1.4.4 and I really needed some new 1.5.x functionality
  2. A lot of original javamail classes if not all were extended/re-written which seemed like an overkill
  3. Last release was on Mar 23, 2012

So I went exploring further.

I must say that I really do appreciate that so much code these days is open source. Both java-gmail-imap and javamail sources showed me what was really happening under the hood and I came up with a simpler hack which only requires one extended class.

I’ll explain the hack here and if you want my code let me know.

So, for a list of messages that I am reading from Gmail I now do a standard javamail profile fetch:

folder.fetch(msgs, stdFetchProfile);

followed by my custom fetch using IMAPFolder’s doCommand():

final MessageSet[] mSets = MessageSet.createMessageSets(mns);
((IMAPFolder) folder).doCommand(new IMAPFolder.ProtocolCommand() {

	public Object doCommand(IMAPProtocol p) throws ProtocolException {
		try {
			Response[] r = p.fetch(mSets, "X-GM-LABELS X-GM-THRID");
			for (int i = 0; i < r.length; i++) {
				if (!FetchResponse.class.isInstance(r[i]))

				// Got a FetchResponse.
				GmailFetchResponse gfr = new GmailFetchResponse(
								((FetchResponse) r[i]).toString());
				// Use gfr.getNumber() to get the msg number
				for (int j = 0; j < gfr.getItemCount(); j++) {
					Item item = gfr.getItem(j);
					if (X_GM_LABELS.class.isInstance(item))
						// get the labels
						((X_GM_LABELS) item).x_gm_labels);
		} catch (ProtocolException e) {
			logError(e.getMessage(), e);
		return null;

GmailFetchResponse is the class I had to create by extending Javamail’s Response. It’s aware of the X-GM-* attributes and I make it re-parse the response received in the standard FetchResponse. I used only the required part of the java-gmail-imap’s parse() method:

private void parse() throws ParsingException {
		if (buffer[index] != '(')
			throw new ParsingException(
					"error in FETCH parsing, missing '(' at index " + index);

		Vector v = new Vector();
		Item i = null;
		do {
			index++; // skip '(', or SPACE

			if (index >= size)
				throw new ParsingException(
						"error in FETCH parsing, ran off end of buffer, size "
								+ size);

			switch (buffer[index]) {
			case 'X':
				if (match( {
					index +=;
					i = new X_GM_MSGID(this);
				if (match( {
					index +=;
					i = new X_GM_THRID(this);
				if (match( {
					index +=;
					i = new X_GM_LABELS(this);
			if (i != null)
		} while (buffer[index] != ')');

		index++; // skip ')'
		items = new Item[v.size()];

X_GM_LABELS* classes I copied from java-gmail-imap project, they’re very simple. I only added required UTF-7 conversion:

public class X_GM_LABELS implements Item {

	static final char[] name = { 'X', '-', 'G', 'M', '-', 'L', 'A', 'B', 'E', 'L', 'S' };
	public int seqnum;

	public String[] x_gm_labels;

	public X_GM_LABELS(GmailFetchResponse r) throws ParsingException {
		seqnum = r.getNumber();
		x_gm_labels = r.readAtomStringList();
		if (x_gm_labels != null)
			for (int i = 0; i < x_gm_labels.length; i++)
				try {
					x_gm_labels[i] = new String(
				} catch (UnsupportedEncodingException e) {

That is all. With one additional custom fetch call (which is not a huge overhead) you have read the Gmail attributes for your messages.

I hope this can be useful for others.




Our user has commented nicely about Yoxel Personal sync in this Basecamp Answers thread (see last comment)

Just want to add here that we can do the same now for Zoho Projects:  Huddle connector is also coming.

Plus, we’re testing our contacts sync for Highrise and Google app:








Is Your Inbox Overflowing?

January 24, 2011

I ran into this article today, It’s time to deal with that overflowing inbox, which re-iterates what we all experience with email today:

1) The growing number of e-mails, she explained, is hampering productivity among so-called knowledge workers who rely heavily on e-mail to get their jobs done and to stay on top of their personal lives.

2) “People with more than 100 messages in their inbox are less satisfied with the quality of their projects, more behind on them, and less likely to know what they need to work on at the start of a workday,”  …


And another interesting fact, pointing out that corporate knowledge workers use email alot for project collaboration:

Right now, the average corporate employee spends 25 percent of his or her workday on e-mail-related tasks, according to Radicati, compared to 14 percent on face-to-face meetings and 9 percent on the phone.

The article suggests to clean-up your inbox regularly and delete email.  But that, I think, is the option you’re left with when using your traditional email client. Email may contain valuable data and so removing it regularly just to make yourself more productive is not the best approach. I believe, organizing email better in ways that make it easy to find and know what is important at the moment, is the way to go.

You’ll probably need an additional app for this, or a new generation email client. GMail is a good one, but how do you manage your MS Exchange email with it? Xobni is an app that could help you with that though.  We’re also developing the Yoxel PCM app that will help you manage email threads/conversations better for more productive project management.


Email or Email Client?

January 12, 2011

Great article from 4spires,  Email Is Flawed For Managing Work – Transformation Is Coming.

Despite our collective understanding that email is flawed as a workflow management tool, we are firmly entrenched in its use.  What is needed is a generic solution that mirrors the simplicity and flexibility of email but adds better workflow tracking and management reporting features.

As I wrote in my earlier post, Email vs. social networking in your workplace, I would separate the term “email” as a messaging system/infrastructure (as defined by RFC822, RFC2821 (smtp), RFC2045 (mime), RFC3501 (imap), …) from “email” as email client software for reading/sending/managing email messages, implementing only a specific use model, usually dated 10-15 years ago. And so when it comes to the email clients I really agree with the article, most email clients are outdated and have not kept up with the workflow management requirements so it is obvious that new generation email management apps need to be developed.

Email as the messaging infrastructure is actually quite solid in my opinion and can be leveraged quite successfully by those new generation tools. I am probably quite “old school” but I love email. BTW, see the comment for that article about the recent Skype outage, could this have ever happened to email and paralyze millions communication channels? What I believe is that simple and open wins and email is simple and based on open standards so there could simply be a better email client that is also designed to enhance the workflow management.

I have to admit though that I am quite biased in my opinion because we’re working on a tool like that ourselves. We simply want to leverage the email based collaboration model that most organizations use today (many of which are MS Outlook based). I think most organizations have chosen to use email for a good reason (flexibility, simplicity, ubiquity, you name it …), so lets just go with what already seems natural and enhance the experience.