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
