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

Tim Peters tim.one@comcast.net
Tue Nov 5 04:10:32 2002

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||22677|
       |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

> 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.

More information about the Spambayes mailing list