On 14 Nov 2018, at 10:02, Eric Sharakan wrote:
Isn't the solution for TJ as simple as having a dedicated header
column for priority, separate from "flag"? So you don't "turn off"
the priority setting, you just choose not to display it.
An excellent idea.
A little thought rapidly leads to the recognition that bundling priority
with intrinsically semantics-free mutually-exclusive mutable flags makes
no sense. If anyone actually pays attention to sender-defined priority,
surely it shouldn't be masked by using flags.
-Eric
On 14 Nov 2018, at 9:52, Bill Cole wrote:
On 13 Nov 2018, at 13:38, TJ Luoma wrote:
We all know these folks… they may be friends, loved one, or even
co-workers… but there are just some people who seem unable to send
out
an email without labelling it as HIGH PRIORITY.
Of course, that almost instantly makes their messages seem _not_
high
priority, because if everything is an emergency, then nothing really
is.
I would love it if MailMate could allow me to turn off the HIGH
PRIORITY flag in emails that I receive which I deem to be not HIGH
PRIORITY.
I don't want to turn off the entire column because I do sometimes
use
regular flags to highlight messages.
I agree completely, and I hope Benny comes up with an implementation.
However, there is a quirk with this misfeature of email which
explains why changing the "Priority" isn't universally implemented:
it is not an IMAP keyword (which would be a local receiver-set
value.) Instead, it is set by the sender adding one or more
non-standard headers: X-Priority, Priority, X-Importance, Importance,
or X-MSMail-Priority. I don't know which of these MailMate
specifically honors but they all share the same problem: as headers
they are an internal part of the delivered message, which an IMAP
server must never modify.
So, unsetting the 'Priority' requires the IMAP client (MailMate) to
reconstruct the message without whichever header(s) it is honoring
and store it and then to delete the original. This means the client
has to do more housekeeping on the state of a message and it means
that other clients could catch the server in a state where both
messages exist.
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
https://lists.freron.com/listinfo/mailmate
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
https://lists.freron.com/listinfo/mailmate
_______________________________________________
mailmate mailing list
mailmate@lists.freron.com
https://lists.freron.com/listinfo/mailmate