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

[Rich Freeman <r-plug@thefreemanclan.net>]

On Tue, Sep 27, 2016 at 11:20 AM,  <bergman@merctech.com> wrote:
>
> The IMAP RFC defines the search capabilities.
>

Sure and they don't include a standard way to handle tags.

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

Sure, but the client and server are going to implement the standard in
a standard way.  Anything beyond that isn't going to be standardized.

So, as somebody pointed out there are MUAs that have tags.  The
problem is that they don't store their tags on the IMAP server, and
different MUAs probably don't handle them the same way even if they
did.  It just isn't part of the standard.

You don't have to worry about an email client ignoring the Reply-To
header or the Subject header because these are part of the RFCs that
every MUA implements.

Tags are not, and therefore you can't rely on them with your choice of MUAs.

Now, I definitely want the tags to be accessible remotely, so IMAP
absolutely needs to support them (either natively, or by virtue of
them being stored at a lower layer and passing through in a searchable
way).  I don't have a strong objection to MUAs directly accessing the
message store.  I just think this is orthogonal to the problem that
the RFCs don't implement tags the way they implement folders.

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

Well, that's nice, but it does me no good since I don't want to limit
myself to thick clients that cache all my mail.

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

Sure, if two people have different requirements, then they may not
agree on whether a solution is adequate.  I'm willing to accept that
my requirements are different from 95% of mutt users.

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

Correct.  I wasn't referring to the IMAP RFC concept of tags at all.

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

Sure, as long as all clients optimize them in the same way, and the
IMAP server optimizes these searches.  That is unlikely if they're not
a part of the RFC.  I suspect most IMAP servers would view a search
like this as a one-off that need not operate quickly, when in my model
it is the sole way that email ends up being retrieved.  With my model
the client would never even ask for a directory listing of an IMAP
folder, while the IMAP server probably make this the most
optimized-for use case.  And this is why standards matter.

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

And this is why I stick with Gmail.  It works just fine here.  The
problem is that it doesn't do a bunch of other things that I'd like it
to do, and probably never will.  But, I've already made a judgment
call that I put more priority on the requirements GMail satisfies than
on the requirements virtually every FOSS MUA in existence satisfies.

But, I'm used to being different...  :)

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