[Spambayes] Spambayes trashes PST file links in OuchLook

Mark Hammond mhammond at skippinet.com.au
Thu Jun 7 03:32:23 CEST 2007


This will be my last mail on this matter:

> Spambayes regeneration is a primary cause of the problem, if not the
> exclusive cause.   The effect is deterministic, and without any error
> trapping as I noted.

I do not believe it is deterministic.  I do not believe you will be able to
reproduce spambayes causing PST files to be opened, nor reproduce spambayes
breaking "links" in PST files (whatever you mean by "links" in that
context - its not a term used with PST files).  In short, I believe you are
fundamentally incorrect about everything other than what you saw, but please
do take this opportunity to prove me wrong about this and demonstrate
spambayes doing what you describe.  I understand you might not have the time
or inclination for that, but you must also understand I have no time for
your demonstrably incorrect speculation.

> The lack of error trapping for this is serious,
> even if not within the Spambayes code implented so far and
> even if it is
> only a Microsoft "feature".

See above - once you can demonstrate the problem is indeed deterministic and
caused by spambayes, I'll be happy to look at ways to prevent spambayes
doing it.  However, while I am certain spambayes did not do what you
describe, it makes no sense for spambayes to catch or trap anything.

> I made no request to audit that code myself, and am not
> inexperienced in coding and software technology.

All due respect, it is clear that your experience does not run deep.  That
is not a critisism - I am sure you are highly skilled in whatever it is you
do, but quite clearly PC technology and coding is not such a strength.  You
do yourself and us a disservice by trying to pretend it is.

> I have no doubt that Mark knows the
> code he wrote very well, but the deterministic path of this damaging
> error runs from Spambayes through OutLook and into the
> Windows registry
> without traps and is a detectable error condition.
>
> My report of this problem of no trapping for a damaging error (and any
> other such reports) should simply go on the spindle of things to
> consider someday or be cautioned in the docs if too hard for Spambayes
> to trap.  Such problems should not simply be ignored as you
> suggest.  I
> don't believe ignoring serious usage hazards is good practice.  Most
> folks do not consider untrapped bugs to be entertaining, but YMMV.

Again, the above makes no sense at all if we assume my description of how
spambayes works is correct (and it is).  I understand it can be hard to get
around some of this technology, but statements like "the deterministic path
of this damaging error runs from Spambayes through OutLook and into the
Windows registry without traps and is a detectable error condition" makes no
sense at all and tends to erode any credibility you may have started with.

> I have a remedial solution for the effect that I implemented
> on my own.
> I will be cautious in using Spambayes to prevent this or
> other unguarded
> problems from occurring again. Pity that Spambayes functions cannot be
> trusted to not damage OutLook data.

>From that mail of yours, you said:

> While Spambayes triggered the largest
> catastrophe I have ever seen

Hyperbole doesn't encourage people to help you.

> it was not the only catastrophe and I have
> had a wholly unrelated example of this same type with a single PST "main
> file" from  previous years.

You may like to reflect on this comment and the paragraphs that follow, as
they clearly indicate spambayes had no role in either the initial problem or
your final solution.  You might like to consider how many days and angst you
would have saved had you not jumped to conclusions.

Mark



More information about the SpamBayes mailing list