[MlMt] Feature request: "Reset/Delete 'High Priority' Flag"

[Bill Cole]

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 at lists.freron.com
>> https://lists.freron.com/listinfo/mailmate
> _______________________________________________
> mailmate mailing list
> mailmate at lists.freron.com
> https://lists.freron.com/listinfo/mailmate