Re: [Evolution] Message priority - a recap

Danw and I agreed that if we were to implement this, we'd probably use
the Importance: header as X- anything headerscould have anything in them
(plus they are non-standard, hence the X- prefix). We'd probably also do
whatever needed to be done in order to be compatable with Outlook I

(a few comments are below...)

On Mon, 2002-06-03 at 16:52, Lonnie Borntreger wrote:
On Mon, 2002-06-03 at 12:54, Jeffrey Stedfast wrote:
Just found another reference about [X-]Priority... seems another set of
values are:

lowest/low/normal/high/highest (as strings)

hah, gotta love it.


Anyway, my filter that colors high priority items red and low priority
blue, works perfectly for receiving mail from Outlook, Outlook Express,
Kmail, Netscape(4-7), and Mozilla.  They all use a number (some with
text, but always a number) with 3 being normal, 1 and 2 being some level
of higher priority, and 4 and 5 being lower priority.

On Mon, 2002-06-03 at 13:43, Jeffrey Stedfast wrote:
[ snipped a lot of RFC stuff ]

Damn.  I spent two hours last night looking through RFCs and didn't see
any of this.  What RFC search engine do you use?

I just use google :-)

but a quick search on google shows that many mailers set values between
1 and 5 (inclusive).

According to one site, a value of 1 means the highest priority and 5
means lowest, but another site claims just the opposite. (I would have
to say that the most logical to me would be 5 is the highest priority
and 1 is the lowest, but hey - I didn't invent the fucking thing so I
guess my opinion means squat).

Well, considering that every other tool I use (problem tracking, etc.)
has 1 as the highest priority (like "this is your number 1 priority"), I
like it with 1 being highest and 5 being lowest.  But that's me.....

I think the int and string values are probably an attempt at being
compatable with 2 of the 3 types of mailers that use this header.
Unfortunately, I would think that any mailer that parsed headers in the
way specified by rfc822 would NOT correctly handle the string value
within the comment section (comments are comments, not values).

But we all know that mailers just strstr anyway :-)
Why implement according to the RFC? that would just be broken :-)

(actually, in the case of email that is an almost entirely true
statement...oh well)

So, it seems to me that supporting [X-]Priority is out of the question,
unless we only support "normal" (aka '3' for the mailers that use
integer values). Of course, supporting only "normal" is pretty much a
waste of time given that we already support normal mail :-)

Based on my testing (see my first paragraph), I think there is a
de-facto standard used for X-Priority by other mailers, and it could be
used by Evolution.  However, I have filters that show me when something
is marked as high/low priority, and if I ever need to send something
marked as such, I can switch mailers for that email. (a pain, but

I've just been testing and sending my results in response to questions. 
Whether you add that ability to Evolution, or not, is entirely a product
feature decision on your part, since it is your product.

Lonnie Borntreger

evolution maillist  -  evolution ximian com
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]