Himalaya: CLI to Manage Emails
github.comHimalaya makes it pretty easy to write cli tools and automate email workflows. It pairs well with August, another rust project that can render html to text on the terminal. I wrote a git email patch automation tool around Himalaya so that people can receive email patches easily[1].
This is cool. I like the ongoing trend of TUIs getting more attention and use.
A little while ago I wrote my own little TUI tool using Textual that interfaces with Outlook using pywin32. I really only needed (need) one specific feature above and beyond what Outlook already does. And that is, I wanted a Vim-like UX for assigning categories to emails and archiving/deleting them. What I have now works surprisingly well and it's very satisfying to have made my own thing that suits my own needs precisely the way I want it to.
I have been looking for something like this. Got a link to your project?
Hey there. This project isn't posted publicly anywhere at the moment—it's a very idiosyncratic one-of-one sort of deal.
For one thing, while I know Python a little bit, I much prefer to write Lisp. But the Textual [0] library is for Python and nothing else seems to even compete in the same space. So my "outlook-explorer" ("oe" on my command line) is actually written in Hy [1], a Lisp-y syntax swap that emits Python AST objects. And there's a couple places where I just hard-coded my own info, like the email address I'm using it with in order to pull from the right inbox in Outlook, that would need some kind of user-facing and reasonably user-friendly config options before it'd be ready for general consumption.
Have you thought about making your own bespoke one-of-one thing? I got much further than I expected to in only a couple hours. It was already basically functional in three hours, I think, and I came to the table with no prior experience using Textual.
I've also been looking for something like this. Was going to post on the Textual discord actuality to ask around.
Most of the email tools like notmuch tend to be GPL which limits adoption IMHO.
I feel like this has been here before, glad it's kept up with updates. Will have to give this a shot soon.
From strictly reading the docs, I love these features:
* oauth2 * json output
But do I need to run the "himalaya ..." command every so often to get fresh e-mails? Or can I leave TUI open and it will refresh in the background?
When composing messages, does anybody know if the "From" header can be re-written like in Thunderbird? I am able to send from ad-hoc aliases with my mail server, but need to re-write the "From" header first. For example, I can receive mail sent to "xyst.hn@example.com" and delivered to mailbox at "xyst@example.com". In order to reply with same e-mail address, I must re-write the "From" header to match.
It's designed to be a CLI tool as opposed to a TUI so that it's more composable with other CLI tools. So you can use it as a building block to create a TUI, but it's not one by default.
I still use mutt on a daily basis.
Being able to select emails using regular expressions is super useful.
IMAPFilter is also simple and powerful to quickly sort email.
Yes! I use mutt for searching, tagging, thread operations (splitting,appending etc.), bouncing, attaching other mails, deleting attachments, openpgp (personal), smime (at work), and it works with IMAP out of the box.
I am also able to integrate (a locally hosted) LanguageTool to check the grammar in the editor.
The only issue is to write emails with embedded images. But personally I don't like such emails for occupying the space of the mailbox.
What do you use to fetch email? mbsync keeps messing up the UID of emails with gmail.
Personnaly, I use https://gitlab.com/shackra/goimapnotify , you can add a `~/.config/imapnotify/{{ youremailaddresshere }}.yaml` config file for each of your email addresses and enable and start it as a systemd service with `systemctl --user enable ---now goimapnotify@{{ youremailaddresshere }}.service`
Here is and example of a config file for a gmail address :
```
```host: imap.gmail.com port: 993 tls: true tlsOptions: rejectUnauthorized: false username: {{ youremailaddresshere }} password: '' passwordCMD: pass mw/{{ youremailaddresshere }} | head -n1 onNewMail: mailsync {{ youremailaddresshere }} | while read OUTPUT; do notify-send "" "$OUTPUT"; done onNewMailPost: '' onDeletedMail: '' onDeletedMailPost: '' boxes: - INBOX> format
indent it with 2+ spaces
like thisThanks!
> tlsOptions:
> rejectUnauthorized: false
Means trust any cert?
Yes, thanks for pointing it out, it should be true.
I took it from my config which I did a long time ago and I guess I didn't pay attention enough when doing it, my bad !
Just Mutt's IMAP support.
offlineimap does the job for me I use it with Gmail and owa (trough davmail)
Does it support email filters? I'd love to manage my gmail filters programmatically or use a configuration file to manage them so I can reuse the filters across multiple emails.
Edit: there is a separate tool for this for gmail https://github.com/mbrt/gmailctl
Neat. I used and loved “mh” in college, but that was before html email became prevalent. It was beautiful to have different commands and treat emails as individual files. Unfortunately mh was grotty old C code and just couldn’t keep up (IMHO) with how we use email today.
shameless plug: i wrote emlv[1] (EMaiL Viewer) in the same mindset. it displays raw email files on the terminal.
> I used and loved “mh” in college
Same and also `nmh`. Loved how you could combine the various parts to make your own tools.
me too - nmh and MH-E still learning though
I'm confused, it is called 'Pimalaya' or 'Himalaya'
Pimalaya is the org, Himalaya is the mail client, AFAIK
I think the README is missing some examples of what this can do. I used it for a script that marks every mail as seen:
#!/bin/bash
while true; do
# Run the command and capture its exit code
result=$(himalaya envelope list --folder INBOX --page 1 --page-size 100 --output json not flag Seen | \
jq -r '.[] | "\(.id) Seen"')
exit_code=$?
# Check the exit code of `himalaya`
if [[ $exit_code -ne 0 ]]; then
echo "No more unseen emails to process or an error occurred."
break
fi
# Check if result is empty
if [[ -z "$result" ]]; then
echo "No more unseen emails to process."
break
fi
# Process unseen emails
echo "$result" | xargs himalaya flag add
echo "Processed unseen emails. Checking for more..."
done
Another idea I had was to use it to sort mails into folders by the receipient address suffix (my.name+amazon@example.com would sort into the amazon folder), which should be possible if I have read the man pages correctly.
Anyway, thanks for this, not sure if this is the "best" way for me to work with mails but it absolutely is the first tool that made me start automating my inbox.
I love that logo.
Brilliant logo, thanks for pointing it out, I was just reading the comment before deciding if it was worth it to check out the project page.
Genuine question - the HN title says "CLI to..." but looking at the GitHub repo I don't see any CLI-centric documentation.
I do see
$ himalaya envelope list --account posteo --folder Archives.FOSS --page 2
I guess my question is: is this different than PINE (or any other terminal-based, interactive email client)?
Himalaya is not interactive: while Pine is a TUI, this is a CLI. Very useful to integrate emails in scripts easily.
The built release packages have full set of man-pages for you to familiarize with.
Looks like mblaze but with extra steps
last release 2017, good game. also only works on Windows with Linux emulator.
No? Version 1.3 was tagged in the repo September 13 this year.
https://github.com/leahneukirchen/mblaze/tags
And correspondingly of course that’s the version package repos have/will published too.
For example, Alpine Linux has that version in a community package repo on a branch.
https://pkgs.alpinelinux.org/package/edge/community/x86/mbla...
FreeBSD package repo is a little behind, still on v1.2 instead of v1.3. But that’s still a version from March of this year.
https://www.freshports.org/mail/mblaze
And even if the most recent release of mblaze really had been a few years ago, it could still be good software. Especially for email.
> last release 2017
feature not a bug
> does not work on Windows
ditto
Is anyone using local LLMs to manage their email? This seems like it could be helpful to hook that up.
Been eyeing this project for a while, hesitant to pull the trigger before a 1.0, just because email is a pain to configure, and having to keep up with changes before a 1.0 would have been a pain.
I'd love to see a blog or some post on the roadmap for this project (and the org in general).
you are in luck then, they just cut 1.0 4 hours ago =)
This looks like it's a "real" CLI instead of a curses thing (TUI?). That's really exciting for me. I strongly prefer tools that can be composed as a standard shell pipeline.
Edit: That is indeed exactly what this is. It's wonderful :)
Amazing! Love the idea, and I really love the “sponsorship” part. It’s very cool that a project like this can get funding.
The “MML” MIME markup language is new to me. It is strange that it’s neither markdown based nor does it automatically build the plain text part for you.
On the few occasions these days where I compose an email in mutt (via vim) I find I end up writing markdown _anyway_* so supporting it as an authoring format would be fantastic.
Alas, a lot of professional interactions require HTML emails. I don’t want to come across as awkward nerd to everyone all the time.
*!:)
Looks nice. No JMAP though :/
I use alpine over at sdf.org. I'd love to use this instead.
Well Himalayas are definitely better than Alps! :)
Q: Can I use this if I work at a Microsoft Teams enterprise org? Probably not, I'm guessing, but hoping there's a way to make that work somehow.
Depends, likely not as Microsoft strongly recommends disabling IMAPv4 and POP3 access to mailboxes in 365 and I think it's now the default. Most company policies do not allow it to be enabled outside service mailboxes.
Do you mean Microsoft 365 for Enterprise? Teams is the chat app.
Thunderbird can sync with Microsoft 365 for Enterprise mail servers and can be configured to store email in a maildir format. So you could use Himalaya to read emails that Thunderbird synced, but you can't manipulate Thunderbirds maildir.
I haven't tried, but the README mentions Office 365 and OAuth, so perhaps?
Sorry this is pretty low-value but I love that organization name. Pimalaya. Cute and very fun to say.
In Dutch it's very fun to say, but not cute ;) sounds like slang for the male genitalia.
This seems really nice. I wonder how it handles accounts with two-factor authentication, sms and yubikey.
API Dev keys, e.g. https://developers.google.com/identity/protocols/oauth2#1.-o....
After testing many clients I learnt to stop worrying and just use Mail app.
Mail causes me to procrastinate so much, and I have no idea why. I use icloud everything, so I wanted my mail there as well, but after 12-13 months I switched back to FastMail because their UX is subtly better suited to quickly sorting through mail for me. And fwiw I'm afaik not using any FastMail features that Mail doesn't have.
I don't mean this in the way that Client A > Client B, but I have spent a fair amount of thought on this, and I have not been aple to pinpoint exactly what characteristics makes the difference for me, which I find to be interesting in itself.
My goal is always to have an empty inbox. So, emails that require some sort of action from my part but are not urgent I will snooze them (Gmail feature) to a later time. Email that's like "ok thanks for letting me know" and that's the end of that interaction, I will delete. Other stuff that requires more immediate attention I'll let it hang in the inbox for at most a few days and then try to act on them.
I noticed that letting mails linger in sight in my inbox is energy draining or causes me to procrastinate.
Last week I searched for an email in Mail.app. It was right there on the screen and it couldn’t find it. It also fails to display or even list some attachments.
This is unacceptable to me. Yet I keep using it because I dislike Gmail’s web interface and my Vim imap setup is not really usable yet and probably never will be.
Outlook has the same searching issue. I often have to resort to manually eyeballing through my email archives to find what I'm looking for. Very annoying indeed.
I'm here too.
I've used many, many different clients over the last few decades (yes, including Linux `mail`). I have to use Outlook at work, and I have to use my providers' web clients on my Windows gaming PC, but on all my other devices I use Mail.app.
I just... don't ever use all the features of the other clients, or don't like some of the behavior they have, or any of that. For a long time I would get excited about new email clients and try them out right away, but no more.
I dunno if it's just that I'm getting old, or if I just don't care as much, or both, or something else.
I use many features of Thunderbird. And it works fine with outlook, even including calendaring, with the Owl plugin. It is a paid plugin, but it makes life much better.
I've tried to use Thunderbird several times over the years, and I always ended up going to something else. Maybe the UI bothered me, I'm not sure.
Indeed, I'm additionally using https://mimestream.com for company Gmail as the Gmail support in Mail.app is sometimes a bit lacking (Labels etc.), but it's also a good way to keep private and work emails separated.
Another vote for mimestream! Was an early free user and love the app. Definitely worth supporting them.
I feel you. I now just use email in my web browser via the respective providers recommended website, aka mail.google.com, microsoft.office365.exchange.email or whatever it is they are calling it these days.
MailMate did that for me.
I just wish that Mail.app would have a seamless ingegration with Calendar.app like Microsoft already provides with Outlook. Also the label system feels very outdated compared to Outlook.
Kanmail turns your Gmail labels to a columnar kanboard, pretty useful in wide screens https://kanmail.io/
How does this compare to old school mblaze tools?
I liked mutt, but this seems promising as well.
I can go a week now without receiving a single useful email...gmail or fastmail are fine
They are, but I have a cron job that fetches my email every 5 minutes. No need to keep a tab open, or do the auth routine again and again. And I used to put an indicator in my status bar displaying the unread count. There’s a whole world of integration when you just dig a bit deeper.
Honest question - Why use interfaces like this, but not regular HTML client?
There are many choices for email client interfaces. HTML for email does not have a good reputation among hackers. After all, email can be considered an ancient technology and is historically based on plain text - HTML breaks not only the philosophy but also many of the tools developed around email.
I have found a sweet spot for an email client between a pure CLI and a full-featured (HTML) GUI client - I use Emacs Gnus, which takes full advantage of Emacs' text-based interface. As always with Emacs, the learning curve is a bit steep at first, but the rewards can be reaped afterwards.
> As always with Emacs, the learning curve is a bit steep at first
For any Emacs users who are interested in using Emacs for mail but don't want to deal with the learning curve of Gnus, check out mu4e, which is easier.
The main reason I chose Gnus instead of mu4e or notmuch is that I did not want to sync all my mailboxes to local disk. What is perhaps not so well known is that IMAP provides its own server-side search engine. Searching mail with Gnus search queries [1] works really well, and I do not have to manage any overhead to get my mail synchronized, indexed, etc. In other words, everything I need for email is built into Emacs (or outsourced to the IMAP server) - no extra packages/software required.
[1] https://www.gnu.org/software/emacs/manual/html_node/gnus/Sea...
This. I kinda hate, but still understand, the general offlineimap/notmuch philosophy in this space. I am not in a bunker, I am not optimizing for a situation where I only have internet intermittently. I just don't want to leave emacs if I dont have to and want to be able to be quick and seamless between my code, mailing lists, rss feeds, org mode, and email in general. It was hard won, but I do get this with Gnus now. And yes, love how you can hijack almost all the IMAP/gmail niceties this way with a little bit of work, especially search.
One thing I have done is export the mbox archives of my old gmail accounts and keep them around in Gnus if I happen to need to search through old emails.
mu4e paired with mbsync is really amazing. All your email in Emacs, with super fast search, and the ability to integrate into things like org agenda.
I found this guide particularly useful for setting things up and even dealing with annoying outlook/office365 servers:
https://brettpresnell.com/post/email/
Does take a bit of doing, but so worth it.
> HTML breaks not only the philosophy but also many of the tools developed around email
I was one of these die-hard-text-only people, back in the mid to late 90s. It was true. People were sending HTML/rich text emails, and it broke everything, and it was awful to read with. Not to mention the kilobytes of bandwidth wasted!
But it's 2024 now. There are vastly more tools that can deal with HTML email than those that can't. Like, I wouldn't be surprised if it's 4 orders of magnitude.
Sorry, folks, we lost. Email is not plain text any more. We can't pretend that it is or should be.
> Email is not plain text any more. We can't pretend that it is or should be.
I send plain text emails and this is a hill I will die on. :-)
Do you not contribute to the development of any open-source projects that only accept patches via plain text emails sent to mailing lists (e.g., many GNU projects)?
Here's a tip for anyone who sends plain text emails, or wants to, and has to deal with annoying normies who complain about undesirable wrapping[1] when viewing plain text emails on mobile devices with small screens: configure your mail client to allow lines in emails to be up to 998 characters[2], which is longer than any paragraph you will likely write. I did this for my work email years ago.
[1] https://www.arp242.net/email-wrapping.html
[2] https://datatracker.ietf.org/doc/html/rfc5322#section-2.1.1
> I send plain text emails and this is a hill I will die on. :-)
I don't want to be mean, but yes, it is likely this hill will die with you :-)))
I doubt you can find many 18 year olds these days that would willingly use plain text emails.
As someone who started using plaintext emails recently, HTML emails are still awful in 2024. Besides being a ugly hack on top of an originally text-only protocol, it encourages bad practices like top-posting, bad alignment etc. What's really intolerable though, is the external and dynamic content in email. I expect email to be a long-term record, not something that changes after I receive it. They should find another tool for that. Besides, most GUI clients just block external content due to security risks anyway.
Perhaps LLMs can solve this somewhat? Not for email summarization - but to intelligently strip away all the HTML fluff and return a plain text version of the contents.
It is a solved problem. Here is a solution that requires something of the order of 1,000,000th of the resources of your proposed idea, no subscription, and runs so fast that you would not even notice it on a machine from 20 years ago:
If you want something more modern:> grep text/html ~/.mailcap text/html; lynx -width 72 -assume_charset=%{charset} -display_charset=utf-8 -dump %s | sed 's|^ ||'; nametemplate=%s.html; copiousoutputtext/html; webdump -dli < %s | sed 's/^ //g'; needsterminal; copiousoutputFWIW, it's pretty straightforward to extract text from an HTML snippet without LLMs, I'm not actually sure if there's anything they'd do better than a simple HTML parser.
Apple Intelligence already does this in the line summary.
> But it's 2024 now. There are vastly more tools that can deal with HTML email than those that can't. Like, I wouldn't be surprised if it's 4 orders of magnitude.
Is it? Whatsapp, Signal, Slack, Notion, ChatGTP, are amongst the apps I use daily - and used by many non-hacker daily, that's pretty much "text only". all support some (subset of) markdown, which is close to "plain text" than to "HTML" in editing and displaying.
What I am trying to say is not that email should use markdown, or that HTML-email is bad or good. What I am trying to say is that there's clear and obvious proof that, in 2024, there's a need and use for "plain text". Even in tools that overlap with what email does.
Slack is far from plain text: https://api.slack.com/block-kit/building
The Slack blocks format is horrendous, and not very powerful.
I disagree that email should be plain text, but honestly I don't think that's really relevant to the question. I read the question as "why CLI instead of GUI", which I think is totally fair. Using a CLI email client instead of a GUI strikes me like using your feet to open jars - maybe you can do it, but it's so much harder for no benefit.
I think it's not the question. One can continue using GUI, and value CLI for its flexibility. E.g. if I'd like to script some routine task, availability of a CLI tools will make it a breath. In the average case of GUI it's either impossible altogether, or requires some ugly user input simulation. Which is like using your feet to open jars - to borrow your comparison
As another commenter pointed out, CLI/TUI isn't that hard. In many cases it's easier than GUI ones. But I have a different purpose. I can configure different pieces (imap for incoming, smtp for outgoing, notmuch & afew for tagging and search, etc) and use it uniformly from a variety of different programs including git and emacs. Not very simple, I must admit. But it's a personal choice. It works very well for my use cases, including realtime full mail backup and offline use.
It just depends on the user. You probably also think cd & ls is so much harder than Finder or whatever.
> Using a CLI email client instead of a GUI strikes me like using your feet to open jars - maybe you can do it, but it's so much harder for no benefit.
Eh? I used to use mutt and now use notmuch. Much simpler to use than, say, Outlook. Not sure what you're talking about being "harder".
Absolutely right. Every GUI email client that I’ve tried is clumsy and slow. Mutt is elegant, powerful, and fast.
This question shows how far we’ve travelled from the original concepts of sending/receiving/viewing email. I just found it funny that you said “regular HTML client”, as if that was the default interface for email. Originally, it was all text, so this post is in many ways closer to how many thought of a “regular” client. But ever since Hotmail, it’s been a gradual shift away from command line email towards web applications. Desktop GUIs are still (kind of) holding on, but even they are more likely than not to be an Electron app.
To answer your question, these days, I’m not sure. There are so many extra features that email providers (Gmail/Office365) include in their web interfaces, it’s hard to not make the argument that the web interfaces are the better way to use email.
There are times it's really useful to access email from a terminal, and terminals are widely available (shell on your primary system, Termux on Android, SSH to your email host, whatevs).
It's also often convenient to either script interactions, or to have full access to shell tools when interacting with email. I practice this more often with mutt, but I can filter either messages or metadata (headers) and send those to an awk or sed pipeline to extract specific information of interest (this is especially useful with notifications / alert emails). This might be tens, hundreds, thousands, or more messages that are of interest.
Full-blown GUI or Web client email tools are pretty, but lack this flexibility.
I don't have much knowledge regarding mail but I can think of two reasons.
First is the use of mailboxes if your mail provider does not provide you with an IMAP server to connect to in which case you'll use a client like mutt to manage your mails.
Second one is the accesibility through the terminal could be reduced with HTML sites. If I want to access my email through a headless server using lynx or similar having to refresh the website to check new mails, or even composing them might be difficult.