Trojitá

Summary An SSL stripping vulnerability was discovered in Trojitá, a fast Qt IMAP e-mail client. User's credentials are never leaked, but if a user tries to send an e-mail, the automatic saving into the "sent" or "draft" folders could happen over a ... [More] plaintext connection even if the user's preferences specify STARTTLS as a requirement. Background The IMAP protocol defines the STARTTLS command which is used to transparently upgrade a plaintext connection to an encrypted one using SSL/TLS. The STARTTLS command can only be issued in an unauthenticated state as per the IMAP's state machine. RFC 3501 also allows for a possibility of the connection jumping immediately into an authenticated state via the PREAUTH initial response. However, as the STARTTLS command cannot be issued once in the authenticated state, an attacker able to intercept and modify the network communication might trick the client into a state where the connection cannot be encrypted anymore. Affected versions All versions of Trojitá up to 0.4 are vulnerable. The fix is included in version 0.4.1. Remedies Connections which use the SSL/TLS form the very beginning (e.g. the connections using port 993) are secure and not vulnerable. Possible impact The user's credentials will never be transmitted over a plaintext connection even in presence of this attack. Because Trojitá proceeded to use the connection without STARTTLS in face of PREAUTH, certain data might be leaked to the attacker. The only example which we were able to identify is the full content of a message which the user attempts to save to their "Sent" folder while trying to send a mail. We don't believe that any other data could be leaked. Again, user's credentials will not be leaked. Acknowledgement Thanks to Arnt Gulbrandsen on the imap-protocol ML for asking what happens when we're configured to request STARTTLS and a PREAUTH is received, and to Michael M Slusarz for starting that discussion. [Less]

Hi all, we are pleased to announce version 0.4 of Trojitá, a fast Qt IMAP e-mail client. For this release, a lot of changes were made under the hood, but of course there are some changes that are visible to the user as well. Improvements: Users ... [More] are able to use multiple sessions, which means that it is possible to use Trojitá with multiple IMAP accounts at the same time. It can be used by invoking Trojitá with the --profile something switch. For each profile, a new instance of the application is started. Please note that this is not our final solution for the multi-accounts problem; work on this is ongoing. For details, refer to the detailed instructions. In the Composer Window, users can now control whether the current message is a reply to some other message. Hopefully, this will make it easier to reply to a ton of people while starting a new thread, not lumping the unrelated conversations together. Trojitá will now detect changes to the network connection state. So for example, when a user switches from a wireless connection to a wired one, Trojitá will detect that and try to reconnect automatically. Trojitá gained a setting to automatically use the system proxy settings. SOCKS5 and HTTP proxies are supported. Memory usage has been reduced and speed has been improved. Our benchmarks indicate being ten times faster when syncing huge mailboxes, and using 38% less memory at the same time. The Compose Window supports editing the "From" field with hand-picked addresses as per common user requests. This release has been tagged in git as "v0.4". You can also download a tarball (GPG signature). Prebuilt binaries for multiple distributions are available via the OBS . This release is dedicated to the people of all nations living in Ukraine. We are no fans of political messages in software announcements, but we also cannot remain silent when unmarked Russian troops are marching over a free country. The Trojitá project was founded in a republic formerly known as Czechoslovakia. We were "protected" by foreign aggressors twice in the 20th century — first in 1938 by the Nazi Germany, and second time in 1968 by the occupation forces of the USSR. Back in 1938, Adolf Hitler used the same rhetorics we hear today: that a national minority was oppressed. In 1968, eight people who protested against the occupation in Moscow were detained within a couple of minutes, convicted and sent to jail. In 2014, Moscowians are protesting on a bigger scale, yet we all see the cops arresting them on Youtube — including those displaying blank signs. This is not about politics, this is about morality. What is happening today in Ukraine is a barbaric act, an occupation of an innocent country which has done nothing but stopped being attracted to their more prominent eastern neighbor. No matter what one thinks about the international politics and the Crimean independence, this is an act which must be condemned and fiercely fought against. There isn't much what we could do, so we hope that at least this symbolic act will let the Ukrainians know that the world's thoughts are with them in this dire moment. За вашу и нашу свободу, indeed! Finally, we would like to thank Jai Luthra, Danny Rim, Benjamin Kaiser and Yazeed Zoabi, our Google Code-In students, and Stephan Platz, Karan Luthra, Tomasz Kalkosiński and Luigi Toscano, people who recently joined Trojitá, for their code contributions. The Trojitá developers Jan Kundrát Yuri Chornoivan Karan Luthra Pali Rohár Tomasz Kalkosiński Christian Degenkolb Jai Luthra Stephan Platz Thomas Lübking [Less]

