Paul Vixie <> wrote:
    >> On Mon, 12 Feb 2018 10:33:51 -0800 Paul Vixie<> wrote:
    >>> if we wanted the effort of an actual rewrite, we would need to
    >>> justify the time expenditure with a potentially larger user
    >>> population, which means reconsideration of features that younger
    >>> people actually depend on, like imap and mime. i'd be up for that.
    >> What specific mime related features do you have in mind?

    > i'd like to provide the MH view via FUSE rather than
    > files-on-disk. rather than using command line utilities to extract a
    > mime part, i want to access it by ~/Mail/inbox/135/part1.exe or
    > whatever.

So what you mean is that you want an MH-like file arrangement consistently
provided over many transports via FUSE.  I'm with you on this.

On top of that, I'd like a personal IMAP server, *solely* so that my local copy
of Thunderbird (or maybe my smartphone IMAP client) can see my archives, and
decode HTML emails and iCS attachments intelligently.  Because otherwise I
mostly live in Emacs/MH-E with HTML interpretation turned off...

    > what seems to have been lost on the other historians here is that mark
    > ignored MH when he made imap, and that bernstein ignored MH when he
    > made Maildir -- and both are _better_ than MH for all modern
    > purposes. MH is now an eddy pool of the e-mail river.

We've talked a lot about the subtle change to move MH to Maildir, and we
never quite work out all the wrinkles, and I'd sure like to that.

I don't know if rewriting MH in go or rust would be better.
I am half-way through each book (one in each bathroom...).
Either way, I think it needs to be incremental... to maybe wrapping the
(C) library and writing new daemons on top of it would make the most sense.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]        |   ruby on rails    [

Attachment: signature.asc
Description: PGP signature


Reply via email to