"Junk Mail" problem. help!
st....@nospamkatamail.com
Mail" but from a little time it works badly.
Now many junk mails go into Junk buzon. I have always to drag them
maually into "In" buzon.
Can you tell me how I have to configure Eudora precisely? I need the
config. of "Junk Mail" and "Junk Mail Esxtras" pages.
Thanks a lot.
John H Meyers
> Now many junk mails go into Junk
In "Paid" mode, with this option enabled?
[x] Automatically place junk in Junk mailbox?
When you open your Junk folder,
what sort of "scores" do you find in the "Junk score" column?
What are the first ten lines of your file "UserJunkDB.txt"
that you will find in the "Plugins" folder within your "Data" folder,
the path of which is seen in "Help" | "About Eudora"?
Do you have any filters whose action is to put mail into the Junk folder?
--
st....@nospamkatamail.com
beacuse I have this problem.
>Eudora's junk filter is intelligent. You need to "train" it. You do
>not do that by dragging good mail out of the Junk Mail folder, you do
>it by highlighting the good message, right clicking, and selecting
>"Not Junk." That message will be transferred to the In box (or other
>place another filter sends it. (I like to mark such messages as
>"Unread" before doing that so they're easier to find after they're
>moved out of the Junk Mail folder.) Do that regularly and Eudora will
>learn to make better decisions with future mail.
>
>Likewise, when you receive spam and it isn't filtered to the junk
>folder, right click on it and select "Junk" and it will go to the Junk
>Mail folder and again Eudora will learn to make better decisions.
>
>I hope that helps.
st....@nospamkatamail.com
>In "Paid" mode, with this option enabled?
>[x] Automatically place junk in Junk mailbox?
Yes
>When you open your Junk folder,
>what sort of "scores" do you find in the "Junk score" column?
I see 90 "score" and always high scores.
>What are the first ten lines of your file "UserJunkDB.txt"
>that you will find in the "Plugins" folder within your "Data" folder,
>the path of which is seen in "Help" | "About Eudora"?
I attach you some lines of "UserJunkDB.txt" file
>Do you have any filters whose action is to put mail into the Junk folder?
I have not abled filters.
#
#File generated by command-line tools
#
!MessageCount = 4294957050, 11638
0 683 $
0 14 $0
0 2 $0.0006
0 2 $0.001
0 1 $0.007-
0 2 $0.009
0 6 $0.01
0 1 $0.014
0 2 $0.021
0 1 $0.023
0 1 $0.046
0 2 $0.05
0 1 $0.062
0 5 $0.07
0 3 $0.077
0 1 $0.08
0 1 $0.087
0 2 $0.1
0 1 $0.10
0 1 $0.12
0 2 $0.145
0 6 $0.15
0 3 $0.16
0 4 $0.18
0 6 $0.20
0 6 $0.21
0 5 $0.22
0 4 $0.24
0 9 $0.25
0 1 $0.27
0 2 $0.31
0 3 $0.32
John H Meyers
> I attach you some lines of "UserJunkDB.txt" file
> #
> #File generated by command-line tools
> #
> !MessageCount = 4294957050, 11638
Gremlin found! ^^^^^^^^^^^^^^
When expressed as a 32-bit integer,
that large number acts like a _negative_ value,
which causes "junk scoring psychosis" :)
More info, plus solution:
http://eudorabb.qualcomm.com/showpost.php?p=3262
http://groups.google.com/group/comp.mail.eudora.ms-windows/msg/abebb56737c4d14f
http://groups.google.com/group/comp.mail.eudora.ms-windows/msg/10168565c9fdc671
--
st....@nospamkatamail.com
get the same problem. I have written a very little number.
Perhaps have I replace it with Eudora 8? ;) ;)
Stan Bischof
> I have just changed the first number on "UserJunkDB.txt" file but I
> get the same problem. I have written a very little number.
What I do is to every now and then make a backup copy of
the junk database. That way when/if there are problems
I can revert easily.
In your case it may be best to simply move aside the
databse and re-train it from scratch. This has the advantage
of cleaning out the built-up cruft that no longer applies.
Stan
Jim Higgins
Dear st....@NOSPAMkatamail.com,
Forget the links referenced below. They provide more confusion than
simple solution.
Do this....
Near the top of your UserJunkDB.txt file is a line that contains
"!MessageCount = 4294957050, 11638" or at least that's what it was a
few days ago.
Back up your UserJunkDB.txt file and then edit the original file so
that line reads
!MessageCount = 500, 11638
That will fix the problem.
To PREVENT the problem from coming back, from now on whenever a "good"
message is found in your junk folder, DO NOT DRAG it out of the junk
folder. Instead, close that message if it is open, click once to
highlight the message summary line if it isn't already highlighted,
then right click on that line and see a menu which includes "Not Junk"
as an option. Select "Not Junk." This is the only proper way to
remove a "good" message from the junk folder. Do NOT simply drag them
out and do NOT simple delete them from the junk folder. If you want
to delete a good message that's in the junk folder, first not-junk it
as described above, then delete it after it is out of the junk folder.
This should solve your current problem and if the problem returns,
performing the "Not Junk" function properly on all the good mail you
find there should fix it. If the fix doesn't last for very long, then
edit the file again... but if you use the proper approach to
recovering good massages from the junk folder you should stay out of
trouble for a good long while.
If you are happy with the results of this advice after a week or so,
you could go back and delete the backup file you created.
Good luck.
On Sun, 08 Nov 2009 17:02:26 -0600, "John H Meyers"
<jhme...@nomail.invalid> wrote:
>On Sun, 08 Nov 2009 16:14:51 -0600:
>
>> I attach you some lines of "UserJunkDB.txt" file
>
>> #
>> #File generated by command-line tools
>> #
>> !MessageCount = 4294957050, 11638
>
>Gremlin found! ^^^^^^^^^^^^^^
>
>When expressed as a 32-bit integer,
>that large number acts like a _negative_ value,
>which causes "junk scoring psychosis" :)
That number above is getting close, but it doesn't exceed the
allowable value for a 32-bit integer.
Value above 4,294,957,050
2^32 - 1 4,294,967,295
Perhaps you mean a 32-bit SIGNED integer?
My own UserJunkDB.txt, which I've never edited directly since junk
handling first came out, reads... !MessageCount = 147, 537
for whatever reference that provides.
Yes, my ISP has effective spam filtration to begin with.
>More info, plus solution:
Hmmm, maybe for some definition of "solution," but not for mine.
>http://eudorabb.qualcomm.com/showpost.php?p=3262
Describes problem as "The problem (=bug) is that when the first number
reaches a certain high value it is rolled back to an extremely high
number."
Huh? Too much guessing what the heck that means for it to explain
much.
Also says, "The solution seems to be to cut down that first number to
something more reasonable by taking a number of the top, for example."
It's not at all clear what "taking a number of (sic) the top" means.
(And "of" in place of "off" isn't the problem.)
Sooo... "high" is OK, but "extremely high" isn't and we need to edit
it to something more "reasonable." Some vague words here, but without
a hint to what's "reasonable" there's no clear solution.
Also says, "Another solution would be to replace UserJunkDB.txt by one
from a backup when the program was still OK."
That's technically a very straightforward solution, but a recent
backup only replaces with numbers that are close to the problem
reoccurring and a very old backup effectively wipes out a lot of junk
filter training.
I think cut and paste links to past discussions sometimes do very
little to provide real help. For example...
>http://groups.google.com/group/comp.mail.eudora.ms-windows/msg/abebb56737c4d14f
Referring to !MessageCount = 4294955033, 40063 now... the above
reference says, "That line doesn't indicate that you did junk that
many messages. The second number is the one for the number of messages
junked. The first number should be the number of messages
not-junked."
After years of operating my junk filter here "that line" reads...
!MessageCount = 147, 537
OP's file reads...
!MessageCount = 4294957050, 11638
So... from this, someone with programming experience can guess we're
talking a 32-bit SIGNED integer that must be zero or greater, but no
"greater" than about (2^32)/2 . Now if we just knew what "reasonable"
meant we'd be on our way. In short, I don't see a clear solution here
for the average user.
>http://groups.google.com/group/comp.mail.eudora.ms-windows/msg/10168565c9fdc671
This one says, "The number that needs changing is the first number in
the line that looks like this: !MessageCount = 112, 1362. That number
is supposed to indicate the number of messages you've not-junked. It
gets decreased every time you junk a message, which it shouldn't be,
and eventually rolls over when it goes negative. That's what causes
the problem with high junk scores."
OK, but the OP's values in !MessageCount = 4294957050, 11638 aren't
negative... at least not to the majority unless the characteristics
of 32-bit UNSIGNED integers are understood. You (John) didn't mention
UNSIGNED integers. No solution for the average user here.
--
Please don't be a "Help Vampire"
http://slash7.com/pages/vampires
John H Meyers
OP reported:
>>> !MessageCount = 4294957050, 11638
JHM:
>> When expressed as a 32-bit integer,
>> that large number acts like a _negative_ value,
>> which causes "junk scoring psychosis" :)
Jim Higgins:
> That number above is getting close, but it doesn't exceed
> the allowable value for a 32-bit integer
> 2^32 - 1 4,294,967,295
It doesn't happen to be possible for a 32-bit counter
to "exceed the allowable value for a 32-bit integer,"
because it has only 32 bits :)
> Perhaps you mean a 32-bit SIGNED integer?
I labeled it as a 32-bit counter which would appear negative
when subtracting one from zero, but whether we label the problem
as occurring when a 32-bit signed counter "goes negative" (to -1)
or as occurring when a 32-bit unsigned counter goes from zero
to a huge positive value (to 4,294,967,295),
and then continues being decremented
by further "Junk/Not_Junk" actions,
the result in the junk scoring program
does have the observed discontinuity
whenever an action decrements a counter from zero,
and that's the cause of the problem.
Here's an experiment with version 7.1.0.9,
showing the first few non-comment lines of the file,
where I start with a never-used "UserJunkDB.txt" file,
then I perform one "Junk" action,
then I perform one "Not Junk" action (on the same message):
Original (never used)
!MessageCount = 0, 0
After one "Junk" action
!MessageCount = 0, 1
0 1 08clientconnect
0 2 2000
0 1 9.27
0 1 Access
0 1 Actual
0 1 Add
0 1 Administrators
After a "Not Junk" action on the same message:
!MessageCount = 1, 1
1 1 08clientconnect
2 2 2000
1 1 9.27
1 1 Access
1 1 Actual
1 1 Add
1 1 Administrators
As you can see, a "Junk" action
increments the right-hand counters on each line,
including both the message count and individual word count lines,
while a "Not Junk" action
increments the left-hand counters on each line,
including both the message count and individual word count lines.
The results with version 6.2.5.6 turned out exactly the same.
According to Katrina Knight, there are (or were) occasions
when the left-hand counter(s) get decremented,
not just incremented -- I don't know just when that occurs,
or whether it happened only in earlier "v6" versions
(Katrina's article of Sept 2004 pre-dates version 6.2.0),
but if it does occur, things would go wrong
at the point of decrementing from zero,
and a correction, if immediately applied,
would be to reverse that (make it either zero
or a small positive number again).
It might be instructive to see what the counts were
just prior to "going below zero,"
if a backup had recently been made.
FWIW, here are the counters from
StaticJunkDB.txt in version 7.1.0.9:
!MessageCount = 10245, 18206
StaticJunkDB.txt in version 6.2.5.6:
!MessageCount = 14311, 7012
I wonder from whose mail those were taken?
Perhaps one might profit by now and then
replacing that file with one's own "UserJunkDB.txt" file,
while it is still working well :)
--
Jim Higgins
I don't recall the word "counter" and even that is not definitive when
it comes to differentiating 32-bit integers (range 0 - 4,294,967,295)
and 32-bit SIGNED integers (range -2,147,483,648 to +2,147,483,647).
It is only with SIGNED integers that subtracting 1 from zero gives a
negative number. With unsigned integers subtracting 1 from zero
results in the largest possible 32-bit value.
Neither do I, but you could try seeing what happens when a piece of
junk is DRAGGED out of Junk to another mailbox. The OP said that's
what he had been doing and then recanted when told he shouldn't.
Perhaps a result of English not seeming to be his native language, but
otherwise an important distinction.
>or whether it happened only in earlier "v6" versions
>(Katrina's article of Sept 2004 pre-dates version 6.2.0),
>but if it does occur, things would go wrong
>at the point of decrementing from zero,
>and a correction, if immediately applied,
>would be to reverse that (make it either zero
>or a small positive number again).
This is perhaps why blindly spewing URLs to old messages relating to
pre-6.2.0 versions, when the OP is using the latest 7.1.0.9, is not
the best thing to do.
>It might be instructive to see what the counts were
>just prior to "going below zero,"
>if a backup had recently been made.
>
>FWIW, here are the counters from
>
>StaticJunkDB.txt in version 7.1.0.9:
>!MessageCount = 10245, 18206
>
>StaticJunkDB.txt in version 6.2.5.6:
>!MessageCount = 14311, 7012
>
>I wonder from whose mail those were taken?
>
>Perhaps one might profit by now and then
>replacing that file with one's own "UserJunkDB.txt" file,
>while it is still working well :)
I couldn't even guess. All I know is that I jumped on 7.1.0.9 as soon
as it came out and have used it extensively since. I get relatively
little spam so I guess that's why my "!MessageCount" numbers are
closer to zero than any example given so far. I've always handled
junking and un-junking "properly" by using the Eudora menu selections
rather than drag and drop. Eudora automatically junks what it thinks
is junk, which is any junk score over 40. I junk the rare junk that
Eudora misses and properly un-junk the good stuff it junks in error.
Incredibly few errors of either type after the first week. My numbers
are low, which one would think runs greater risk of the first one
going below zero and that hasn't happened.
My manual junk and unjunk scores are 100 and 0 respectively for
whatever that's worth. MinJunkScore is 40.
Bottom line to my part of this discussion (to including earlier
messages on the junk mail problem) being that I think very little of
this esoteric business about integers or signed integers was helpful
to the OP. He needs to edit his file to stop the problem and he needs
to handle the manual junking and manual unjunking of messages properly
to avoid recurrence. Whether additional steps are needed to prevent
recurrence is unproven at this time.
John H Meyers
> It is only with SIGNED integers that subtracting 1 from zero gives a
> negative number. With unsigned integers subtracting 1 from zero
> results in the largest possible 32-bit value.
Subtracting 1 from zero gives the _identical_ value in either case
(a 32-bit word where every bit is "1")
What I concluded last time was that, in the end,
trying to guess how the "junk scorer" _interprets_ the result
is moot -- we know that this point is where things go wrong,
and we know that if we want to correct the observed "going wrong,"
we need to change a recognizably "wrong counter" to a value
where many of the leading bits are again "0"
> you could try seeing what happens when a piece of junk
> is DRAGGED out of Junk to another mailbox.
I just tried this, and nothing happened -- neither "dragging out from"
nor "dragging into" the Junk mailbox changed any counters,
which does not support telling someone
that this is the cause of his problem,
or will prevent its recurrence in the future.
> blindly spewing URLs to old messages relating to
> pre-6.2.0 versions, when the OP is using the latest 7.1.0.9,
> is not the best thing to do.
We don't even know whether it can ever happen,
if no other version is ever used.
Those messages are also the only ones I can find
which identify that the "total counts line"
is where things go wrong, how to recognize it, and how to fix it,
so they are the only references I can credit,
to give credit where due, to those who have already
found the problem in the past, as well as who may have
recovered from it by doing what they had said.
JHM:
>> Perhaps one might profit by now and then
>> replacing that file with one's own "UserJunkDB.txt" file,
>> while it is still working well :)
> I couldn't even guess.
I will take full credit for guessing,
that if the complete logic of calculating a "junk score"
in any way blends the two files (the "StaticJunkDB.txt"
which comes installed with the programs, plus the
"UserJunkDB.txt" which changes upon user's "Junk/Not_Junk" actions),
then I think it may improve reliance on one's own training,
plus assist recovery of any corruption to one's own "UserJunkDB.txt"
to have a previous version of it saved as "StaticJunkDB.txt,"
thus "promoting the good health of two birds with one feeder" :)
> [I got] incredibly few errors of either type after the first week.
> My numbers are low, which one would think runs greater risk
> of the first one going below zero and that hasn't happened.
Does this point to possible prior use of an older Eudora version
by the OP as a suspect? "Only the OP knows for sure" :)
> Bottom line to my part of this discussion (to including earlier
> messages on the junk mail problem) being that I think very little of
> this esoteric business about integers or signed integers was helpful
> to the OP.
Then why keep harping upon it?
If we agree that when something subtracts 1 from 0,
then it goes into "bad territory, counter-wise,"
or even if we attribute the bad value to a haunting
by an evil spirit, then it's still necessary to both
recognize the symptom of a "bad counter"
and know what sort of value a "good counter" should have,
if we are to put it back into "good" state again,
although unnecessary if we prefer
to instead just junk the training file itself.
> He needs to edit his file to stop the problem
Good, so he has to know what sort of edit makes it "good" again.
> and he needs to handle the manual junking
> and manual unjunking of messages properly to avoid recurrence.
This we do not know. We have no evidence that version 7.1.0.9
(or even 6.2.3.4) subtracts from any counter at any time,
based on the very few experiments I have just done,
but we do have the past testimony
of some whom I would call expert,
saying that some past version certainly did that,
in response to _normal_ junking!
There are also other possibilities as to how it might go wrong,
internally -- for example, if a 16-bit counter,
while being _interpreted_ as signed, exceeds 32,767
and is then copied to a 32-bit counter, again being
interpreted as signed, but then is written as a decimal value
to the file, by a function which interprets it as unsigned!
We don't know what goes on, but one thing I just saw,
from an experiment, is that dragging messages to or from Junk
seemed to be of no influence at all.
> Whether additional steps are needed to prevent
> recurrence is unproven at this time.
Then why give the unproven advice above,
particularly when applying the _normal_ advice too often (that is,
applying normal "Junk/Not_Junk" actions to too many messages)
was declared by those who have researched this before
as the actual precipitator of the problem!
If I can keep my eyes from glazing over,
I'll ask Katrina whether she has any more direct knowledge about this,
and with what versions, etc. (she may also have had contact with developers,
one might suspect, from some knowledge of internals which would otherwise
seem hard to obtain).
Thank you, and good night.
--
st....@nospamkatamail.com
Two days ago I have modified UserJunkDB.txt file and I have written
"!MessageCount = 500, 11638". I now can tell you I have solved my
problem. Eudora now works very very fine.
Thanks for your suggestions.
Jim Higgins
<jhme...@nomail.invalid> wrote:
>On Wed, 11 Nov 2009 01:55:04 -0600, Jim Higgins wrote:
>
>> It is only with SIGNED integers that subtracting 1 from zero gives a
>> negative number. With unsigned integers subtracting 1 from zero
>> results in the largest possible 32-bit value.
>
>Subtracting 1 from zero gives the _identical_ value in either case
>(a 32-bit word where every bit is "1")
>
>What I concluded last time was that, in the end,
>trying to guess how the "junk scorer" _interprets_ the result
>is moot -- we know that this point is where things go wrong,
>and we know that if we want to correct the observed "going wrong,"
>we need to change a recognizably "wrong counter" to a value
>where many of the leading bits are again "0"
>
>> you could try seeing what happens when a piece of junk
>> is DRAGGED out of Junk to another mailbox.
>
>I just tried this, and nothing happened -- neither "dragging out from"
>nor "dragging into" the Junk mailbox changed any counters,
>which does not support telling someone
>that this is the cause of his problem,
>or will prevent its recurrence in the future.
On the contrary... observation that the first value getting smaller
until it passes thru zero and becoming negative is the cause of the
problem, one should properly unjunk messages so as to increment this
counter as (I assume) was intended when mail is unjunked. If you
don't, then whatever condition decrements that value is more able to
cause the problem. Obviously I'm rejecting the notion that so much
mail is unjunked or other action occurs that increments the first
value, that it increases over 2Gigs to become negative (signed 32-bit
integer assumed).
>> blindly spewing URLs to old messages relating to
>> pre-6.2.0 versions, when the OP is using the latest 7.1.0.9,
>> is not the best thing to do.
>
>We don't even know whether it can ever happen,
>if no other version is ever used.
>
>Those messages are also the only ones I can find
>which identify that the "total counts line"
>is where things go wrong, how to recognize it, and how to fix it,
>so they are the only references I can credit,
>to give credit where due, to those who have already
>found the problem in the past, as well as who may have
>recovered from it by doing what they had said.
Read those messages from top to bottom. As I recall 2 out of 3 just
rattle on and on without providing a clear solution.
>JHM:
>>> Perhaps one might profit by now and then
>>> replacing that file with one's own "UserJunkDB.txt" file,
>>> while it is still working well :)
>
>> I couldn't even guess.
>
>I will take full credit for guessing,
>that if the complete logic of calculating a "junk score"
>in any way blends the two files (the "StaticJunkDB.txt"
>which comes installed with the programs, plus the
>"UserJunkDB.txt" which changes upon user's "Junk/Not_Junk" actions),
>then I think it may improve reliance on one's own training,
>plus assist recovery of any corruption to one's own "UserJunkDB.txt"
>to have a previous version of it saved as "StaticJunkDB.txt,"
>thus "promoting the good health of two birds with one feeder" :)
>
>> [I got] incredibly few errors of either type after the first week.
>> My numbers are low, which one would think runs greater risk
>> of the first one going below zero and that hasn't happened.
>
>Does this point to possible prior use of an older Eudora version
>by the OP as a suspect? "Only the OP knows for sure" :)
A VERY GOOD POINT! This is perhaps why spewing references to old
messages, some of which predate version 6.?, is perhaps not such a
good idea without first asking. "Too much help" offered when the
problem isn't fully defined can become a "problem."
>> Bottom line to my part of this discussion (to including earlier
>> messages on the junk mail problem) being that I think very little of
>> this esoteric business about integers or signed integers was helpful
>> to the OP.
>
>Then why keep harping upon it?
Because the value of any help offered is proportional to the ability
to understand it and to see it as sensible, it makes no sense to
describe a value as a 32-bit integer and go on in references about the
vague relationship between big numbers and really big numbers being
the problem without accurately describing the integer being discussed
as 32-bit UNSIGNED... and for that matter without describing big vs
really big. There is a difference between information and usable
information.
>If we agree that when something subtracts 1 from 0,
>then it goes into "bad territory, counter-wise,"
>or even if we attribute the bad value to a haunting
>by an evil spirit, then it's still necessary to both
>recognize the symptom of a "bad counter"
>and know what sort of value a "good counter" should have,
>if we are to put it back into "good" state again,
>although unnecessary if we prefer
>to instead just junk the training file itself.
Agreed. But vague descriptions of good vs bad with big being OK, but
really big being bad, and then talking about positive vs negative
values - which don't clearly map to big vs really big doesn't seem
like it would help the average person.
>> He needs to edit his file to stop the problem
>
>Good, so he has to know what sort of edit makes it "good" again.
That's why I told him... without running him around to old messages, 2
out of 3 of which described the problem, but didn't clearly address a
solution.
>> and he needs to handle the manual junking
>> and manual unjunking of messages properly to avoid recurrence.
>This we do not know.
We do know he has the problem and we "know" he has been unjunking by
dragging. He said so.
>We have no evidence that version 7.1.0.9
>(or even 6.2.3.4) subtracts from any counter at any time,
>based on the very few experiments I have just done,
>but we do have the past testimony
>of some whom I would call expert,
>saying that some past version certainly did that,
>in response to _normal_ junking!
For the sake of discussion I'll stipulate that a past version
decremented the counter under some condition. So how is the problem
happening in ver 7.1.0.9 if it isn't still being decremented under
some condition? Do you hold the notion that it was incremented over 2
giga-times to make a 32-bit signed negative value to cause the
problem? That seems really unlikely.
>There are also other possibilities as to how it might go wrong,
>internally -- for example, if a 16-bit counter,
>while being _interpreted_ as signed, exceeds 32,767
>and is then copied to a 32-bit counter, again being
>interpreted as signed, but then is written as a decimal value
>to the file, by a function which interprets it as unsigned!
>
>We don't know what goes on, but one thing I just saw,
> from an experiment, is that dragging messages to or from Junk
>seemed to be of no influence at all.
I didn't see that. I saw proper unjunking incrementing the first
value while improper unjunking didn't. So... if we run with that
assumption that in an earlier version this value was decremented under
certain conditions, it seems that proper unjunking helps to prevent
the problem of this value falling below zero. Thus proper unjunking
is at least a factor in PREVENTING the problem.
>> Whether additional steps are needed to prevent
>> recurrence is unproven at this time.
>
>Then why give the unproven advice above,
>particularly when applying the _normal_ advice too often (that is,
>applying normal "Junk/Not_Junk" actions to too many messages)
>was declared by those who have researched this before
>as the actual precipitator of the problem!
>
>If I can keep my eyes from glazing over,
>I'll ask Katrina whether she has any more direct knowledge about this,
>and with what versions, etc. (she may also have had contact with developers,
>one might suspect, from some knowledge of internals which would otherwise
>seem hard to obtain).
Please don't do so on my account because my eyes are glazing over too
and I'm straying from the real point. My point isn't the technical
details per se. My point is that a lot of technical details don't
necessarily constitute help.
>Thank you, and good night.
Likewise.
Jim Higgins
That's good news! I'm glad to have been able to help.
Jim Higgins
<jhme...@nomail.invalid> wrote:
>On Wed, 11 Nov 2009 01:55:04 -0600, Jim Higgins wrote:
>>
>> and he needs to handle the manual junking
>> and manual unjunking of messages properly to avoid recurrence.
>
>
>This we do not know. We have no evidence that version 7.1.0.9
>(or even 6.2.3.4) subtracts from any counter at any time,
>based on the very few experiments I have just done,
>but we do have the past testimony of some whom I would
>call expert, saying that some past version certainly did that,
>in response to _normal_ junking!
I was going to leave this topic alone, but based on my own limited
testing this morning, Eudora 7.1.0.9 (registered) will decrement the
first !MessageCount counter in the UserJunkDB.txt file.
This morning I un-junked two messages with no change seen to the
UserJunkDB.txt file !MessageCount values UNTIL EUDORA WAS SHUT DOWN.
After shutdown it could be seen that the first count had been
incremented by 2, no change to the second count.
Now these same two messages were junked with no change seen to the
file until Eudora was again closed. After shutdown it could be seen
that the first count was DECREMENTED by two and the second count was
incremented by two.
It appears that Eudora only updates the UserJunkDB.txt file at
shutdown, or at least at longer intervals than my testing lasted. Any
testing that doesn't include shutting down Eudora before checking for
changes to the UserJunkDB.txt file is potentially flawed.
So, here's the case showing that Eudora does decrement the first
counter.
Also, here's the case for properly un-junking good mail rather than
dragging it out of junk as the OP initially indicated he had been
doing... because doing so increments the first counter, making it
less likely to fall below zero and become negative, which causes the
problem of all incoming mail being junked automatically.
I'm assuming/accepting that the counter is a 32-bit signed integer
when I say it becomes negative. Perhaps the problem comes about
because the first value is greater than or "huge" vs the second value.
I haven't tested either possibility and don't plan to.
I don't know if it's important, but my settings apply a junk value of
zero to a manually unjunked message and a value of 100 to a manually
junked message.
John H Meyers
> Eudora 7.1.0.9
>
> This morning I un-junked two messages with no change seen to the
> UserJunkDB.txt file !MessageCount values UNTIL EUDORA WAS SHUT DOWN.
> After shutdown it could be seen that the first count had been
> incremented by 2, no change to the second count.
>
> Now these same two messages were junked with no change seen to the
> file until Eudora was again closed. After shutdown it could be seen
> that the first count was DECREMENTED by two and the second count was
> incremented by two.
>
> It appears that Eudora only updates the UserJunkDB.txt file at
> shutdown, or at least at longer intervals than my testing lasted. Any
> testing that doesn't include shutting down Eudora before checking for
> changes to the UserJunkDB.txt file is potentially flawed.
In the cases I reported earlier, I always first closed Eudora,
before opening and inspecting the file content which I then posted,
so I got "different mileage" on this, which apparently indicates
that I didn't hit the same conditions -- perhaps the order of
operations is significant, or doing several consecutively
(I only did one operation at a time, with shutdowns in between),
or who knows?
What do you feel is responsible for your own counter
(also in 7.1.0.9) not having "gone negative" after long use?
Well, thanks for illustrating that something is up,
whatever it may be.
If this whets anyone's further curiosity, join the
"group testing team," and add anything which seems to clarify
(or muddle) the understanding of "when it does, vs. when it doesn't"
Perhaps the junk scorer would have been even more accurate,
had it acted consistently? (people have reported
getting better results with "mailwasher," for example,
which is another "probabilistic" system,
whose internal details I do not know).
--
Jim Higgins
<jhme...@nomail.invalid> wrote:
>On Thu, 12 Nov 2009 10:08:28 -0600, Jim Higgins interestingly wrote:
>
>> Eudora 7.1.0.9
>>
>> This morning I un-junked two messages with no change seen to the
>> UserJunkDB.txt file !MessageCount values UNTIL EUDORA WAS SHUT DOWN.
>> After shutdown it could be seen that the first count had been
>> incremented by 2, no change to the second count.
>>
>> Now these same two messages were junked with no change seen to the
>> file until Eudora was again closed. After shutdown it could be seen
>> that the first count was DECREMENTED by two and the second count was
>> incremented by two.
>>
>> It appears that Eudora only updates the UserJunkDB.txt file at
>> shutdown, or at least at longer intervals than my testing lasted. Any
>> testing that doesn't include shutting down Eudora before checking for
>> changes to the UserJunkDB.txt file is potentially flawed.
>
>In the cases I reported earlier, I always first closed Eudora,
>before opening and inspecting the file content which I then posted,
>so I got "different mileage" on this, which apparently indicates
>that I didn't hit the same conditions -- perhaps the order of
>operations is significant, or doing several consecutively
>(I only did one operation at a time, with shutdowns in between),
>or who knows?
I manually un-junked two messages at the same time, observed no change
to the file date in Explorer, shut down, observed a change to the file
date, opened file and observed change to counters.
Restarted Eudora, manually junked those same two messages at the same
time, observed no change to the file date... etc same as above.
>What do you feel is responsible for your own counter
>(also in 7.1.0.9) not having "gone negative" after long use?
I can't explain, but I'll ramble on a bit about my situation here.
Dell Optiplex 330 new 11/27/2007, fresh install of Eudora 7.1.0.9
(registered version with X1 message search engine).
Eudora has done an outstanding job of catching spam using only the
default criteria that come with a fresh installation of Ver 7.1.0.9 so
I have manually junked and manually unjunked relatively few messages
over the last two years. Manually unjunked is small in comparison to
manually junked and manually junked is very small in comparison to
automatically junked. Perhaps 5 - 7 spam a week on average over those
two years with Eudora handling the vast majority of it automatically.
>Well, thanks for illustrating that something is up,
>whatever it may be.
Glad to help. I usually don't dig deeper into these things because
explaining something that can't/won't be fixed/updated is low among my
priorities.
>If this whets anyone's further curiosity, join the
>"group testing team," and add anything which seems to clarify
>(or muddle) the understanding of "when it does, vs. when it doesn't"
>
>Perhaps the junk scorer would have been even more accurate,
>had it acted consistently?
I don't know that the spam scorer hasn't acted consistently since we
clearly don't know all the factors that control it... IMHO. The
difference in the results of our own recent testing illustrates this.
> (people have reported getting better results with
> "mailwasher," for example, which is another "probabilistic"
> system, whose internal details I do not know).
I'm inclined to ignore (or at least take with a grain of salt)
self-selected testimonials about anti-spam software (or pretty much
anything else). They just aren't statistically meaningful. Everyone's
own crying baby sounds fine while the one next door is a pain in the
butt.
To at least put numbers on a personal testimonial I was going to quote
spam counts, percentages, false positive and false negative results,
etc., from my Eudora statistics file, but see that if anything is
flawed in Eudora, statistics is it. Yearly stats say I get 7% spam.
That would be 15 a day and I don't get that in a week. It also says
98% effective, meaning 2% inaccurate. That would be 4 messages a day
improperly handled by the spam filter. Utterly ridiculous. I can't
begin to give a true count for the year, but I recall one in the past
couple of months, not 4 per day. I only mention this before folks
split this thread and start ranking Eudora performance vs Mailwasher
(or whatever) based on flawed Eudora statistics.