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 guess.
(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. > > Weird. > > 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 > doable) > > 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. > > > -- > TTFN, > Lonnie Borntreger > > > _______________________________________________ > evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution -- Jeffrey Stedfast Evolution Hacker - Ximian, Inc. [EMAIL PROTECTED] - www.ximian.com _______________________________________________ evolution maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution
