Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
a mailx clone
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
Welcome to MailNex. This is a console/terminal email client (Mail User Agent) in the style of mailx. For installation instructions, see the file INSTALL. For usage instructions, see the file USER.README. Current Status: Still pretty Alpha There is a minimal set of functionality for reading *most* mail with a plain text part. Common/basic operations like forwarding are not yet supported, so I cannot consider this program to be generally useful yet. Very few mailx commands and settings are implemented so far. Non-imap folders don't work. All of this is slowly getting better as I work out various issues. There are a few things where we are already better than mailx. In particular: * Command history and (some) command completion * Uses a system password manager if available. * Show when new mail arrives without waiting for the user to run a command. * preferential header ordering (keep From, To, Date, and Subject together when printing, for example) * Color/attribute support in headline format string * Virtual Folders (make a folder view based on a message list from the real folder, then operate on that list as if it were a folder. Convenient for grouping unread or flagged email together and with low message id numbers). * search engine style searching of messages (after manual indexing) * Basic OpenPGP signing and encryption (PGP/MIME only) And, here are a few things that we fall far behind from mailx (or at least the heirloom mailx variant): * No message forwarding support * many variant commands are missing (e.g. Reply (not reply)) * incomplete message list support * difficult to install due to non-distro package requirements * No support for local spool/mbox/maildir nor pop3. Goals: be like mailx, supporting the useful bits of bsd-mailx and heirloom-mailx. Add features that most people expect should have been implemented long ago * PGP format signing/encryption * subpart referencing and display (e.g. syntax to explicitly save an attachment without having to 'write /dev/null' and work your way through all of the parts) * readline or similar * notifications (in particular, new mail received) * address book search while selecting email addresses * support external program (e.g. khard) * possibly support "recent" addresses, like kmail used to (kmail still has the feature, but it currently only stores the username and host with no other data, like full name) * Somewhat better calendar support for example, a multipart/alternative with a text/calendar part should default to displaying a processed version of the text/ calendar part instead of defaulting to the text/plain. There are some emailers (google? outlook.com?) that send a set of text/plain,text/html,text/calendar and leave the text/plain and text/html EMPTY! very frustrating! * Support accellerated full-body search * posibly using Xapian, Sphinx, or Lucene, or "notmuch" * Support storing mail lists (not mailing lists) into variables, like vim registers * mostly useful for saving search results for re-use. for example, I'll do a complicated IMAP style search that takes 2 minutes. I want to read the 3rd result, then the 5th, then review the list again or whatever. In current heirloom-mailx, the moment I move to a particular message, that replaces the current mail list with that one message, so to retrieve the list I have to reperform the 2 minute search. * Support searching within a mail list. For example, I perform one search which gives me a list of say 50 messages. I'd like to refine the search without running over the entire list again. I should be able to do a new search that only looks at those 50 messages. * Support different pagers and CRT values based on command and possibly terminal type * e.g. CRT full screen for the find command, but 0 for viewing mail. * Might want to disable paging or have a very big CRT when using tmux so that you get its scroll-back buffer instead. * Support better editing of message structure * Biggest example is being able to edit an attachement, even when there isn't a real file backing it. Other projects (or, why another mail client): I had been a user of kmail for a LONG time. Then they went and broke it in the move to KDE4 (apparently it works great for the developers, but for me and a bunch of other people, it started doing strange and horrible things to our IMAP folders and started forgetting the people we email). At that point, I did a big overview of alternative mail programs, and ended up settling on heirloom-mailx (openssl version from Ubuntu) because it was very fast and required very little setup to Just Work™. After I started this project (like, seriously, day 3) I ran accross 'sup' which wasn't in my previous overview. It has some of the same goals as me and an interesting philosophy statement. However, I'm continuing this project because I generally like the mailx interface (sup appears to try to have a GUI/TUI approach like cone, pine, and mutt), and because I also want something I can hack on, and I don't know ruby. Additionally, the sup homepage appears defunct right now. * sup - designed to be FAST and handle mailing lists especially well. It uses xapian for search, which is the same decision I made. Developer liked mutt as their primary MUA originally. Then they liked how GMail dealt with threads and search, but not the implementation (top posting, HTML, single level threads) It also borrows from mutt, emacs, and vi for efficiency of console use. Used to support remote mail, but now delegates that. Delegation is a good unix move, but I haven't enjoyed imap delegators. In particular, they suggest offlineimap to synchronize local maildir with a remote imap host. However, maildir doesn't have a good way to show which side has the more recent data (in particular, flags) for a given message, making synchronization when both sides change something impossible to get right. While I applaud using small programs to do stuff well, I think a mail viewer needs to support remote protocols as a primary function, or utilize a medium that can support it (e.g. not using IMAP or maildir) --Update-- Newer mail servers support detecting changes in flags and such, so there exists the ability to do real synch, so long as UIDs are handled carefully. 'offlineimap' seems to have put a decent amount of thought into this, though I haven't actually tried it yet. I have now actually tried sup-mail against my local maildir (from a dovecot clone of my IMAP server). The thread view is amazing. The list with hidden-but-expandable quoted sections is just about exactly what I wanted to accomplish with this project, and the way it shows thread branches is fantastic! That covers an aspect I hadn't figured out yet. It even offers a CLI interface, though that didn't seem as good. The TUI is where the functionality is. My biggest dismay was at the slow speed of the initial indexing. Once that was finished, it was quite snappy. Other great UI bits from sup: Single-line header but easily expanded. Messages per thread in list view, along with attachment icon. First line of text in latest message of thread in list view (doesn't quite get it right for inline or bottom posting, but is otherwise great, especially when the mail contains a quick thanks or a quick question) Parts I don't like: Have to scroll to message thread to open it (akin to no CLI like mailx). Having to have separate sync process. Showing HTML mail as an attachment instead of as alternative content (akin to not showing message structure at all; a feature I sorely miss from kmail. It does make the interface simpler, though). I don't see how I can make viewing threaded emails decent using an external viewer (mailx calls PAGER which I usually set to less, or a script that colorizes before passing to less, or vim). However, you cannot then interract. Closest thing would be pre-folding parts of the message in Vim before giving control to the user (maybe marking up with fold markers), but it wouldn't be the same experience as sup. I think a managed viewer with the option to dole it out would be best. If the user *really* wants to use their own PAGER, go for it. The multiple buffers in sup is also quite nice. A lot like using Vim (but different bindings to switch). I expect it to be quite useful to have multiple threads open in different buffers at the same time and switch between them. Similarly, it would be nice to be able to jump between threads and a new mail. Not sure how to reasonably accomplish that last one when shelling out the editing process (I *really* want Vim for editing, as I'm sure other would want emacs or nano or whatever, and I don't want to implement a poor clone for inline. Maybe wrap Vim like tmux or screen does?). Some things sup handles that I hadn't considered yet (though hopefully I would have eventually): * Linkage between mail folders. In particular, Sent mail needs to be included in order to see all parts of a conversation that you participate in. Additional notes: * The slow initial sync from sup appears to have to do with an inefficiency in the inbox viewer. I noticed this because quitting sup mid-sync and restarting had the import go very fast again, then slow down. The magic number always seems to be about 100 messages in the viewer. After a restart, it doesn't load that many messages, but as it imports they all end up in the view. The proper way to do the initial import seems to be to run sup-sync after you add new mailboxes but before running sup-mail and checking for messages. This runs quite speedily; about the same speed as our indexing goes (which makes sense; we're both using Xapian). * I haven't found a way for sup to watch for changes instead of polling. Additionally, offlineimap *does* have a watch (using IDLE) but they warn it is an incomplete feature and "may well have problems", so the safest thing is to have offlineimap do polling as well. This means that it can be up to 2 poll durations before sup tells me I have new mail. offlineimap defaults to a 5 minute poll interval, which is already longer than I'd like in an active business environment. Turning down the poll period is better response, but more load on me and my mail server. Ideally offloadimap would have well-tested IDLE support, and sup would do dnotify or similar so the OS tells it when there is an update to look at. * Messages read in Sup don't seem to get that status propogated back to the IMAP server. I'm guessing I have something misconfigured. I did check the maildir with heirloom-mailx; it doesn't see any change in flags either, so I'm guessing it is Sup not updating the maildir rather than offlineimap not noticing. * cone - the first terminal mail program I used; originally I set it up while still using kmail for when I logged in remotely (GUI over internet sucks). Not particularly easy to configure, bad color schemes, not a lot of features (or, I didn't invest enough time) * mailx - POSIX email viewer. heirloom's version supports S/MIME, IMAP, and some other niceties. Very fast. Supports calling programs based on mime-type to produce text representations for console viewing. Doesn't require much out-of-the-box configuration, but has many config options with account and destination override-ability. (I like how it, like vim, can be run vanilla and is usable) OTOH, lacks important things like line editing, address book (closest thing is aliases), OpenPGP (GPG) support (they recommend inline clear-sign) and reasonable handling of search results. Search is also based on either support in the IMAP server or by fetching messages and doing local search at the time of the search query. This makes header searches slow and content searches very slow, though still not as bad as some other clients. Update - while heirloom-mailx seems no longer maintained, there is a (fork?) called s-nail under development. It adds command line history and some other nice features. Still doesn't support OpenPGP, though it seems they might have plans for it. * kmail - Very featureful client. Supports (or supported) OpenPGP, S/MIME, multiple identites, multiple accounts, filtering, addressbook and calendar integration (with KDEPIM, not 'generic'). One of the best features that was *almost* implemented right was its thread view options. There are times when you want to see threads and times when you don't. It allowed you to have multiple tabs open and you could have two tabs to the same mail box open with different threading on each. Unfortunately, your thread selections from the menu applied to all of kmail and just didn't update an old tab until you changed boxes, so you couldn't switch between, say, sent and INBOX on any tab without losing settings. It had both sorting and aggregation options (unlike others that group those together). My favorite set was aggregating by thread but listing each thread in the order of most recent message within the thread. Other clients seem to prefer to sort by thread leader, which results in missing something if someone replies to a month or year old thread if you don't pay attention to the unread count. (KMail made that mode impossible when one of the akonadi issues resulted in all messages being marked as unread after every sync with the server. It didn't like setting the \Seen flag for some reason.). This ordering is somewhat close to gmail. Requires a GUI and KDE. More recent versions split the viewer from the client, which is now a local server backend that integrates into a search and information caching database (akonadi backed by mysql). In theory this is good because you can get new mail notifications when your viewer is closed, and searching for stuff should be very fast. In practice, things got out of sync, search often didn't work, and the backing database could grow to enormous sizes. Somewhere along the line they also switched to DBus for communication between components, which in my experience breaks a *lot*, and when it does, you get either weird error messages or weird behavior or both. * mutt - haven't used it yet. I've heard lots of good things and some bad things. I'm mostly against its mbox format of choice.