a mailx clone
Switch branches/tags
Nothing to show
Clone or download
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

  * 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
  * 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.

    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
            * 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

    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.