Hi all, we are pleased to announce version 0.4 of Trojitá, a fast Qt IMAP e-mail client. For this release, a lot of changes were made under the hood, but of course there are some changes that are visible to the user as well. Improvements: Users ... [More] are able to use multiple sessions, which means that it is possible to use Trojitá with multiple IMAP accounts at the same time. It can be used by invoking Trojitá with the --profile something switch. For each profile, a new instance of the application is started. Please note that this is not our final solution for the multi-accounts problem; work on this is ongoing. For details, refer to the detailed instructions. In the Composer Window, users can now control whether the current message is a reply to some other message. Hopefully, this will make it easier to reply to a ton of people while starting a new thread, not lumping the unrelated conversations together. Trojitá will now detect changes to the network connection state. So for example, when a user switches from a wireless connection to a wired one, Trojitá will detect that and try to reconnect automatically. Trojitá gained a setting to automatically use the system proxy settings. SOCKS5 and HTTP proxies are supported. Memory usage has been reduced and speed has been improved. Our benchmarks indicate being ten times faster when syncing huge mailboxes, and using 38% less memory at the same time. The Compose Window supports editing the "From" field with hand-picked addresses as per common user requests. This release has been tagged in git as "v0.4". You can also download a tarball (GPG signature). Prebuilt binaries for multiple distributions are available via the OBS . This release is dedicated to the people of all nations living in Ukraine. We are no fans of political messages in software announcements, but we also cannot remain silent when unmarked Russian troops are marching over a free country. The Trojitá project was founded in a republic formerly known as Czechoslovakia. We were "protected" by foreign aggressors twice in the 20th century — first in 1938 by the Nazi Germany, and second time in 1968 by the occupation forces of the USSR. Back in 1938, Adolf Hitler used the same rhetorics we hear today: that a national minority was oppressed. In 1968, eight people who protested against the occupation in Moscow were detained within a couple of minutes, convicted and sent to jail. In 2014, Moscowians are protesting on a bigger scale, yet we all see the cops arresting them on Youtube — including those displaying blank signs. This is not about politics, this is about morality. What is happening today in Ukraine is a barbaric act, an occupation of an innocent country which has done nothing but stopped being attracted to their more prominent eastern neighbor. No matter what one thinks about the international politics and the Crimean independence, this is an act which must be condemned and fiercely fought against. There isn't much what we could do, so we hope that at least this symbolic act will let the Ukrainians know that the world's thoughts are with them in this dire moment. За вашу и нашу свободу, indeed! Finally, we would like to thank Jai Luthra, Danny Rim, Benjamin Kaiser and Yazeed Zoabi, our Google Code-In students, and Stephan Platz, Karan Luthra, Tomasz Kalkosiński and Luigi Toscano, people who recently joined Trojitá, for their code contributions. The Trojitá developers Jan Kundrát Yuri Chornoivan Karan Luthra Pali Rohár Tomasz Kalkosiński Christian Degenkolb Jai Luthra Stephan Platz Thomas Lübking [Less]

