HERMES Mail - A full-featured eMail client for Haiku?


Hello, world. This is going to sound strange as all get-out, but I’ll just jump into it and let you judge for yourself.

I’ve “inherited”, in large part, the codebase of the old Eudora mail client for Windows (we’re talking 2004-era vintage). Problem is, I’m not anything close to a coder (I’ve written programs in LISP, but this is pure C++, and it is a big project). I’m good with architectural decisions, high-level stuff, planning, Web development, support, p.r., practically everything but the code. So I managed to wangle a few coders to do the work, and meanwhile, I’ve put the word out, taken executive decisions on the name/colour scheme/user experience/iconset, set up one Kickstarter after another (netting us about $4,000 in funds), frontend development for a new Web site, etc etc etc…

Eudora as originally abandoned in 2004 is still a great eMail client; the business code is pretty much close to perfect, and what wasn’t (mainly OpenSSL) we replaced with newer versions. The first production-quality release of HERMES Mail (numbered 8.0 to maintain continuity with Eudora, with a name change for legal reasons) is due out any day now.

Anyway, HERMES Mail is constructed with pure C++, no third-party toolkits involved. The GUI is pure MFC (that was not the case six months ago). And all of this got me thinking, as a Haiku user familiar with its monolithic philosophy, why not try to port it over? The business code shouldn’t require much of a change, and Haiku lacks what I’d call a “full-featured” eMail client written with the Haiku Way in mind.

Would anyone be up for writing (a GUI for) an eMail client in C++? The MFC GUI would work as a great template, the business code is roughed in, there are no preconceived expectations (as there are for Mac)…


For anyone willing to waste some time on this, the Bitbucket Mercurial repo is here: The GUI parts of it are a bit dated (we’ve got one person doing GUI, and while it’s pretty close to working on his computer, he won’t check it in on Mercurial unless it’s Finished with a capital F - says it’ll be done in a day or two max.) But the business code is all done, basically.

We’ve mostly been using Visual Studio as an IDE.


There are a few things that would make good additions that I’ve seen people use a lot (preseeded replys based on message content like "Sure sounds great!, I can’t make it, can we reschedule etc… "). It would be awesome to have those features in a local email client not running on a remote server.

I know this is a lot to ask, but at work I must use Exchange + Calendar… so… that is what it is. Perhaps Exchange support is deserving of it’s own kickstarter.

Porting this might make a decent succession of GSoC projects… Divided into get it running with a basic UI, get all the settings dialogs working, UI polish etc… it would take years but that’s a potential way to go. Also whoever does the port should take advantage of Haiku’s features in the UI such layout management, window stacking/tiling and the advanced filesystem search features.


Preseeded replies, and whole templates, are part of what we’re working on for version 8.5. Another is heuristic detection of phone numbers, package numbers, addresses, etc. Then there’s mail merge and fields (good for, for example, sending Dear : letters).

The deadline for GSoC is fast approaching. I’m wondering whether just to go ahead and create a GSoC project on a suo sponte basis…


One thing yahoo webmail does now is auto unsubscribe from mailing lists… that seems like an ideal case for a script/plugin also to enable doing that. It would require some maintenance though I guess or instrumentation to allow users to submit/update macros to do the work for new site/lists.

I often find mailing lists are quire annoying to interact with as well… for instance the folder I send them to is aways unread (I don’t need to be told that by the UI). Top posting is often the default of the mail client… would be nice if it could detect the correct method of posting and do that. Some mailing lists only allow plain text etc… detect that.


Also on the to-do list. Heuristic detection of unsubscribe-from-list, and then popping a big blue (UNSUBSCRIBE) link on top of the message preview window.

The way I figured out what needed to be done was that I looked at Postbox, which is great from a features standpoint but crap from a UI/UX standpoint, and then I crossed out what we already had. The rest (which is about 15 features) is our to-do list.

Bottom posting is already built in. And we have rules similar to Gmail (so we can set up mailing list eMails to go into a user-specified folder and be marked as read).



Isn’t there a bugtracker at Hermes Mail project for sending in feature requests? Doing that on the Haiku forum seems a little unappropriate.

Glad to see the open sourcing of Eudora does not go lost and people are interested in making it live again.

