On Thu, 31 Jan 2002, Nels Lindquist wrote:
> On 31 Jan 2002 at 1:39, Charlie Watts wrote:
>
> > Messages are already tagged with numbers indicating spammishness. Is
> > adding "Maybe" and "Probably" just helpful because it makes filtering
> > easier? It really isn't adding any information.
> >
> > I find that a decent bit of my spam is in the 5-10 range anyway. Which is
> > indeed where all of my false positives are, too.
> >
> > Checking three folders for false positives wouldn't be any faster than
> > checking one is now ...
> >
> > From my point of view (I know others use SA differently) SA should just be
> > a filter. Pass messages through it for labeling. It shouldn't be
> > auto-reporting things or doing delivery. There are already tools to do
> > those things.
>
> SpamAssassin/MTA integration methods which allow the spam status of a
> message to be determined during the SMTP conversation provide the
> opportunity to bounce the mail before it's accepted from the
> originating server.

A useful thing to do. I reject tons of mail during the SMTP session.

Having ways to integrate SA and an MTA is great.

> Where would you set a benchmark for rejection, or would you even
> consider that?  Many people are already rejecting mail through the
> use of blackhole lists.  IMO, SpamAssassin is more accurate than such
> systems; many of the open relay based lists especially are prone to
> rejecting *some* legitimate mail.  I've been considering setting up
> my server to mark spam if it's above the usual threshold, but reject
> it outright if it's above some higher threshold.

You can set the benchmark for rejection wherever you are comfortable. But
you need an MTA that has Perl hooks to be able to integrate SA into the
SMTP session.

Or milter, I suppose. And I think there already is a milter w/ SA support.

But this shouldn't be a "core" SA feature. If somebody contributes an SA
wrapper module to integrate it into the SMTP portion of an MTA, that's
where rejection should be implemented.

I'm just a fan of the Unix process model - lots of tiny components, all
chained together. The alternative is to just turn SA into a complete
MTA...

I suppose I should just think of the "spamassassin" command-line program
as another application that uses the SA Perl components. There, I'm
happier already. :-)

-- 
Charlie Watts
[EMAIL PROTECTED]
Frontier Internet, Inc.
http://www.frontier.net/


_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk

Reply via email to