Mailman 3 November 2003 - spambayes-dev

RE: [Spambayes] Outlook Envelope Tray Icon
by Kenny Pitt Dec. 4, 2003

Dec. 4, 2003

Bob Chojnacki wrote: > Hi, > > I really like SpamBayes and the Outlook plugin. It is working much > better than other spam filters, considering I get 85-95% spam. I am > currently using version 008.1. I read your FAQ about the problems > with making the Outlook envelope tray icon go away. (I am also not > sure if this is the right email address to send this comment, so > please bear with me if it isn't.) > > Is the following link helpful? (Keep in mind that I am not a Windows > programmer): > > http://www.slipstick.com/dev/code/clearenvicon.htm Thanks for the link. I created the following code to implement this in the Outlook plugin and attached it to a menu item for testing. It was, in fact, successful in removing the new mail envelope from the taskbar. Now, the *really* tricky part is figuring out when to remove the icon. ==================== def RemoveNewMailIcon(): win32gui.EnumWindows(_removeIconCallback, None) def _removeIconCallback(hwnd, extra): # Check for Outlook window class. if win32gui.GetClassName(hwnd) == "rctrl_renwnd32": # Got the correct class, but we need to make sure window title is # empty because there may be other top-level Outlook windows. if win32gui.GetWindowText(hwnd) == "": return not _killNewMailIcon(hwnd) else: return True else: return True WUM_RESETNOTIFICATION = win32con.WM_USER + 7 def _killNewMailIcon(hwnd): nid = (hwnd, 0) if not win32gui.Shell_NotifyIcon(win32gui.NIM_DELETE, nid): return False else: win32gui.SendMessage(hwnd, WUM_RESETNOTIFICATION, 0, 0) return True ==================== -- Kenny Pitt

2 1

RE: [spambayes-dev] More CVS branch/tags questions
by Tony Meyer Dec. 1, 2003

Dec. 1, 2003

[This thread seems to have died a week ago, but since I was away, and have things to say <wink>, and it doesn't seem to be resolved, I figured I'd resurrect it. While I'm doing notes: thanks Richie, Anthony and Skip for outlining the various processes in more detail - great stuff for us cvs newbies]. [Richie] > Re-reading Tony's mail, I should have pointed out at the time that we > shouldn't commit edits to both places, but should use "cvs up [-j > moving-tag] -j release_1_0" to periodically merge the bugfix > branch onto the head. Nuts. I've been very guilty of this. Basically for every edit if I thought it fit in the 'bug fix' category, then I recommitted it on the branch. The changelog outlines (for the most part) which ones I put into the branch, and which ones were only on the head. > From looking at the logs, it seems you're right, Mark - > bugfixes have been > hitting the head instead of release_1_0. Also, some fixes have been > committed to both the head and release_1_0, which will probably make > merging release_1_0 back onto the head a pain - you always get more > conflicts when you do that. Apart from the last couple of weeks, I committed the majority of changes to the branch (a mixture of stuff from me, and copying other people's fixes from the head). With the exception of the windows specific stuff, I'm pretty sure that I branch-committed all the changes that looked to me like bug fixes. I did do it by copying and pasting, mostly (and then checking), so hopefully there won't be too many conflicts. > (I should have encouraged more discussion of > branch strategy when all this came up - we make heavy use of > CVS branches at work, and we know a bit about how best to manage them.) I should asked more questions, too, sorry. I'm very much a newcomer to cvs, and was probably pushing towards the 1.0 release most for a period, so should have ensured that I was doing it right. > How much enhancement work has gone onto the head since release_1_0 was > taken? A lot with the web interface. The changelog details it - it's the stuff in the 1.1a1 section, rather than the 1.0a7 one. [Anthony] > I'd suggest the following: > > - checkin to the trunk. If the fix is a bugfix, and suitable for the > branch, include "bugfix candidate" in the checkin message. > > - (preferably) check your bugfix into the branch as well. I suggest > having two checkouts, one on the branch, one on the trunk. > > - (otherwise) someone else notices that the "bugfix" needs to be > applied to the branch as well, and does so. This is more-or-less what I was doing, I think, except that I based the "bugfix candidate" decision on discussion in the lists the checkin message, and my own fallible head, rather than an explicit message. > Having said that, I'd say the time to branch is at the point > where we're about to cut the first beta. So we've possibly done > it too soon here. This was almost the intent here, too. The original aim was to create the branch, release 1.0a6, then in a very short time release 1.0b1; before release the code that became 1.0a6 seemed pretty stable, and the main reason for the release was to have an alpha with the new script/option names before releasing a beta. Of course, after it was released, the db-closing/interface bug surfaced, and there was a resurgence of dbrunrecovery errors, plus a few others. [Richie] > Our failure this time, if there even was a failure, was in > not advertising the strategy loudly enough. When a strategy is decided, what would be the best way to advertise it, given that people may join the development team at any point? Something in readme-devel? And speaking of deciding a strategy, what is the spambayes one? <wink>. Personally, I'm in favour of someone else deciding and giving me steps to follow :) It does seem likely that if we can resolve the db corruption bug, a beta wouldn't be far off, so it would be good to decide by then :) =Tony Meyer