Jos wrote a blog post yesterday commenting on the complexity of the PIM problem. He raises an interesting concern about whether we would be all better if there was no Trojitá and I just improved KMail instead. As usual, the matter is more ... [More] complicated than it might seem on a first sight. Executive Summary: I tried working with KDEPIM. The KDEPIM IMAP stack required a total rewrite in order to be useful. At the time I started, Akonadi did not exist. The rewrite has been done, and Trojitá is the result. It is up to the Akonadi developers to use Trojitá's IMAP implementation if they are interested; it is modular enough. People might wonder why Trojitá exists at all. I started working on it because I wasn't happy with how the mail clients performed back in 2006. The supported features were severely limited, the speed was horrible. After studying the IMAP protocol, it became obvious that the reason for this slowness is the rather stupid way in which the contemporary clients treated the remote mail store. Yes, it's really a very dumb idea to load tens of thousands of messages when opening a mailbox for the first time. Nope, it does not make sense to block the GUI until you fetch that 15MB mail over a slow and capped cell phone connection. Yes, you can do better with IMAP, and the possibility has been there for years. The problem is that the clients were not using the IMAP protocol in an efficient manner. It is not easy to retrofit a decent IMAP support into an existing client. There could be numerous code paths which just assume that everything happens synchronously and block the GUI when the data are stuck on the wire for some reason. Doing this properly, fetching just the required data and doing all that in an asynchronous manner is not easy -- but it's doable nonetheless. It requires huge changes to the overall architecture of the legacy applications, however. Give Trojitá a try now and see how fast it is. I'm serious here -- Trojitá opens a mailbox with tens of thousands of messages in a fraction of second. Try to open a big e-mail with vacation pictures from your relatives over a slow link -- you will see the important textual part pop up immediately with the images being loaded in the background, not disturbing your work. Now try to do the same in your favorite e-mail client -- if it's as fast as Trojitá, congratulations. If not, perhaps you should switch. Right now, the IMAP support in Trojitá is way more advanced than what is shipped in Geary or KDE PIM -- and it is this solid foundation which leads to Trojitá's performance. What needs work now is polishing the GUI and making it play well with the rest of a users' system. I don't care whether this polishing means improving Trojitá's GUI iteratively or whether its IMAP support gets used as a library in, say, KMail -- both would be very succesfull outcomes. It would be terrific to somehow combine the nice, polished UI of the more established e-mail clients with the IMAP engine from Trojitá. There is a GSoC proposal for integrating Trojitá into KDE's Kontact -- but for it to succeed, people from other projects must get involved as well. I have put seven years of my time into making the IMAP support rock; I would not be able to achieve the same if I was improving KMail instead. I don't need a fast KMail, I need a great e-mail client. Trojitá works well enough for me. Oh, and there's also a currently running fundraiser for better address book integration in Trojitá. We are not asking for $ 100k, we are asking for $ 199. Let's see how many people are willing to put the money where their mouth is and actually do something to help the PIM on a free desktop. Patches and donations are both equally welcome. Actually, not really -- great patches are much more appreciated. Because Jos is right -- it takes a lot of work to produce great software, and things get better when there are more poeple working towards their common goal together. Update: it looks like my choice of kickstarter platform was rather poor, catincan apparently doesn't accept PayPal :(. There's the possiblity of direct donations over SourceForge/PayPal -- please keep in mind that these will be charged even if less donors pledge to the idea. [Less]

