As I've pointed out in a previous message on this topic, it's not impossible that this behaviour is a bug. It it is reported, there will be one of two responses - "Oops, it's a bug, we'll fix before release", or "No, that's a deliberate design decision, live with it".
If it is a deliberate choice on Microsoft's part, they may have made it without considering all the ramifications. Pointing out that this is causing a problem with third party software may or may not prompt them to review this, but unless it's reported as a problem, they'll never know people are concerned about this.
Sure, but at the end of the day though, Microsoft will do as Microsoft pleases, it's only our *opinion* that the client should add its own message id, and if Microsoft chooses to change the *format* of the message id, thats entirely up to them too.
My point is that these are relatively high scoring rules that *by their very nature* (checking for "known" versions of OE/Outlook) will start FP'ing whenever Microsoft bring out a new version which uses a slightly different format. For this reason the maximum scores for these kind of rules should always be reigned in to a safe maximum value rather than giving the GA a free hand with those scores. (And the GA has the facility to do this)
Otherwise the same thing will keep happening every time one of the major email programs comes out with a new version that modifies the Message ID format and/or anything else these rules check.
I think this is an issue with Outlook, btw, not Outlook Express.
> Are you sure that its not generating its own Message-ID ? Just how is that
No, which is why I wrote "apparently". Another poster has suggested that this is what is happening.
Although I'd have to try and track down our customer who was having the FP problems, I'm fairly sure they were not using a beta version of Outlook.
> being determined ? From a visual glance at my own sample message I can't > see how SA can possibly be determining whether the Message-ID is being > generated by the client or not.
There are ways to check - for example send messages from Outlook via two different SMTP servers that are known to be running different MTAs. Or use something like ethereal to sniff the conversation between Outlook and the MTA to see whether or not Outlook is sending a Message-ID with the message.
Err yeah, but I mean how can SpamAssassin be sure ? It doesn't have the luxury of doing this manual comparision test using two different mail servers...
> http://bugzilla.spamassassin.org/show_bug.cgi?id=2135 > > >> Also broken is MSGID_OE_SPAM_4ZERO which triggers on netfolders > >> updates.. > > > > Likewise, if that's in the corpora used by people contributing to the > > mass-checks it'll affect the score in 2.60. > > Perhaps, but wouldn't it be better to actually fix the problem ? These two
It would be, but as you say below, the report came too late for 2.60. It has to be the developers' choice as to how they manage the software. I'm not happy with their decision in this case either, but that's life.
Yeah, I'm not complaining about it, just pointing out that its a shame that a new version is going to come out with a fairly significant already known bug... :/
It's not necessarily too late for things to be changed - I believe that the developers can exert control over the GA process (for example, to tell the GA that certain rules are not allowed to have scores above a certain level, and it will obey those constraints).
> rules combined are enough to go over a threshold of 7 let alone the > default 5, and both rules are essentially broken. > > If the GA decides that it has to reduce the scores for those two rules > dramatically (and I have a strong suspicion it wont, due to a likely lack > of example messages in the GA corpus) then the effectiveness of the rules > will be lost in any case.
If it becomes a major problem, it's not inconceivable that the scoring might be redone between minor revisions (as happened between 2.53 and 2.54).
Yeah.
> It's unfortunate that at the time I reported it (before 2.55 came out, > from memory) that it was deemed too late to fix for 2.60...due to the > "feature freeze" at the time. (I argued it was a bug fix to existing > rules, but oh well.... :)
This is one of the problems with beta software. What happens if the developers remove this rule, and then Outlook 2003 is released with different behaviour, and goes back to Outlook 2000-style message-ids? You suddenly get significant problems with spammers forging X-Mailer headers again (a la 2.5[0123]).
We'll have to see what happens....
Well I don't think we can dictate subtle behavioural requirements to people like Microsoft, we just basically have to go with whatever they do and work the rules around them...
Regards, Simon
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
