python script as an emergency mailbox cleaner
tim.one at comcast.net
Sun Sep 21 19:47:12 CEST 2003
> I don't think 'fewer' examples of bogus 'Undeliverable e-mail'
> messages will be 'better' because of the permutating and morphing
> nature of this worm generated message. 'Fewer' examples would result
> in ALL 'Undeliverable e-mail' message catagorized as objectionable
> because the number valid messages of this type is so small in the
> save e-mail that most users have.
Which is exactly why training on "too many" such unwanted messages will make
it very difficult for the handful of legitimate messages of that sort to
score as ham. I started the spambayes project, and did most of the research
for, and coding of, its tokenizer and classifier, but you're certainly free
to ignore my ill-informed advice <wink>.
> In addition, I'd opt for the commercial product because protecting my
> systems against infection is not what I want to spend my time doing,
> and I'm quite willing to pay for that product.
I have no objection to people buying Inboxer. It adds real value for a very
large class of users. I'll repeat what I said:
>> The classification engine in Inboxer comes from the free spambayes
>> Inboxer is a commercial product (produced by some old friends of
>> mine from Dragon Systems, but I have no other connection to it),
>> which can afford to pay people to research and add ease-of-use
>> features. The spambayes project is behind on that count, but for
>> the technically-minded should perform equally well.
Since the code doing the analysis is identical between the two, people
comfortable with Python programming may well get just as much good from the
spambayes distribution. Programmers don't need as much hand-holding as
users in Inboxer's general-population target market. Since this is the
comp.lang.python newsgroup, I expect most readers *here* fit in the
programmer class of user. I don't object to them buying Inboxer either, but
I think the information I provided will be appreciated by most people here.
> Now, if I can just find a way to charge the cost to Earthlink because
> of their failure to perform their implicit contract to provide
> reliable e-mail service.
I suspect they already thought of that trick <wink> -- a good start would be
to read your service contract with them.
More information about the Python-list