Jos wrote a blog post yesterday commenting on the complexity of the PIM problem. He raises an interesting concern about whether we would be all better if there was no Trojitá and I just improved KMail instead. As usual, the matter is more complicated ... [More] than it might seem on a first sight. Executive Summary: I tried working with KDEPIM. The KDEPIM IMAP stack required a total rewrite in order to be useful. At the time I started, Akonadi did not exist. The rewrite has been done, and Trojitá is the result. It is up to the Akonadi developers to use Trojitá's IMAP implementation if they are interested; it is modular enough. People might wonder why Trojitá exists at all. I started working on it because I wasn't happy with how the mail clients performed back in 2006. The supported features were severely limited, the speed was horrible. After studying the IMAP protocol, it became obvious that the reason for this slowness is the rather stupid way in which the contemporary clients treated the remote mail store. Yes, it's really a very dumb idea to load tens of thousands of messages when opening a mailbox for the first time. Nope, it does not make sense to block the GUI until you fetch that 15MB mail over a slow and capped cell phone connection. Yes, you can do better with IMAP, and the possibility has been there for years. The problem is that the clients were not using the IMAP protocol in an efficient manner. It is not easy to retrofit a decent IMAP support into an existing client. There could be numerous code paths which just assume that everything happens synchronously and block the GUI when the data are stuck on the wire for some reason. Doing this properly, fetching just the required data and doing all that in an asynchronous manner is not easy -- but it's doable nonetheless. It requires huge changes to the overall architecture of the legacy applications, however. Give Trojitá a try now and see how fast it is. I'm serious here -- Trojitá opens a mailbox with tens of thousands of messages in a fraction of second. Try to open a big e-mail with vacation pictures from your relatives over a slow link -- you will see the important textual part pop up immediately with the images being loaded in the background, not disturbing your work. Now try to do the same in your favorite e-mail client -- if it's as fast as Trojitá, congratulations. If not, perhaps you should switch. Right now, the IMAP support in Trojitá is way more advanced than what is shipped in Geary or KDE PIM -- and it is this solid foundation which leads to Trojitá's performance. What needs work now is polishing the GUI and making it play well with the rest of a users' system. I don't care whether this polishing means improving Trojitá's GUI iteratively or whether its IMAP support gets used as a library in, say, KMail -- both would be very succesfull outcomes. It would be terrific to somehow combine the nice, polished UI of the more established e-mail clients with the IMAP engine from Trojitá. There is a GSoC proposal for integrating Trojitá into KDE's Kontact -- but for it to succeed, people from other projects must get involved as well. I have put seven years of my time into making the IMAP support rock; I would not be able to achieve the same if I was improving KMail instead. I don't need a fast KMail, I need a great e-mail client. Trojitá works well enough for me. Oh, and there's also a currently running fundraiser for better address book integration in Trojitá. We are not asking for $ 100k, we are asking for $ 199. Let's see how many people are willing to put the money where their mouth is and actually do something to help the PIM on a free desktop. Patches and donations are both equally welcome. Actually, not really -- great patches are much more appreciated. Because Jos is right -- it takes a lot of work to produce great software, and things get better when there are more poeple working towards their common goal together. Update: it looks like my choice of kickstarter platform was rather poor, catincan apparently doesn't accept PayPal :(. There's the possiblity of direct donations over SourceForge/PayPal -- please keep in mind that these will be charged even if less donors pledge to the idea. [Less]

