[PLUG] mail user agent vs message storage on server (Was: Re: Top-posting)

[bergman@merctech.com]

In the message dated: Mon, 26 Sep 2016 19:37:21 -0500,
The pithy ruminations from Rich Freeman on 
<Re: [PLUG] Top-posting> were:
=> On Mon, Sep 26, 2016 at 5:06 PM, Rich Kulawiec <rsk@gsp.org> wrote:
=> >
=> > However: I think it's critical to separate functionality here, in keeping
=> > with the "Software Tools" concept (and the foundations of Unix)
=> > that a tool should do one thing and do it well.  Mail really, really
=> > should be kept in mbox format (it's served us well, it's simple, and

Or not....the hierarchical directory tree filled with
single-text-file-per-messages format has some really
strong advantages too. When combined with other *nix tools that are
inheriently command-line and file based, it's not difficult to build
complex searching, filtering, and sorting tools.

=> > a LOT of tools exist to work with it) and search really, really should
=> > be separated from it, not integrated with it, because it would be
=> >
=> 
=> Honestly, the on-disk storage format of the mail and index data
=> doesn't really concern me because email clients shouldn't ever look at
=> that stuff.  They should be talking to the mail server and giving it
=> queries.

Interesting approach.

I use the New Mail Handler (nmh) MUA, which is an outgrowth of the
Mail Handler (mh) package that originated over 30 years ago at the Rand
Corporation. It's still in [limited] use and active development.

=> 
=> The problem is IMAP really seems inadequate to this task.  If I want a

Sure. But IMAP is a Mail Access Protocol, not an MUA.

=> list of the first 20 headers with the tag "PLUG" how do I do that with
=> IMAP?  I don't know if IMAP actually supports anything like cursors,

The IMAP protocol supports searching on strings in headers...it's up to
your MUA to enable you to submit that search to the IMAP server and to
limit the number of search results that are displayed.

=> and it doesn't have much in the way of search capability to my

The IMAP RFC defines the search capabilities.

=> knowledge.  Or at least, the FOSS servers out there don't have it.
=> 
=> The storage can be in whatever format works well.  Getting my mail out
=> in mbox format is useless if it doesn't still have the tags applied,
=> though there is no reason you couldn't export in that format if it
=> isn't the native format.  I'm not convinced that a huge sequential
=> text file with indexed byte offsets is the best solution for what
=> amounts to a key/value storage system.  But, whatever, the storage
=> isn't the problem here; the protocol is the problem as far as I can

You're defining "the problem" by assuming that the mail is stored on a
"mail server" which provides both transport (receipt) of mail and
access....so with that as a starting assumption, 'the protocol' looks like
the problem in that it appears to limit how you can access messages. I
suspect that the issue here isn't really isn't the limitations of the
IMAP protocol, but the implementation on both the IMAP server and the MUA
(IMAP client).

My model is that the mail server is an MTA only, and recevied mail
is stored on my local client...in which case I've got access to those
messages with both friendly GUI tools (claws-mail currently, sometimes
exmh) and very rich (and somewhat unfriendly) command-line tools.

So, I've defined "the problem" differently, and in my case the storage
format actually leads to a solution to those issues.

My mailers support an arbitrary number of tags (overlapping or exclusive
sets) per message, and allow me to do full-text searches, generate
statistics about message contents, etc., by using lots of text-based
tools that already exist.

=> tell.  And of course the clients also would need to support this

Yes. In my case, the "client" is doing all the support, as there is no
mail access protocol beyond open(2). :)

While I'd like to see more people use nmh, I'm not really advocating
for it in this discussion, merely using is as an example of a different
way of handling mail...it's very usable for me because of history and
because of some architecture decisions (and tradeoffs), most critically
that I do not store received messages on a mail server that is external
to my mail user agent (client).

Really, I'm trying to point out that each 'solution' being suggested is
largely a result of defining the 'problem' in with different starting
conditions.

=> protocol, and not think in terms of folders (or at least not be
=> limited to these; a UI that wastes a segment of screen to tell me that
=> I'm always in my "INBOX" folder in IMAP does me no good).

Oh, that's just a bad UI.

=> 
=> If IMAP could properly support tags I'm sure GMail's IMAP interface

I don't understand what you mean by "IMAP properly support tags".

I believe you're using the word 'tags' in a different sense that the
definition of tags in the IMAP RFC (a 'token' with a unique numerical
sequence to track the command-and-response exchange between the IMAP
server and client).

It looks like you mean 'tag' as a way to arbitrarly label messages,
which enables display (searching, sorting, selection) of messages based
on those labels.

Perhaps the IMAP RFC allows for alteration of message headers, ie:

	X-TAG: plug, reply, urgent=no, cat_pictures=no, nmh

in which case the existing specification that allows searching by text
in headers would accomplish what you want.


=> would already be using these features.  They just map tags back to
=> "folders" and make an email appear in multiple folders at the same
=> time.  That really isn't a solution if you want to use your mail
=> client as anything other than a one-off solution that isn't regularly
=> used.

That really, really looks like a mail client issue, not a protocol
imitation....but I dunno. Perhaps try a different mail client?

Mark

=> 
=> -- 
=> Rich
=> ___________________________________________________________________________
=> Philadelphia Linux Users Group         --        http://www.phillylinux.org
=> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
=> General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
=> 
-- 
Mark Bergman    Biker, Rock Climber, SCUBA Diver, Unix mechanic, IATSE #1 Stagehand
'94 Yamaha GTS1000A^1					      2015 Aprilia Caponord
bergman@panix.com 			       https://www.flickr.com/photos/rmsppu

http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=bergman%40panix.com

I want a newsgroup with a infinite S/N ratio! Now taking CFV on:
rec.motorcycles.stagehands.pet-bird-owners.pinballers.unix-supporters
15+ So Far--Want to join? Check out: http://www.panix.com/~bergman 
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug