On Sep 04, 2010, at 11:40, Arno Garrels wrote: > Hello DZ-Jay, > > At least Firebird provides 5 priorities so why should we remove this > feature from ICS?
It's not standard, most clients assume there's only "low," "normal," and "urgent". In any case, setting TSmtpCli to use only three values (which is what it currently does, by the way) does not prevent other clients from using 5 values. Those clients will likely map "low" to 1 and "high" to 5. > It's likely that X-MSMail-Priority can be removed, however my OE v6 > still uses it, XP SP3. But that's OE v6. The question is, do we want ICS to impersonate OE v6, or to implement the protocol and let the client extend it as it wishes? I don't have Windows at hand right now, could you test if OE v6 handles "X-Priority" or "Priority" too? Remember, one thing is the header it sends, another is the headers it understands from incoming mail. Typically, mail client developers understand that they receive messages from many different clients. RFC #2156 defines only 3 levels for the "Priority" header: "normal," "urgent," and "non-urgent". "X-Priority" on the other hand is typically treated as a numeric value (0 through 5), where zero (or no header) means "normal" and the rest is a range between "very low" and "urgent". This was the way it was defined in the old Eudora client. Like I mentioned, it's a mess of "standards". What most programs do is to use what they think is the most common (e.g., "X-Priority") and then attempt to detect all other common possibilities. I think ICS should do the same, pick one from the most common ones and send that one only. Client applications using TPop3Cli component should then take care to expect different formats and attempt to decode them. It should not hurt to include more than one, but it may be unnecessary, and it also doesn't follow the convention of other popular clients. The RFC standard suggests "Priority," but like I said, not many clients seem to be using it. They probably support it, though. The most common one seems to be "X-Priority". I'm not an expert on this, so please do not think I'm proposing definitive solutions. These are mere personal suggestions based on my observations. Your views are welcome. > > Isn't it just the high priority itself, that scores? I did a bit more research on why SpamAssassin and why it would treat the priority headers as spam and found the following default rules: X_PRIORITY_HIGH: 2.0—Sent with 'X-Priority' set to high MISSING_MIMEOLE: 0.5—Message has X-MSMail-Priority, but no X-MimeOLE PRIORITY_NO_NAME: 0.5—Message has priority setting, but no X-Mailer It seems obvious what the problem was with the original ICS code: a very high "spam" score was given because "X-Priority" was set to "high" instead of to a numeric value, suggesting that it was a spamming tool and not one of the many real clients that use the Eudora header. Also, "X-MSMail-Priority" is expected to come with "X-MimeOLE" which identify the client as MS Outlook. And lastly, any priority header detected without an "X-Mailer" header suggests that it doesn't come from a "real" mailer. Also, keep in mind that modern clients use a single header for priority (whichever they pick), so including many may also alert other spam detectors. dZ. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be