There's a lot of people who are very careful to never delete a single line from an e-mail they are replying to, always quoting the complete history. There's also a lot of people who believe that it wastes time to eyeball such long, useless texts. One ... [More] of the fancy features introduced in this release of Trojitá, a fast Qt IMAP e-mail client, is automatic quote collapsing. I won't show you an example of an annoying mail for obvious reasons :), but this feature is useful even for e-mails which employ reasonable quoting strategy. It looks like this in the action: When you click on the ... symbols, the first level expands to reveal the following: When everything is expanded, the end results looks like this: This concept is extremely effective especially when communicating with a top-posting community. We had quite some internal discussion about how to implement this feature. For those not familiar with Trojitá's architecture, we use a properly restricted QtWebKit instance for e-mail rendering. The restrictions which are active include click-wrapped loading of remote content for privacy (so that a spammer cannot know whether you have read their message), no plugins, no HTML5 local storage, and also no JavaScript. With JavaScript, it would be easy to do nice, click-controlled interactive collapsing of nested citations. However, enabling JavaScript might have quite some security implications (or maybe "only" keeping your CPU busy and draining your battery by a malicious third party). We could have enabled JavaScript for plaintext contents only, but that would not be as elegant as the solution we chose in the end. Starting with Qt 4.8, WebKit ships with support for the :checked CSS3 pseudoclass. Using this feature, it's possible to change the style based on whether an HTML checkbox is checked or not . In theory, that's everything one might possibly need, but there's a small catch -- the usual way of showing/hiding contents based on a state of a checkbox hits a WebKit bug (quick summary: it's tough to have it working without the ~ adjacent-sibling selector unless you use it in one particular way). Long story short, I now know more about CSS3 than I thought I would ever want to know, and it works (unless you're on Qt5 already where it assert-fails and crashes the WebKit). Speaking of WebKit, the way we use it in Trojitá is a bit unusual. The QWebView class contains full support for scrolling, so it is not necessary to put it inside a QScrollArea. However, when working with e-mails, one has to account for messages containing multiple body parts which have to be shown separately (again, for both practical and security reasons). In addition, the e-mail header which is typically implemented as a custom QWidget for flexibility, is usually intended to combine with the message bodies into a single entity to be scrolled together. With WebKit, this is doable (after some size hints magic, and I really mean magic -- thanks to Thomas Lübking of the KWin fame for patches), but there's a catch -- internal methods like the findText which normally scroll the contents of the web page into the matching place no longer works when the whole web view is embedded into a QScrollArea. I've dived into the source code of WebKit and the interesting thing is that there is code for exactly this case, but it is only implemented in Apple's version of WebKit. The source code even says that Apple needed this for its own Mail.app -- an interesting coincidence, I guess. Compared with the last release, Trojitá has also gained support for "smart replying". It will now detect that a message comes from a mailing list and Ctrl+R will by default reply to list. Thomas has added support for saving drafts, so that you are not supposed to lose your work when you accidentally kill Trojitá anymore. There's also been the traditional round of bug fixes and compatibility improvements. It is entertaining to see that Trojitá is apparently triggering certain code paths in various IMAP server implementations, proprietary and free software alike, for the first time. The work on support for multiple IMAP accounts is getting closer to being ready for prime time. It isn't present in the current release, though -- the GUI integration in particular needs some polishing before it hits the masses. I'm happy to observe that Trojitá is getting features which are missing from other popular e-mail clients. I'm especially fond of my pet contribution, the quote collapsing. Does your favorite e-mail application offer a similar feature? In the coming weeks, I'd like to focus on getting the multiaccounts branch merged into master, adding better integration with the address book (Trojitá can already offer tab completion with data coming from Mutt's abook) and general GUI improvements. It would also be great to make it possible to let Trojitá act as a handler for the mailto: URLs so that it gets invoked when you click on an e-mail address in your favorite web browser, for example. And finally, to maybe lure a reader or two into trying Trojitá, here's a short quote from a happy user who came to our IRC channel a few days ago: 17:16 < Sir_Herrbatka> i had no idea that it's possible for mail client to be THAT fast One cannot help but be happy when reading this. Thanks! If you're on Linux, you can get the latest version of Trojitá from the OBS or the usual place. Cheers, Jan [Less]

There's a lot of people who are very careful to never delete a single line from an e-mail they are replying to, always quoting the complete history. There's also a lot of people who believe that it wastes time to eyeball such long, useless texts. ... [More] One of the fancy features introduced in this release of Trojitá, a fast Qt IMAP e-mail client, is automatic quote collapsing. I won't show you an example of an annoying mail for obvious reasons :), but this feature is useful even for e-mails which employ reasonable quoting strategy. It looks like this in the action: When you click on the ... symbols, the first level expands to reveal the following: When everything is expanded, the end results looks like this: This concept is extremely effective especially when communicating with a top-posting community. We had quite some internal discussion about how to implement this feature. For those not familiar with Trojitá's architecture, we use a properly restricted QtWebKit instance for e-mail rendering. The restrictions which are active include click-wrapped loading of remote content for privacy (so that a spammer cannot know whether you have read their message), no plugins, no HTML5 local storage, and also no JavaScript. With JavaScript, it would be easy to do nice, click-controlled interactive collapsing of nested citations. However, enabling JavaScript might have quite some security implications (or maybe "only" keeping your CPU busy and draining your battery by a malicious third party). We could have enabled JavaScript for plaintext contents only, but that would not be as elegant as the solution we chose in the end. Starting with Qt 4.8, WebKit ships with support for the :checked CSS3 pseudoclass. Using this feature, it's possible to change the style based on whether an HTML checkbox is checked or not . In theory, that's everything one might possibly need, but there's a small catch -- the usual way of showing/hiding contents based on a state of a checkbox hits a WebKit bug (quick summary: it's tough to have it working without the ~ adjacent-sibling selector unless you use it in one particular way). Long story short, I now know more about CSS3 than I thought I would ever want to know, and it works (unless you're on Qt5 already where it assert-fails and crashes the WebKit). Speaking of WebKit, the way we use it in Trojitá is a bit unusual. The QWebView class contains full support for scrolling, so it is not necessary to put it inside a QScrollArea. However, when working with e-mails, one has to account for messages containing multiple body parts which have to be shown separately (again, for both practical and security reasons). In addition, the e-mail header which is typically implemented as a custom QWidget for flexibility, is usually intended to combine with the message bodies into a single entity to be scrolled together. With WebKit, this is doable (after some size hints magic, and I really mean magic -- thanks to Thomas Lübking of the KWin fame for patches), but there's a catch -- internal methods like the findText which normally scroll the contents of the web page into the matching place no longer works when the whole web view is embedded into a QScrollArea. I've dived into the source code of WebKit and the interesting thing is that there is code for exactly this case, but it is only implemented in Apple's version of WebKit. The source code even says that Apple needed this for its own Mail.app -- an interesting coincidence, I guess. Compared with the last release, Trojitá has also gained support for "smart replying". It will now detect that a message comes from a mailing list and Ctrl+R will by default reply to list. Thomas has added support for saving drafts, so that you are not supposed to lose your work when you accidentally kill Trojitá anymore. There's also been the traditional round of bug fixes and compatibility improvements. It is entertaining to see that Trojitá is apparently triggering certain code paths in various IMAP server implementations, proprietary and free software alike, for the first time. The work on support for multiple IMAP accounts is getting closer to being ready for prime time. It isn't present in the current release, though -- the GUI integration in particular needs some polishing before it hits the masses. I'm happy to observe that Trojitá is getting features which are missing from other popular e-mail clients. I'm especially fond of my pet contribution, the quote collapsing. Does your favorite e-mail application offer a similar feature? In the coming weeks, I'd like to focus on getting the multiaccounts branch merged into master, adding better integration with the address book (Trojitá can already offer tab completion with data coming from Mutt's abook) and general GUI improvements. It would also be great to make it possible to let Trojitá act as a handler for the mailto: URLs so that it gets invoked when you click on an e-mail address in your favorite web browser, for example. And finally, to maybe lure a reader or two into trying Trojitá, here's a short quote from a happy user who came to our IRC channel a few days ago: 17:16 < Sir_Herrbatka> i had no idea that it's possible for mail client to be THAT fast One cannot help but be happy when reading this. Thanks! If you're on Linux, you can get the latest version of Trojitá from the OBS or the usual place. Cheers, Jan [Less]

I'm happy to announce that Trojitá, a fast IMAP e-mail client, has become part of the KDE project. You can find it below extragear/pim/trojita. Why moving under the KDE umbrella? After reading the KDE's manifesto, it became obvious that the KDE ... [More] project's values align quite well with what we want to achieve in Trojitá. Becoming part of a bigger community is a logical next step -- it will surely make Trojitá more visible, and the KDE community will get a competing e-mail client for those who might not be happy with the more established offerings. Competition is good, people say. But I don't want to install KDE! You don't have to. Trojitá will remain usable without KDE; you won't need it for running Trojitá, nor for compiling the application. We don't use any KDE-specific classes, so we do not link to kdelibs at all. In future, I hope we will be able to offer an optional feature to integrate with KDE more closely, but there are no plans to make Trojitá require the KDE libraries. How is it going? Extremely well! Five new people have already contributed code to Trojitá, and the localization team behind KDE got a terrific job with providing translation into eleven languages (and I had endless hours of fun hacking together lconvert-based setup to make sure that Trojitá's Qt-based translations work well with KDE's gettext-based workflow -- oh boy was that fun!). Trojitá also takes part in the Google Code-in project; Mohammed Nafees has already added a feature for multiple sender identities. I also had a great chat with the KDE PIM maintainers about sharing of our code in future. What's next? A lot of work is still in front of us -- from boring housekeeping like moving to KDE's Bugzilla for issue tracking to adding exciting (and complicated!) new features like support for multiple accounts. But the important part is that Trojitá is live and progressing swiftly -- features are being added, bugs are getting fixed on a faily basis and other people besides me are actually using the application on a daaily basis. According to Ohloh's statistics, we have a well established, mature codebase maintained by a large development team with increasing year-over-year commits. Interested? If you are interested in helping out, check out the instructions and just start hacking! Cheers, Jan [Less]