4 3

Clever avoidance technique
by Greg Ward Nov. 30, 2003

Nov. 30, 2003

Here's a nifty variation on the invisible-text-in-HTML tactic: make the invisible text vaguely relevant to the recipient of the spam. I just got one this morning that's immediately, obviously spam from these headers: From: "Inconvenience O. Imprecision" <esteves(a)belice.com> To: Gward <gward(a)python.net> Subject: Gward, meet singles in your area U7n2QHvxKLmBOhTROl57D5Q7crCNQzbL Date: Sat, 29 Nov 2003 16:42:22 -0500 but if I look in the HTML body, I see this: The Defense Technical Information Center (DTIC= =ae) is the central facility for the collection and dissemination of scie= ntific and technical information for the Department of Defense (DoD)=2e M= uch of this information is made available by DTIC in the form of technica= l reports about completed research, and research summaries of ongoing res= earch=2e u62Mb6TFJNptB0duTKrhqDiJDdBNRazm which isn't terribly relevant to me... but a little farther on (after the actual spam payload, encoded of course), we see this: The Handle System allows handles to be both cr= eated and resolved in a distributed fashion (see the diagram on this page= for an overview of the Handle System architecture)=2e Both creation and = resolution can be accomplished using dedicated clients, common clients su= ch as web browsers using special extensions or plug-ins, or unextended cl= ients going through various proxies=2e In all cases, communication with t= he Handle System is carried out using the Handle System protocol which ha= s a formal specification and some specific implementations, all freely av= ailable from CNRI=2e The protocol has a corresponding client library avai= lable in C and Java=2e The C client library has been used by CNRI in the = creation of a handle-aware extension to the Netscape and Microsoft web br= owsers=2e The Java client library has been used to create an http-to-hand= [...] Interesting! This would probably count as ham for any computer geek. However, the above blurb describes software produced by my former employer, and you can probably get to it with 3 or 4 clicks from my home page. And, knowing CNRI, the first blurb is probably vaguely related -- most of their money comes from the US military-industrial-entertainment complex, after all. This feels very much like it's targeted at Bayesian filters -- eg. I suspect SpamAssassin pre-2.6 would have had a better chance at calling this one spam than Spambayes (which scored it 0.198, just barely ham for my thresholds). Full message attached in case you're curious. Greg -- Greg Ward <gward(a)python.net> http://www.gerg.ca/ Earn cash in your spare time -- blackmail your friends!

2 1

Re: [spambayes-dev] A spectacular false positive
by T. Alexander Popiel Nov. 28, 2003

Nov. 28, 2003

In message: <LNBBLJKPBEHFEDALKOLCIEGPHCAB.tim.one(a)comcast.net> "Tim Peters" <tim.one(a)comcast.net> writes: > >Especially since more & more of us are inclining toward using tiny databases >(compared to what we used to do), making space for a "last used" timestamp >may not be nearly as scary as it used to be. This is something that I don't understand... why do we care if the database is huge? With 100 gigabyte drives commonplace, why are we quibbling over 20 or 40 megabytes? - Alex

