From: siongsoo on 6 Mar 2010 04:37
can anyone help re this:
i am using eudora ver 18.104.22.168 in paid mode.
since recently most of incoming mails are going directly in the Junk box!
How do i go about preventing that?
From: Han on 6 Mar 2010 07:29
siongsoo <user(a)compgroups.net/> wrote in
> can anyone help re this:
> i am using eudora ver 22.214.171.124 in paid mode.
> since recently most of incoming mails are going directly in the Junk box!
> How do i go about preventing that?
What are your junk settings at Tools|options|Junk mail and junk mail
I have a setting at least must be "50". And it works for me.
email address is invalid
From: John H Meyers on 6 Mar 2010 07:42
On 3/6/2010 3:37 AM:
> I am using Eudora version 126.96.36.199 in paid mode.
> Since recently most of incoming mails are going directly in the Junk box!
Display the first few lines of file "UserJunkDB.txt"
which is found in the "Plugins" subfolder of your mail "Data" folder.
To find your mail "Data" folder, click "Help" > "About Eudora"
and note the path following the word "Data" -- in version 7.1
you could simply click on that path to open the folder,
as illustrated here:
Here is an example of one person's first few lines of "UserJunkDB.txt"
#File generated by command-line tools
!MessageCount = 4294947616, 34307
If you have a similar very large number in that line, see:
The two numbers are supposed to represent the total number
of "Not Junk" vs. "Junk" actions which have been performed on messages
to "train" the junk filter, as various words in each message
are also being counted, in the subsequent lines of the same file.
At some point the counting has mistakenly been "corrected" by a
subtraction, which reached zero and then tried to subtract one more,
from a 32-bit internal binary counter,
resulting in the unsigned value 2^32-1=4294967295, after which
further subtractions have left that incorrect large count in the file,
which thereafter upsets the junk filter's junk scoring calculations.
Some people try to "fix" the current counter by just replacing
the wrong count with a guess as to a reasonable small number;
others might scrap the entire file and let a new "training" file
be automatically created in its place, or might replace the current
"user" version of the file with either a formerly backup up
"good" version of their own file, or a copy of the "system" version
(StaticJunkDB.txt) found within Eudora's program files area.
The Eudora manual says: The SpamWatch plug-in
was heavily influenced by work done by Paul Graham,
and publicized in his article "A Plan for Spam"
and additional suggestions made by Gary Robinson
in his Linux Journal article "Spam Detection" [URL no longer valid]