Thanks to the Computer History Museum for getting it released (


@PulkoMandy, I never intended to use this thread for feature requests; I was just responding to questions I was receiving.

Oh, we’re THIS close to making Eudora live on as HERMES for Windows; it should be released to-morrow as a closed beta, and then we’ll open it up around Valentine’s Day or thereabouts. I’m uploading the HERMES Project “corporate” Web site as we speak (front-end development by yours truly).

I was just thinking, given how we managed to port Qualcomm’s proprietary, €3700 toolkit to plain MFC, maybe someone from the Haiku project could be co-opted to help us port the MFC to Haiku’s toolkit? Really, for a power eMail user, it would be so much better than trying to wrestle with either Haiku Mail or a ported Thunderbird.

I know @waddlesplash is busy as all hell, but if we only had one or two people as competent as him, we’d probably have HERMES Mail/H (for Haiku) out within four to six months. It only took us six months to strip Stingray (QC proprietary toolkit) out completely and replace it with MFC, and we only have two developers at present!

inb4 Qt: I know, I know, Qt is a cross-platform toolkit from the word go, and we could’ve used it, but this code was second-hand. Not only that, but Qt apps stand out—and not in a good way. Just compare Inkscape with something like Adobe Illustrator and you’ll KWIM. Qt apps are slower, horrible for universal access (trouble especially for the blind), and don’t mesh with any UI/UX but KDE (which was built with Qt in mind).


Because time is running out, I’ve taken the initiative to complete a GSoC mentorship application. I’ve got exactly one day to finish it.

Unfortunately, we’re essentially a three-man concern at this point in time (Søren Thygesen as MFC specialist, Pete MacLean as C++ coder, and me as Lord High Everything Else), and it’s a fact that organisations with more available mentors stand a better chance of being accepted by Google. So, we’ve got about the same chance of being accepted into GSoC as pigs do of flying unassisted.

I’m thinking, since this is a Haiku-targeted mentorship, would anyone else be willing to serve as a mentor and upgrade our chances to, say, a snowball’s chance of not melting in Hell? Perhaps @pulkomandy or @waddlesplash?


FYI, Haiku also currently has 3 registered mentors.


Off topic, but: I’m filling out the mentorship application as we speak. Any tips? How does Google evaluate, for lack of a better term, “trustworthiness”? We have a BitBucket repo, a Web site under construction, but a lot of the work goes on via eMail and on IRC. Or do they base the acceptance/refusal on the text of the application alone?


Beyond the Summer of Code (and also because I don’t at all expect an acceptance), is anyone willing to try their hand at the code, have a look at it and see how the business code would fit into Haiku as a whole, or even to experiment with converting the MFC into BeAPI?


They will review your description, make sure you have sources online with an open source license, and look at your ideas list to make sure you have ideas suitable for the students to work on.

They also try to balance different type of projects (operating systems, web apps, desktop apps, …) and technologies/languages so that all students can find something they like.


Did you wake up on the wrong side of the bed or something? lighten up… This isn’t the Haiku mailing list after all.


I’m not really interested in this at all, and frankly I’m not sure why Haiku users would be in general. Our own mail client was indeed “barely functional” as of R1/beta1, but we’ve made a ton of improvements in the last 6 months and so it’s approaching general usability now (I think @humdinger has gone back to using it on a daily basis.)

One really can’t have a “Haiku-centric” mail client without the filesystem+attributes-based design, and any cross-platform effort would necessarily not use that for portability’s sake. Hence even Beam is better than any ported effort.


If it supports Exchange protocols, I would be interested. My most often used mailbox is Hotmail, complete with contacts, calendars and reminders. Not that many clients support the Exchange protocol; just found out that Evolution is supposed to support it, so I’ll be trying that in addition to EMClient, which is my current email program.

@waddlesplash you make an excellent point about the file attributes, indexing and search capabilities of Haiku, and it makes me wonder what the porting coders can and will do to take advantage of them.



People are interested probably because its one of the best Email clients… its like the BeOS of email clients.

Kind of like how Opera was the BeOS of browsers… most email clients on Linux even are decidedly lacking.

The native email clients are generally buggy… so if a client with a stable core, and native UI is ported all the better. Why would anyone not want that. I’ll grant you that the current Native email clients theoretically can integrate with Haiku more deeply… however they’ve been mostly unstable and unusable for the entire time I’ve used Haiku. Also from the sound of it the core already has far more features than Haiku’s current clients.


I personally think some focus on stabilizing what we have and implementing missing features would be a simpler and more cohesive task. I really don’t like the work flow of other email systems. The BeOS email system is one of the big reasons I like Haiku. Of course porting users’ favorite apps isn’t a bad thing. I just don’t see them as a viable replacement for what we already have. Keep application ports where they belong, HaikuPorts and HaikuDepot.

BTW, there’s been a lot of work recently on the mail system. Perhaps give it another shot?


Yeah frankly I don’t care, there is something to be said for the native clients but as porting QT5 has proved more is better, and has probably drawn more attention to Haiku and it’s native applications anyway more so than they could have done alone.

Getting an outside developer interested in a port of a popular formerly closed source software, written in c++ with a decoupled core and a yet to be written native UI… isn’t something that happens too often so lets be positive about it lol.

The question I have is… is it possible to compile Hermes without a UI, headless or with a basic ncurses interface?


Frankly, I’m not sure why Haiku users wouldn’t be interested in this. The Haiku mail client is still not only barely functional, but lacks crucial functions for certain business tasks.

For example, something as “stupid” and “inconsequential” as timed mail send is not included. Suppose I’m an accounts executive and I maintain a list of users who are close to being assessed a penalty. I want to send them a penalty notice at midnight on the 31st of February, but I don’t want to have to be at work on that date to send it. I’d rather compose the penalty notice at a time convenient to me, and set the POP3/Exchange/IMAP client to send the message automatically. The fact that neither T-bird nor MS Outlook have this functionality is no excuse. Neither is the fact that I could hypothetically set some sort of cron job to do it on my behalf.

Go to the Postbox web site. Look at their list of features (and they are a for-profit eMail client marketed specifically towards power users). We’re missing about five of those features, and those are mostly AI-based. Domain fencing? We have that. HERMES Mail can warn you if you send outside of your organisation. User fencing? We have that too. Ever hit “Reply All” by accident?

In specific reference to the metadata-based mailstore: HERMES Mail for Windows doesn’t have it (uses a UNIX mailstore file, with messages concatenated one after the other), but we’re pursuing a one-codebase-per-system philosophy. There’s no reason why HERMES Mail for Haiku shouldn’t have it. We could even crib it from Haiku Mail. In fact, that would make the most sense, because Eudora came with an indexing engine called X2.

@ComputeWorldwide, Eudora (and by extension HERMES Mail/Wd, and the hypothetical Mail/H) does indeed support Exchange. If you grok C++, by all means let’s talk about it.