5 6

Proposal[spambayes-dev] Business opportunity
by Auto Auction Center Nov. 28, 2003

Nov. 28, 2003

About Us: Out of over 100,000 merchants, Netcom3 (Auto Center) is ranked #1 as the most successful company through Clickbank Network. Netcom3 (The Auto Center) has millions of used car buyers every month in its automotive network with one of the largest providers of e-business for the automotive industry. By 2004, millions of customers will be using our no obligation service to bid on vehicles and make offer requests to our network of over 67,200 sellers and dealers. We have been in the automotive business for over 7 years with a huge profit gain each and every year. We are now planning to expand our company by offering free advertising on our online auto site which will also appear on our network partner's sites Including: Yahoo.com, cars.com, Autotrader.com, autoweb.com and many more auto giants. Advertising with us is FREE and you can instantly generate an ongoing stream of targeted leads. All leads can be emailed to you or customers can go directly to your website to view what you have to offer. Profit Potential: By signing up with Netcom3.com, you will have access to over 63,000,000 potential auto buyers every month for FREE. Just imagine how much money you can save by signing up with Netcom3 appose to posting your on ads on our network partners sites yourself. See example below. Example: To post an ad on yahoo.com auto site it will cost you $34.95 per car. But if you sign up with Netcom3.com it will cost you nothing and your ad will appear on Netcom3 site and its network partner sites including yahoo.com for free. Example2: Place 100 ads on yahoo.com will cost you $3495.00. Place 100 ads with Netcom3 and its partner sites will cost you $0. You can post as many cars as you like for free. We are so confident in our service that we are not obligating you or any of our other affiliates to contract with us. You can back out at anytime. Give it a try and I guarantee you will be glad you did. If you are interested in receiving more qualified leads please visit our web site for more details at http://www.netcom3.com/sell.htm Thank You Netcom3 / Auto Center Marketing Department

1 0

RE: [spambayes-dev] More CVS branch/tags questions
by Tony Meyer Nov. 28, 2003

Nov. 28, 2003

