FW: RE: RE: [Spambayes] Email client integration -- what's needed?

[Tim@mail.powweb.com]

Tim, I don't know why it's doing that.  I'm sending from 
tim@fourstonesExpressions.com... but it comes out on the list with the  
invalid address...  Lemme do some more investigation... but it's 
probably my stinkin host... forever screwing me up.

Certainly a training class would have helped me get my head around the 
training side of things.  It's not really a trivial abstraction...

Ok, I'll take a crack at the training class, then... got some ideas, 
but could use a few suggestions on some remembering stuff... All we 
can really ever count on having is a few basic headers and the message 
body.  Somehow from whatever we have, we need to create a key that 
will be used to find a saved message.  I could hash the entire 
message, or use a checksum... ideas?

11/4/2002 10:10:32 PM, Tim Peters <tim.one@comcast.net> wrote:

>Tim, all msgs to you bounce, with
>
>  Recipient address: Tim@mail.powweb.com
>  Reason: Remote SMTP server has rejected address
>  Diagnostic code: smtp;550 <Tim@mail.powweb.com>: User unknown
>  Remote system: dns;mail.powweb.com (TCP|24.153.64.230|22677|
>                 63.251.213.34|25) (mail.powweb.com ESMTP Postfix)
>
>-----Original Message-----
>From: Tim Peters [mailto:tim.one@comcast.net]
>Sent: Monday, November 04, 2002 11:02 PM
>To: Tim@mail.powweb.com
>Subject: RE: RE: RE: [Spambayes] Email client integration -- what's
>needed?
>
>
>> Ok, I'm totally with ya now.  Is anyone working on a general 
purpose
>> training class?
>
>Not seriously as such, although the Outlook client has steps in that
>direction.  I expect people think the retraining steps are too 
trivial to
>factor out, but I think that's a mistake:  while the general class 
should
>indeed end up being simple, there are subtleties that should be 
captured
>once and for all, and the very existence of a training class will 
help the
>next person figure out how to proceed with the next client.  The 
current
>Tester and TestDriver classes (esp. the former) have that flavor too:  
their
>existence has driven the creation of concrete test drivers, and 
supplied
>just enough commonality so that post-test analysis tools have been
>relatively easy to write.
>
>> If not, I can take a crack at it...  The smtpproxy is kinda broken
>> without it, because while it can train, it will need some kind of
>> remembering in order to be able to untrain...
>
>I think you're in a good position, then.  When the client allows 
tight
>integration, it seems hard to abstract things enough for easy 
reusability;
>with a nightmare client <0.7 wink>, it should be easier to picture an 
ideal.
>
>
>_______________________________________________
>Spambayes mailing list
>Spambayes@python.org
>http://mail.python.org/mailman/listinfo/spambayes
>
>
- Tim
www.fourstonesExpressions.com