...
> My concept would be to authenticate the user (by either IP range,
> or Exact Text as his actual return address text that appears in the mail
> program), and have the ability to auto-capture outbound addresses that the
> users sends to, and automatically add them to the AUTO-PASS list. Also,
> make the AUTO-PASS list work on a user by user basis, or global (all
users),
> to allow individuals to decide to accept-reject messages, which my current
> method would only allow/deny on a global basis.
Certainly possible, but fairly complicated.
Moverover, you still need content filtering, to catch the cases that slip
through. (Every technique fails some of the time.) At least use an SURBL to
stop messages pointing at known junk domains (i.e., use TF Pro :-).
> Also, I personally love the AVP program's Trash (tab) viewer to see
> all quarantined trash messages in a list style viewer and approve, relay
or
> reject messages many-at-a-time.
TF Pro's viewer uses a somewhat different approach: you can tell the TF
viewer to delete all similar messages (those that contain the same link, for
instance). That happens automatically when you mark a domain for deletion,
which makes it even easier.
That are a few cases where another approach would be helpful (mainly when
blocking on text strings, which I don't do very often; I've got improving
that on my todo list).
> But we need a more powerful method of extracting (inbound) approved
addresses
> (with single buttons), add them to either the Exception list (auto-pass),
My presumption has been that that's a pretty rare need. There is also the
issue of where to put such a thing; the UI is cluttered enough as it is. I
suppose one could try to put some tabs on the analyze dialog. Or
something...
> or reject them and add them to either
> the spam-from address, or spam-IP range (of SMTPrcv), for the overall
> process to become efficient.
Since TF is only handling content filtering, and my experience (which seems
to be different from yours) is that it is rare that spam comes from the same
IP for any length of time, TF doesn't do anything like this. It would be
easy enough to have the mail IP filter tie into SMTPrcv. (I didn't do that
because I can't use block-at-the-door, and because I'm only blocking a
handful of mail server IPs anyway).
> Does this ideology of mail handling sound like it may work for
> others here ?
Can't answer that. It wouldn't work very well for me (at least not without
the IPs expiring fairly quickly), since I manage several mailing lists,
including some for public comments on the Ada programming language. Not to
mention sales for RRS. I don't want to block any incoming mail unless it's
junk, and I can't know ahead of time who is going to mail me.
> How difficult a task would writing these kind of plug-ins be ?
Depends on how fancy. The TF Pro Viewer and Filter took something over 8
weeks (full-time) to construct, starting with the TF Classic Filter. That's
a pretty hefty time investment.
Adding stuff to TF is fairly easy, though, because most of the hard parts
are already done. All you have to do is convince me its a good idea. :-)
Randy.
This is the discussion list for the IMS Free email server software.
To unsubscribe send mailto:[EMAIL PROTECTED]
Delivered by Rockliffe MailSite
http://www.rockliffe.com/mailsite
Rock Solid Software (tm)