[Mark] > Should we abandon the branch, merging everything > back to the trunk? I don't see the branch is offering > us any value, firstly as it is now very old, and secondly > as the trunk doesn't seem to have had any changes that > truly should be post 1.0 - unless we don't count a > Windows binary in 1.0. The sb_server interface has had quite a few changes on the trunk that haven't been put into the branch. I certainly hope that they didn't introduce new bugs (since I wrote most of it), but they may have done. I think it would certainly mean that we should do another release before we consider that things are stable. OTOH, the changes were all sugar, and they could be ripped out and added back in another day. Anyone have any idea how many people are using sb_server from cvs? Enough that the changes (they're fairly old now, even though they've never made a release) seem fairly stable? -0 from me, anyway. > I will start moving on the binary again as > soon as someone can help me resolve this. I can't help resolve it, really, but now I'm back and have caught up with things, I'm happy to help out however I can with the 'full' binary. Are you still thinking of doing one final Outlook only one? Give me a list of things to do <wink>. (Or maybe you already did; I'll have to look through the stuff I have on my to-do list). > In the meantime > it looks like resolving 355 bugs as duplicates <wink/frown> I tried to get some of those out of the way; there sure are a lot of Outlook ones there at the moment. If the new release solves the 0x000000 install problem, that'd get rid of a lot... =Tony Meyer

3 2

Re: [Spambayes-checkins] spambayes/spambayes message.py, 1.40, 1.41
by Sjoerd Mullender Nov. 26, 2003

Nov. 26, 2003

Richie Hindle wrote: > Update of /cvsroot/spambayes/spambayes/spambayes > In directory sc8-pr-cvs1:/tmp/cvs-serv19794 > > Modified Files: > message.py > Log Message: > Patch 831388: Make message.py respect the header_score_digits option. > > Bugfix candidate (probably). > > > Index: message.py > =================================================================== > RCS file: /cvsroot/spambayes/spambayes/spambayes/message.py,v > retrieving revision 1.40 > retrieving revision 1.41 > diff -C2 -d -r1.40 -r1.41 > *** message.py 8 Oct 2003 04:04:35 -0000 1.40 > --- message.py 25 Nov 2003 23:11:18 -0000 1.41 > *************** > *** 342,346 **** > > if options['Headers','include_score']: > ! disp = str(prob) > if options["Headers", "header_score_logarithm"]: > if prob<=0.005 and prob>0.0: > --- 342,346 ---- > > if options['Headers','include_score']: > ! disp = ("%."+str(options["Headers", "header_score_digits"])+"f") % prob > if options["Headers", "header_score_logarithm"]: > if prob<=0.005 and prob>0.0: > This can be done with disp = "%.*f" % (options["Headers", "header_score_digits"], prob) which looks more readable to me. -- Sjoerd Mullender <sjoerd(a)acm.org>

3 3

RE: [spambayes-dev] Three patches for better Evolution integration
by Tony Meyer Nov. 26, 2003

Nov. 26, 2003

[Sjoerd Mullender] > I was thinking, could you use the IMAP command to add a flag to a > message, such as STORE +FLAGS Classified and STORE +FLAGS > Trained. You can select messages with SEARCH KEYWORD Classified. You > wouldn't have to change the message, so you don't need to make > copies (unless of course you have to move the message to a > different folder). The problem is that not all IMAP servers allow you to store arbitary flags (at least this is how the RFC reads to me; correct me if I'm wrong). So this would mean we only support a subset of IMAP servers. Again, if someone decides that this is the way to go, I don't really care, but I likewise, I don't care enough to do it myself. =Tony Meyer

2 1

more selective Received: header mining...
by Skip Montanaro Nov. 26, 2003

Nov. 26, 2003

I made a change to the mine_received_headers stuff this evening, adding a new option, gateway_machines. The idea is that the only Received: header which is really useful is the one which crosses the boundary between your known "good" network and the wild free-for-all part of the net. Received: headers from hosts internal to your network are meaningless, since for the most part, all mail passes through them, while Received: headers from hosts external to your network probably just contain random garbage which clogs your database with meaningless tokens. On the other hand, information from the point at which your mail system receives a message can be useful. You can trust your network's mail server to at least get the IP address of the delivering host. When processing Received: headers, I use the gateway_machines option (a regular expression) to detect when I first encounter an SMTP server I trust. I have four useful email addresses: skip(a)mojam.com, skip(a)pobox.com, skip(a)python.org and montanaro(a)users.sourceforge.net, so I set gateway_machines to mojam\.com|pobox\.com|python\.org|sourceforge\.net The attached context diff implements the change. If you leave gateway_machines an empty string, mine_received_headers will have it's original meaning. If you set it to something, it will cause only the earliest Received: header which matches your regular expression to be processed. It's hard to tell how well this will work, since improvements are necessarily very small at this stage of the game. It certainly seems like it might be time-sensitive. Machines which were open relays a year ago may be closed off now, forcing spammers to use different routes to your mailbox. I'm thinking it might be more helpful with small training databases and small messages, as it adds more relevant clues for the classfier to munch on. My only testing to this point has been to see how it does on my current unsure mailbox. At the moment it contains about 50 messages, a mixture of ham and spam (though mostly spam) which all scored unsure when they landed there and which for one reason or another I have yet to delete or save somewhere else. Before enabling gateway_machines no messages scored as spam. After enabling it to the above regex and retraining from scratch (~170 hams and 250 spams), three more messages from my unsure mailbox scored as spam. Not surprisingly, the number of 'received:' records in my training database dropped substantially (from 2289 to 1254) after enabling this. Finally, note that the couple of context diffs here were pulled out of already modified versions of tokenizer.py and Options.py, so patch will probably apply them with offsets. Skip

2 1

RE: Bug in UserInterface.py
by Tim Peters Nov. 26, 2003

Nov. 26, 2003

Would someone familiar with UserInterface.py please check in the attached patch, or add it to the patch manager if you're unsure about it? Thanks!

3 2