"Junk Mail" problem. help!
in [Eudora]
|
Prev: Data folder
Next: convert selected to uppercase
From: st.luck on 9 Nov 2009 12:04 I have just changed the first number on "UserJunkDB.txt" file but I get the same problem. I have written a very little number. Perhaps have I replace it with Eudora 8? ;) ;) >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
From: Stan Bischof on 9 Nov 2009 12:52 st.luck(a)nospamkatamail.com wrote: > 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
From: Jim Higgins on 9 Nov 2009 13:03 Dear st.luck(a)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" <jhmeyers(a)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
From: John H Meyers on 10 Nov 2009 06:33 On Mon, 09 Nov 2009 12:03:46 -0600: 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 :) --
From: Jim Higgins on 11 Nov 2009 02:55
On Tue, 10 Nov 2009 05:33:08 -0600, "John H Meyers" <jhmeyers(a)nomail.invalid> wrote: >On Mon, 09 Nov 2009 12:03:46 -0600: > >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. 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. >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, 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. .. -- Please don't be a "Help Vampire" http://slash7.com/pages/vampires |