bogofilter-bugs Mailing List for bogofilter -- Fast Bayesian Spam Filter
Fast Bayesian spam filter along lines suggested by Paul Graham
Brought to you by:
m-a
Menu
▾
▴
bogofilter-bugs — for bogofilter bug reports
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(19) |
Dec
(28) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(5) |
Feb
(12) |
Mar
(5) |
Apr
(1) |
May
(10) |
Jun
(4) |
Jul
(7) |
Aug
(5) |
Sep
(4) |
Oct
(4) |
Nov
(3) |
Dec
(2) |
| 2004 |
Jan
(7) |
Feb
(4) |
Mar
|
Apr
|
May
|
Jun
(17) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
(4) |
Nov
(6) |
Dec
(2) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(1) |
| 2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2010-09-20 09:45:44
|
Bugs item #3071774, was opened at 2010-09-20 11:45 Message generated for change (Tracker Item Submitted) made by tomas_hoger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=3071774&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Tomas Hoger (tomas_hoger) Assigned to: Nobody/Anonymous (nobody) Summary: bogofilter: yyinput result may exceed max_size Initial Comment: While reviewing this old flex bug: https://sourceforge.net/tracker/?func=detail&aid=1601111&group_id=97492&atid=618177 I've noticed that bogofilter's custom yyinput method returns unexpected result for the input file attached in the flex bug, as it returns result exceeding max_size limit passed to it. It does not seem to write out of bounds of the provided buffer, though incorrect result seems to have been causing flex to write out of bounds. I've not checked whether the extra buffer resize added to flex in response to the original bug is sufficient in all cases to avoid out of bounds write. As noted in the referenced bug, issue can be reproduced with current bogofilter 1.2.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=3071774&group_id=62265 |
|
From: SourceForge.net <no...@so...> - 2010-08-24 10:11:54
|
Bugs item #3052165, was opened at 2010-08-24 12:11 Message generated for change (Tracker Item Submitted) made by adrian13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=3052165&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: adrian (adrian13) Assigned to: Nobody/Anonymous (nobody) Summary: Process /usr/bin/bogofilter was killed by signal 11 (SIGSEGV Initial Comment: As the Fedora package maintainer I got a bug report about a bogofilter crash. See https://bugzilla.redhat.com/show_bug.cgi?id=626131 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=3052165&group_id=62265 |
|
From: SourceForge.net <no...@so...> - 2010-07-03 09:02:02
|
Bugs item #3024752, was opened at 2010-07-03 09:02 Message generated for change (Tracker Item Submitted) made by davison You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=3024752&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Darren Davison (davison) Assigned to: Nobody/Anonymous (nobody) Summary: segmentation fault Initial Comment: I get a number of spam messages through that cause bogofilter 1.2.1 to seg fault. I\\\'ve created the smallest test case file I can (6 bytes) that reliably segfaults bogofilter (attached). darren@bacall ~ $ bogofilter -s < spamtest.txt Segmentation fault ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=3024752&group_id=62265 |
|
From: SourceForge.net <no...@so...> - 2009-11-21 13:10:25
|
Bugs item #2901697, was opened at 2009-11-21 12:42 Message generated for change (Tracker Item Submitted) made by brot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=2901697&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Brot (brot) Assigned to: Nobody/Anonymous (nobody) Summary: Use of XDG Base Directory Specification Initial Comment: bogofilter should follow the XDG Base Directory Specification for the configuration/data directory on Linux. You can find more information here: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html On my system I found the folder ~/.bogofilter which should not be under my home root ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=2901697&group_id=62265 |
|
From: Garen E. <sc...@tr...> - 2009-08-23 23:57:08
|
Hi David; Thanks for responding so quickly. You must have no life. :) On Sun, 23 Aug 2009, David Relson wrote: > "bogoutil -i" drops .MSG_COUNT up through v1.2.0. This problem has > been fixed in v1.2.1. The -i switch on bogoutil seems to be missing documentation in the man page. > Your pruning algorithm is "interesting". I'd be concerned about its > effect on scoring tokens. In practice it has about zero effect on scoring. Once the token counts reach zero counts for both ham/spam the token is just taking up space in the database as a "most likely" random string of characters. If the string is encountered again in a new message it gets re-added to the database and has the same effect as if the counts were incremented again. Shrug. Deleting unused or rarely used tokens frees up database space, thus reducing the overall size of the database for new messages. Because counts are decremented for both spam and ham, and only on tokens that were 6 months old or older once a month, over time rarely seen tokens will eventually age out. The procmail script I use has bogofilter auto learn only if the wordlist.db is less than 30meg in size. After that messages have to be manually retrained. This keeps the database size down to a reasonable size, yet after pruning, when the database size is dropped to 15 meg or so, it allows for new variations of spam to be "learned" again without my having to interfere with the process too much. The overall effect is that bogofilter auto learns up to about the 15th or 20th of the month, then just uses the database as is, until it's pruned again. If you are interested, I can share the script that I'm using to accomplish this. It would be easier if message counts could be decremented on tokens with bogoutil, but there isn't any option I've seen to decrement the token counts in bogoutil. Anyway, I probably would not have seen this .MSG_COUNT bug show up if I hadn't recently rebuilt the wordlist.db from scratch with the fc10 upgrade. The old wordlist.db was a few years old. Am glad it's fixed in the newer version. Garen On Sun, 23 Aug 2009, David Relson wrote: > Date: Sun, 23 Aug 2009 15:03:34 -0400 > From: David Relson <re...@os...> > To: Garen Erdoisa <sc...@tr...> > Cc: bog...@li... > Subject: Re: [bugs] Rare bug that causes bogofilter to segfault > > Hello Garen, > > "bogoutil -i" drops .MSG_COUNT up through v1.2.0. This problem has > been fixed in v1.2.1. > > Using "bogofilter -N" or "bogofilter -S" enough to set .MSG_COUNT to > zero is a misuse of the capability. It's allowed but ill advised. > > Your pruning algorithm is "interesting". I'd be concerned about its > effect on scoring tokens. > > Regards, > > David > > On Sun, 23 Aug 2009 11:23:35 -0600 (MDT) > Garen Erdoisa wrote: > >> >> Bug report: bogofilter-1.2.0-1.fc10.i386.rpm >> >> Synopsis: Bogofilter starts to segfault if the database .MSG_COUNT >> token drops to zero on either spam or ham counts. >> >> This is reproducible in current fc10 versions of BOGOFILTER and >> bogofilter-sqlite3, possibly others. I haven't looked at the source >> code yet, but I suspect it's a divide by zero situation. >> >> When retraining messages using >> >> cat message |bogofilter -Ns >> >> or >> >> cat message |bogofilter -Sn >> >> It decrements the database .MSG_COUNT token counts when messages are >> unregistered. If one of these counts reaches zero, then subsequent >> messages are processed using for example: >> >> cat message |bogofilter -Ns >> cat message |bogofilter -Ns >> cat message |bogofilter -vvvp >> >> bogofilter will begin to segfault. >> >> if >> >> cat message |bogofilter -TT >> >> is entered, the result will always be 0.000000000000 >> even if the message would otherwise score as 1.000000000000 causing >> all messages to score as ham. >> >> This bug became apparent on my system because of some other >> semi-automated scripts I use to retrain messages as either spam or >> ham. The script uses -Ns and -Sn to train the messages to exhaustion. >> In the case of -Ns the script retrains repeatedly on the same message >> until the score reaches .99 or higher, and in the case of -Sn the >> script trains until the score is less than .30. I'm using bogofilter >> in tristate mode. >> >> For most situations this scenario will probably go unnoticed unless >> people retrain messages alot using -Ns and -Sn. >> >> I've been aware of bogofilter segfaulting for about a month now, and >> have spent the last couple of days tracking down the source of this >> bug. >> >> I've verified the bug by manually manipulating the .MSG_COUNT token >> in wordlist.db, then rebuilding the database. >> >> ie: >> bogoutil -d wordlist.db >wordlistdump.txt >> then edit wordlistdump.txt to change the value of the .MSG_COUNT >> token to 0 or 1 >> >> then rebuilt the database with >> cat wordlistdump.txt |bogoutil -l wordlist.new.db >> mv wordlist.new.db wordlist.db >> >> Additional info not necessarily related to the bug: >> >> My wordlist.db file currently over 30meg in size and has been >> training for several months, so it has plenty of tokens in it. >> >> I stop auto training the database at around 30meg and prune it once a >> month via a cron job that decrements message counts by one count on >> tokens older than 6 months and again on tokens older than 1 year. If >> the counts on a given token reaches zero for both ham and spam, the >> token is not included in a database rebuild so is effectively >> deleted. This tends to delete random strings of characters that >> otherwise bloat the database and trims it down to about 15 meg in >> size. >> >> Also, I've been using earlier versions of bogofilter for several >> years now and have had no other issues. This segfault issue started >> with my recent upgrade to FC10 from FC9, when I also decided to >> upgrade to the most recent version of bogofilter. In that upgrade I >> had decided to rebuild the wordlist.db from scratch using spam and >> ham from the last 90 days. >> >> -- >> Garen Erdoisa >> sc...@tr... >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 >> 30-Day trial. Simplify your report design, integration and deployment >> - and focus on what you do best, core application coding. Discover >> what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> Bogofilter-bugs mailing list >> Bog...@li... >> https://lists.sourceforge.net/lists/listinfo/bogofilter-bugs > |
|
From: David R. <re...@os...> - 2009-08-23 23:42:04
|
On Sun, 23 Aug 2009 16:53:33 -0600 (MDT)
Garen Erdoisa wrote:
>
> Hi David;
>
> Thanks for responding so quickly. You must have no life. :)
It's all in the timing. Your message happened to be present when I was
checking email ...
> On Sun, 23 Aug 2009, David Relson wrote:
> > "bogoutil -i" drops .MSG_COUNT up through v1.2.0. This problem has
> > been fixed in v1.2.1.
>
> The -i switch on bogoutil seems to be missing documentation in the
> man page.
My mistake. I was thinking "import" when I should have been thinking
"load". The command is "bogoutil -l", not "bogoutil -i"
> > Your pruning algorithm is "interesting". I'd be concerned about its
> > effect on scoring tokens.
>
> In practice it has about zero effect on scoring. Once the token
> counts reach zero counts for both ham/spam the token is just taking
> up space in the database as a "most likely" random string of
> characters.
>
> If the string is encountered again in a new message it gets re-added
> to the database and has the same effect as if the counts were
> incremented again. Shrug.
>
> Deleting unused or rarely used tokens frees up database
> space, thus reducing the overall size of the database for
> new messages.
Token dates reflect training information, i.e. when the token's count
was last updated. Thus a token's date can be really old even though
it's used regularly to score messages.
> Because counts are decremented for both spam and ham, and only on
> tokens that were 6 months old or older once a month, over time rarely
> seen tokens will eventually age out.
>
> The procmail script I use has bogofilter auto learn only if the
> wordlist.db is less than 30meg in size. After that messages have to
> be manually retrained. This keeps the database size down to a
> reasonable size, yet after pruning, when the database size is dropped
> to 15 meg or so, it allows for new variations of spam to be "learned"
> again without my having to interfere with the process too much.
>
> The overall effect is that bogofilter auto learns up to about the
> 15th or 20th of the month, then just uses the database as is, until
> it's pruned again.
>
> If you are interested, I can share the script that I'm using to
> accomplish this. It would be easier if message counts could be
> decremented on tokens with bogoutil, but there isn't any option I've
> seen to decrement the token counts in bogoutil.
AFAICT, you're the first person to use for decrementing counts as a
means of removing tokens. Bogoutil can filter tokens based on age
("-a") and count ("-c"). A "--decrement" flag could be added. For
example
"bogoutil -a 30 ... " deletes tokens older than 30 days
"bogoutil -a 30 --decrement" decrements tokens older than 30 days
"bogoutil --decrement -c 3" decrements all counts
and deletes if cnt < 3
"bogoutil -a 30 --decrement -c 3" decrements if older than 30
and deletes if cnt < 3
Feel free to send the script. I'll take a look at it.
Alternative, subscribe to bogofilter's users mailing list, offer your
script, and see what the response is.
> Anyway, I probably would not have seen this .MSG_COUNT bug show up if
> I hadn't recently rebuilt the wordlist.db from scratch with the fc10
> upgrade. The old wordlist.db was a few years old. Am glad it's fixed
> in the newer version.
The .MSG_COUNT bug has been present since the .MSG_COUNT token was
added. I don't recall how long ago that was, but the NEWS.0 file
mentions .MSG_COUNT back in early 2004. Undoubtedly its
existence goes back even further.
Regards,
David
|
|
From: David R. <re...@os...> - 2009-08-23 19:24:03
|
Hello Garen, "bogoutil -i" drops .MSG_COUNT up through v1.2.0. This problem has been fixed in v1.2.1. Using "bogofilter -N" or "bogofilter -S" enough to set .MSG_COUNT to zero is a misuse of the capability. It's allowed but ill advised. Your pruning algorithm is "interesting". I'd be concerned about its effect on scoring tokens. Regards, David On Sun, 23 Aug 2009 11:23:35 -0600 (MDT) Garen Erdoisa wrote: > > Bug report: bogofilter-1.2.0-1.fc10.i386.rpm > > Synopsis: Bogofilter starts to segfault if the database .MSG_COUNT > token drops to zero on either spam or ham counts. > > This is reproducible in current fc10 versions of BOGOFILTER and > bogofilter-sqlite3, possibly others. I haven't looked at the source > code yet, but I suspect it's a divide by zero situation. > > When retraining messages using > > cat message |bogofilter -Ns > > or > > cat message |bogofilter -Sn > > It decrements the database .MSG_COUNT token counts when messages are > unregistered. If one of these counts reaches zero, then subsequent > messages are processed using for example: > > cat message |bogofilter -Ns > cat message |bogofilter -Ns > cat message |bogofilter -vvvp > > bogofilter will begin to segfault. > > if > > cat message |bogofilter -TT > > is entered, the result will always be 0.000000000000 > even if the message would otherwise score as 1.000000000000 causing > all messages to score as ham. > > This bug became apparent on my system because of some other > semi-automated scripts I use to retrain messages as either spam or > ham. The script uses -Ns and -Sn to train the messages to exhaustion. > In the case of -Ns the script retrains repeatedly on the same message > until the score reaches .99 or higher, and in the case of -Sn the > script trains until the score is less than .30. I'm using bogofilter > in tristate mode. > > For most situations this scenario will probably go unnoticed unless > people retrain messages alot using -Ns and -Sn. > > I've been aware of bogofilter segfaulting for about a month now, and > have spent the last couple of days tracking down the source of this > bug. > > I've verified the bug by manually manipulating the .MSG_COUNT token > in wordlist.db, then rebuilding the database. > > ie: > bogoutil -d wordlist.db >wordlistdump.txt > then edit wordlistdump.txt to change the value of the .MSG_COUNT > token to 0 or 1 > > then rebuilt the database with > cat wordlistdump.txt |bogoutil -l wordlist.new.db > mv wordlist.new.db wordlist.db > > Additional info not necessarily related to the bug: > > My wordlist.db file currently over 30meg in size and has been > training for several months, so it has plenty of tokens in it. > > I stop auto training the database at around 30meg and prune it once a > month via a cron job that decrements message counts by one count on > tokens older than 6 months and again on tokens older than 1 year. If > the counts on a given token reaches zero for both ham and spam, the > token is not included in a database rebuild so is effectively > deleted. This tends to delete random strings of characters that > otherwise bloat the database and trims it down to about 15 meg in > size. > > Also, I've been using earlier versions of bogofilter for several > years now and have had no other issues. This segfault issue started > with my recent upgrade to FC10 from FC9, when I also decided to > upgrade to the most recent version of bogofilter. In that upgrade I > had decided to rebuild the wordlist.db from scratch using spam and > ham from the last 90 days. > > -- > Garen Erdoisa > sc...@tr... > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day trial. Simplify your report design, integration and deployment > - and focus on what you do best, core application coding. Discover > what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Bogofilter-bugs mailing list > Bog...@li... > https://lists.sourceforge.net/lists/listinfo/bogofilter-bugs |
|
From: Garen E. <sc...@tr...> - 2009-08-23 17:25:24
|
Bug report: bogofilter-1.2.0-1.fc10.i386.rpm Synopsis: Bogofilter starts to segfault if the database .MSG_COUNT token drops to zero on either spam or ham counts. This is reproducible in current fc10 versions of BOGOFILTER and bogofilter-sqlite3, possibly others. I haven't looked at the source code yet, but I suspect it's a divide by zero situation. When retraining messages using cat message |bogofilter -Ns or cat message |bogofilter -Sn It decrements the database .MSG_COUNT token counts when messages are unregistered. If one of these counts reaches zero, then subsequent messages are processed using for example: cat message |bogofilter -Ns cat message |bogofilter -Ns cat message |bogofilter -vvvp bogofilter will begin to segfault. if cat message |bogofilter -TT is entered, the result will always be 0.000000000000 even if the message would otherwise score as 1.000000000000 causing all messages to score as ham. This bug became apparent on my system because of some other semi-automated scripts I use to retrain messages as either spam or ham. The script uses -Ns and -Sn to train the messages to exhaustion. In the case of -Ns the script retrains repeatedly on the same message until the score reaches .99 or higher, and in the case of -Sn the script trains until the score is less than .30. I'm using bogofilter in tristate mode. For most situations this scenario will probably go unnoticed unless people retrain messages alot using -Ns and -Sn. I've been aware of bogofilter segfaulting for about a month now, and have spent the last couple of days tracking down the source of this bug. I've verified the bug by manually manipulating the .MSG_COUNT token in wordlist.db, then rebuilding the database. ie: bogoutil -d wordlist.db >wordlistdump.txt then edit wordlistdump.txt to change the value of the .MSG_COUNT token to 0 or 1 then rebuilt the database with cat wordlistdump.txt |bogoutil -l wordlist.new.db mv wordlist.new.db wordlist.db Additional info not necessarily related to the bug: My wordlist.db file currently over 30meg in size and has been training for several months, so it has plenty of tokens in it. I stop auto training the database at around 30meg and prune it once a month via a cron job that decrements message counts by one count on tokens older than 6 months and again on tokens older than 1 year. If the counts on a given token reaches zero for both ham and spam, the token is not included in a database rebuild so is effectively deleted. This tends to delete random strings of characters that otherwise bloat the database and trims it down to about 15 meg in size. Also, I've been using earlier versions of bogofilter for several years now and have had no other issues. This segfault issue started with my recent upgrade to FC10 from FC9, when I also decided to upgrade to the most recent version of bogofilter. In that upgrade I had decided to rebuild the wordlist.db from scratch using spam and ham from the last 90 days. -- Garen Erdoisa sc...@tr... |
|
From: SourceForge.net <no...@so...> - 2009-04-14 11:34:49
|
Bugs item #2761691, was opened at 2009-04-14 12:34 Message generated for change (Tracker Item Submitted) made by hines10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=2761691&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: David Hines (hines10) Assigned to: Nobody/Anonymous (nobody) Summary: configure doesn't create Makefile Initial Comment: In a clean unpack of bogofilter-1.2.0.tar.bz2, running ./configure in the top directory fails to create a Makefile. Tested on Debian 4.0 amd64, Ubuntu 8.04.2 (Hardy) i386 and FreeBSD 7.1 amd64 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=2761691&group_id=62265 |
|
From: SourceForge.net <no...@so...> - 2009-03-13 08:12:47
|
Bugs item #2685941, was opened at 2009-03-13 11:12 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=2685941&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Trunov (thestream) Assigned to: Nobody/Anonymous (nobody) Summary: Bogofilter cannot parse msg if body is base64-encoded Initial Comment: If message text is base64-encoded (or uuencoded), bogofilter cannot parse such message. Parsed tokens will be undecoded garbage. The message have following format ==================================== More-Header-Lines Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: base64 Content-Disposition: inline More-Header-Lines BASE64-ENCODED-TEXT ==================================== The message is attached. After a quick debugging, it look like a big logic problem with lexx parser which prefetches lines in advance. When parsers detects "end of message header" event, next line of message was already fetched and buffered by lexx. Since bogofilter still was in "header" mode at the point of this fetch, line was buffered as is, without base64 decoding. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=2685941&group_id=62265 |
|
From: SourceForge.net <no...@so...> - 2008-05-23 18:06:46
|
Bugs item #1970709, was opened at 2008-05-23 19:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1970709&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Dave Saville (savida) Assigned to: Nobody/Anonymous (nobody) Summary: bogofilter 1.1.6 divide by zero Initial Comment: German spam message causes BF to crash with divide by zero. Attached is the message and a debug output from BF. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1970709&group_id=62265 |
|
From: SourceForge.net <no...@so...> - 2008-04-15 15:06:29
|
Bugs item #1943136, was opened at 2008-04-15 19:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1943136&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Trunov (thestream) Assigned to: Nobody/Anonymous (nobody) Summary: Incorrect callback to process_arg() in bogoutil.c Initial Comment: If I'm understanding everything right, there is a problem with config parser callback in bogoutil. bogoutil.c calls common config parser code - read_config_file() in configfile.c read_config_file() calls process_config_option() -> process_config_option_as_arg() -> and finally calls process_arg() But bogoutil.c does not provide own public process_arg() function with correct prototype. So linker will randomly pick one of existing versions in library - either from bogolexer.c, either from bogoconfig.c, with unpredictable side effects. I think that address of process_arg() must be passed to read_config_file() and similar functions as parameter, like it's already done with longopts_xxx. Of course, all these callback functions much have same prototype (now process_arg() in bogoutil.c have different (simplified) prototype). Also there are references to optarg in bogoutil's process_arg() which, I think, are incorrect for unified scheme. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1943136&group_id=62265 |
|
From: Nettie H. <rba...@re...> - 2007-09-08 15:45:10
|
Verpassen Sie nichts am Lebem - Sie werden fuhlen was unsere Kunden bestatigen! Preise die keine Konkurrenz kennen - Kein peinlicher Arztbesuch erforderlich - Bequem und diskret online bestellen. - Diskrete Verpackung und Zahlung - Kein langes Warten - Auslieferung innerhalb von 2-3 Tagen - Kostenlose, arztliche Telefon-Beratung - Visa verifizierter Onlineshop - keine versteckte Kosten Originalmedikamente Ciiaaaaaalis 10 Pack. 27,00 Euro Viiaaaagra 10 Pack. 21,00 Euro Nur fur kurze Zeit - vier Pillen umsonst erhalten http://rqdnoja.metalwhere.com/?997931258825 (bitte warten Sie einen Moment bis die Seite vollstandig geladen wird) |
|
From: S.S.U. <car...@gm...> - 2007-08-21 21:10:53
|
Ym9nb2ZpbHRlci1idWdzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAoKCllvdZJyZSBsb3Npbmcgb25s aW5lIGJ1c2luZXNzLiAgQW5kIGl0knMgbm90IHRoZSBzdHJlbmd0aCBvZiB5b3VyIHNpdGUgliBp dJJzIHdoZXJlIHlvdXIgc2l0ZSBzaG93cyB1cCBvbiB0aGUgc2VhcmNoIGVuZ2luZXMuICAKTGV0 IHVzIGdpdmUgeW91IGEgZnJlZSBzaXRlIHJldmlldyBhbmQgc2hvdyB5b3UgaG93IHdlIGNhbiBp bmNyZWFzZSB5b3VyIHdlYiB0cmFmZmljIGFuZCB5b3VyIGJvdHRvbSBsaW5lLiAKSXSScyBhIGZy ZWUgY29uc3VsdGF0aW9uIGJhY2tlZCBieSBhIGd1YXJhbnRlZSBhbmQgcHJvdmVuIHJlc3VsdHMu ICBFbWFpbCB1cyBub3cgYXQgY2FyYXJvYmluQGdtYWlsLmNvbSAgYW5kIHdlIHdpbGwgYmVnaW4g eW91ciByZXZpZXcuICAKTWFrZSBzdXJlIHRvIGxpc3QgYWxsIHRoZSBzaXRlKHMpIHlvdSBuZWVk IGluY3JlYXNlZCBidXNpbmVzcyBhdCBhbmQgd2hlcmUgeW91IHdhbnQgdXMgdG8gY29udGFjdCB5 b3UuCgo= |
|
From: C.R.S. <car...@gm...> - 2007-08-14 22:37:43
|
CllvdZJyZSBsb3Npbmcgb25saW5lIGJ1c2luZXNzLiAgQW5kIGl0knMgbm90IHRoZSBzdHJlbmd0 aCBvZiB5b3VyIHNpdGUgliBpdJJzIHdoZXJlIHlvdXIgc2l0ZSBzaG93cyB1cCBvbiB0aGUgc2Vh cmNoIGVuZ2luZXMuICAKTGV0IHVzIGdpdmUgeW91IGEgZnJlZSBzaXRlIHJldmlldyBhbmQgc2hv dyB5b3UgaG93IHdlIGNhbiBpbmNyZWFzZSB5b3VyIHdlYiB0cmFmZmljIGFuZCB5b3VyIGJvdHRv bSBsaW5lLiAKSXSScyBhIGZyZWUgY29uc3VsdGF0aW9uIGJhY2tlZCBieSBhIGd1YXJhbnRlZSBh bmQgcHJvdmVuIHJlc3VsdHMuICBFbWFpbCB1cyBub3cgYXQgY2FyYXJvYmluQGdtYWlsLmNvbSAg YW5kIHdlIHdpbGwgYmVnaW4geW91ciByZXZpZXcuICAKTWFrZSBzdXJlIHRvIGxpc3QgYWxsIHRo ZSBzaXRlKHMpIHlvdSBuZWVkIGluY3JlYXNlZCBidXNpbmVzcyBhdCBhbmQgd2hlcmUgeW91IHdh bnQgdXMgdG8gY29udGFjdCB5b3UuCgo= |
|
From: F.O.B. <car...@gm...> - 2007-08-09 23:10:16
|
Ym9nb2ZpbHRlci1idWdzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAoKCllvdZJyZSBsb3Npbmcgb25s aW5lIGJ1c2luZXNzLiAgQW5kIGl0knMgbm90IHRoZSBzdHJlbmd0aCBvZiB5b3VyIHNpdGUgliBp dJJzIHdoZXJlIHlvdXIgc2l0ZSBzaG93cyB1cCBvbiB0aGUgc2VhcmNoIGVuZ2luZXMuICAKTGV0 IHVzIGdpdmUgeW91IGEgZnJlZSBzaXRlIHJldmlldyBhbmQgc2hvdyB5b3UgaG93IHdlIGNhbiBp bmNyZWFzZSB5b3VyIHdlYiB0cmFmZmljIGFuZCB5b3VyIGJvdHRvbSBsaW5lLiAKSXSScyBhIGZy ZWUgY29uc3VsdGF0aW9uIGJhY2tlZCBieSBhIGd1YXJhbnRlZSBhbmQgcHJvdmVuIHJlc3VsdHMu ICBFbWFpbCB1cyBub3cgYXQgY2FyYXJvYmluQGdtYWlsLmNvbSAgYW5kIHdlIHdpbGwgYmVnaW4g eW91ciByZXZpZXcuICAKTWFrZSBzdXJlIHRvIGxpc3QgYWxsIHRoZSBzaXRlKHMpIHlvdSBuZWVk IGluY3JlYXNlZCBidXNpbmVzcyBhdCBhbmQgd2hlcmUgeW91IHdhbnQgdXMgdG8gY29udGFjdCB5 b3UuCgo= |
|
From: Hannah S. <he...@ca...> - 2007-07-10 20:14:39
|
Sie leben nur einmal - warum dann nicht was neues ausprobieren? Preise die keine Konkurrenz kennen - keine versteckte Kosten - Bequem und diskret online bestellen. - Kostenlose, arztliche Telefon-Beratung - Kein langes Warten - Auslieferung innerhalb von 2-3 Tagen - Diskrete Verpackung und Zahlung - Kein peinlicher Arztbesuch erforderlicht - Visa verifizierter Onlineshop Klicken Sie HIER und Sie erhalten vier Dosen umsonst http://lbuov.firemajor.hk/?089786897989 |
|
From: Deanne L. <hea...@ar...> - 2007-07-10 10:45:25
|
Versuchen Sie unser Produkt und Sie werden fuhlen was unsere Kunden bestati= gen Preise die keine Konkurrenz kennen - Diskrete Verpackung und Zahlung - Kein langes Warten - Auslieferung innerhalb von 2-3 Tagen - Kein peinlicher Arztbesuch erforderlicht - Kostenlose, arztliche Telefon-Beratung - Bequem und diskret online bestellen. - Visa verifizierter Onlineshop - keine versteckte Kosten Jetzt bestellen - und vier Pillen umsonst erhalten http://fzjuem.continuemany.hk/?808831528898 |
|
From: SourceForge.net <no...@so...> - 2007-02-23 21:38:31
|
Bugs item #1667467, was opened at 2007-02-23 13:38 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1667467&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Scott Roy Atwood (satwood) Assigned to: Nobody/Anonymous (nobody) Summary: X-Bogosity header Interferes with DomainKeys and DKIM Initial Comment: The X-Bogosity header is written at the end of the message headers in the write_message method of passthrough.c. DomainKeys and DKIM are anti-spoofing technologies that add a cyptographic signaure of a hash of the the entire email message after the DomainKey-Signature or DKIM-Signature line, including email headers. If any headers are added after after one of these lines, it will spoil the signature and invalidate the spoof protection of these technologies. Bogofilter should be modified to inject the X-Bogosity header before any DomainKeys-Signature or DKIM-Signature line that exists in the message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1667467&group_id=62265 |
|
From: SourceForge.net <no...@so...> - 2007-02-06 15:11:15
|
Bugs item #1653369, was opened at 2007-02-06 16:11 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1653369&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Markus Elfring (elfring) Assigned to: Nobody/Anonymous (nobody) Summary: Check return codes everywhere Initial Comment: Some checks for return codes are missing. Examples: Would you like to add more error handling for return values from "fprintf" in the functions like "open_wordlist" and "configure_wordlist"? http://bogofilter.cvs.sourceforge.net/bogofilter/bogofilter/src/wordlists.c?revision=1.119&view=markup ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1653369&group_id=62265 |
|
From: SourceForge.net <no...@so...> - 2006-12-08 16:58:10
|
Bugs item #1611646, was opened at 2006-12-08 16:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1611646&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: sfuser3175 (sfuser3175) Assigned to: Nobody/Anonymous (nobody) Summary: Resource Limit Check Failure Initial Comment: The unsigned compare bug in check_fsize_limit is back. Specifically in bogofilter 1.1.3 the comparison against RLIM_INFINITY on line 475 of datastore_db.c if (rl.rlim_cur != (rlim_t)RLIM_INFINITY) { I've used ulimit to set max file size to unlimited, But I still get bogofilter complaining about db size approaching maximum file size, and eventually refusing to process. On my system (SuSE 9.1 with Linux 2.6.13.5 kernel) RLIM_INFINITY is -1 rl.rlim_cur is -1 rl.rlim_max is -1 BUT (ultimately) rlim_t is unsigned long int ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1611646&group_id=62265 |
|
From: SourceForge.net <no...@so...> - 2006-11-14 11:21:42
|
Bugs item #1596237, was opened at 2006-11-14 12:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1596237&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Michael Gerdau (mgdde) Assigned to: Nobody/Anonymous (nobody) Summary: bogofilter crashes upon processing dir with spam mails Initial Comment: Hi ! I can reliably crash the current stable release (1.1.1) as downloaded today from the sf projectpage. Here is how I can reproduce it: The attached tarball contains a dir named spamtest holding 26 msgs. I have it untarred in my home dir and then issue bogofilter -vvv -s -B ~/spamtest which gives Speicherzugriffsfehler (presumably segmentation fault or something similar) The msgs 1163324890.6552.8OJNc:2,S 1163325287.6552.wRGQC:2,S 1163325288.6552.H1bHp:2,S seem to be the culprit -- any of these added to my complete spamfolder (some 4000 msgs) makes bogofilter crash. The attached dir is the smallest testcase I had found, i.e. removing more msgs usually results in bogofilter working as advertised. I'm on SuSE 10.1, i686 mgd@Hamiller:~/ftp/mail/bogofilter> bogofilter -V bogofilter version 1.1.1 Database: Sleepycat Software: Berkeley DB 4.3.29: (April 23, 2006) AUTO-XA Copyright (C) 2002-2003 Eric S. Raymond, Adrian Otto, Gyepi Sam. Copyright (C) 2002-2006 David Relson, Matthias Andree, Greg Louis bogofilter comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under the General Public License. See the COPYING file with the source distribution for details. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1596237&group_id=62265 |
|
From: David R. <re...@os...> - 2006-11-08 00:47:33
|
On Tue, 07 Nov 2006 22:10:20 +0900 Masaru Nomiya wrote: > Hello, > > I'm usiong bogofilter 1.0.1 now. > > I've downloaded bogofilter 1.1.1, and could build without any > problems. BUt, Bogofilter doesn't work at all. > > That is, > > # bogofilter -vI 1 > *** glibc detected *** double free or corruption (out): > 0x00002aaaaadbe5b0 *** aborted. > > What the matter. I wonder? > > My System; > > 1. SuSE Linux 10.0 (2.6.13-15.12-smp) > 2. glibc 2.3.4 > 3. BerkleyDB 4.3 > > Any hints? > > Thanks in advance, There have been several several reports of bogofilter's having problems on 64 bit processors. Try downloading patch.1107_lexer_v3_l.txt from SourceForge and rebuilding bogofilter. If that doesn't correct the problem, gzip and email the problem email to me (re...@us...). Regards, David |
|
From: Masaru N. <m.n...@gm...> - 2006-11-07 13:10:31
|
Hello, I'm usiong bogofilter 1.0.1 now. I've downloaded bogofilter 1.1.1, and could build without any problems. BUt, Bogofilter doesn't work at all. That is, # bogofilter -vI 1 *** glibc detected *** double free or corruption (out): 0x00002aaaaadbe5b0 *** aborted. What the matter. I wonder? My System; 1. SuSE Linux 10.0 (2.6.13-15.12-smp) 2. glibc 2.3.4 3. BerkleyDB 4.3 Any hints? Thanks in advance, --- Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp "Bill! You married with Computers. Not with Me!" "No..., with money." |
|
From: SourceForge.net <no...@so...> - 2006-11-06 04:21:35
|
Bugs item #1591118, was opened at 2006-11-06 13:21 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1591118&group_id=62265 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rooyama (ooyama02n) Assigned to: Nobody/Anonymous (nobody) Summary: token.c Segmentation Fault Initial Comment: Bogofilter 1.1.1 died(Segmentation fault)by scanning this file. I researched and found it bug. src/token.c line 355 was wrong. -if (text[leng-1] == '>') { +if (leng > 0 && text[leng-1] == '>') { ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=499997&aid=1591118&group_id=62265 |
2 messages has been excluded from this view by a project administrator.