I'm happy to announce that Trojitá, a fast IMAP e-mail client, has become part of the KDE project. You can find it below extragear/pim/trojita. Why moving under the KDE umbrella? After reading the KDE's manifesto, it became obvious that the KDE ... [More] project's values align quite well with what we want to achieve in Trojitá. Becoming part of a bigger community is a logical next step -- it will surely make Trojitá more visible, and the KDE community will get a competing e-mail client for those who might not be happy with the more established offerings. Competition is good, people say. But I don't want to install KDE! You don't have to. Trojitá will remain usable without KDE; you won't need it for running Trojitá, nor for compiling the application. We don't use any KDE-specific classes, so we do not link to kdelibs at all. In future, I hope we will be able to offer an optional feature to integrate with KDE more closely, but there are no plans to make Trojitá require the KDE libraries. How is it going? Extremely well! Five new people have already contributed code to Trojitá, and the localization team behind KDE got a terrific job with providing translation into eleven languages (and I had endless hours of fun hacking together lconvert-based setup to make sure that Trojitá's Qt-based translations work well with KDE's gettext-based workflow -- oh boy was that fun!). Trojitá also takes part in the Google Code-in project; Mohammed Nafees has already added a feature for multiple sender identities. I also had a great chat with the KDE PIM maintainers about sharing of our code in future. What's next? A lot of work is still in front of us -- from boring housekeeping like moving to KDE's Bugzilla for issue tracking to adding exciting (and complicated!) new features like support for multiple accounts. But the important part is that Trojitá is live and progressing swiftly -- features are being added, bugs are getting fixed on a faily basis and other people besides me are actually using the application on a daaily basis. According to Ohloh's statistics, we have a well established, mature codebase maintained by a large development team with increasing year-over-year commits. Interested? If you are interested in helping out, check out the instructions and just start hacking! Cheers, Jan [Less]

I'm sitting on the first day of the Qt Developer Days in Berlin and am pretty impressed about the event so far -- the organizers have done an excellent job and everything feels very, very smooth here. Congratulations for that; I have a first-hand ... [More] experience with organizing a workshop and can imagine the huge pile of work which these people have invested into making it rock. Well done I say. It's been some time since I blogged about Trojitá, a fast and lightweight IMAP e-mail client. A lot of work has found the way in since the last release; Trojitá now supports almost all of the useful IMAP extensions including QRESYNC and CONDSTORE for blazingly fast mailbox synchronization or the CONTEXT=SEARCH for live-updated search results to name just a few. There've also been roughly 666 tons of bugfixes, optimizations, new features and tweaks. Trojitá is finally showing evidence of getting ready for being usable as a regular e-mail client, and it's exciting to see that process after 6+ years of working on that in my spare time. People are taking part in the development process; there has been a series of commits from Thomas Lübking of the kwin fame dealing with tricky QWidget issues, for example -- and it's great to see many usability glitches getting addressed. The last nine months were rather hectic for me -- I got my Master's degree (the thesis was about Trojitá, of course), I started a new job (this time using Qt) and implemented quite some interesting stuff with Qt -- if you have always wondered how to integrate Ragel, a parser generator, with qmake, stay tuned for future posts. Anyway, in case you are interested in using an extremely fast e-mail client implemented in pure Qt, give Trojitá a try. If you'd like to chat about it, feel free to drop me a mail or just stop me anywhere. We're always looking for contributors, so if you hit some annoying behavior, please do chime in and start hacking. Cheers, Jan [Less]