Re: APPEAL FOR URGENT ASSISTANCE
On Fri, Oct 18, 2002 at 07:08:02PM -0500, Graham Wilson wrote:
> On Fri, Oct 18, 2002 at 07:46:23PM +0200, Santiago Vila wrote:
> > On Fri, 18 Oct 2002, Antti-Juhani Kaijanaho wrote:
> >
> > > On 20021018T151937+0200, Santiago Vila wrote:
> > > > * Users know whether or not their messages reach the list. If
> > > > there is "spamicity" in a legitimate email, users may remove the
> > > > spamicity and resubmit again.
> > >
> > > This is only possible if spammish mails bounce to the sender.
> >
> > So everybody claims the lists are archived everywhere, indexed by
> > search engines, distributed by news gateways, and now a legitimate
> > user needs a bounce to be sure that his posting did not reach the
> > list? :-)
>
> archives only updated daily and crawlers dont crawl overly often, so
> you would not be able to check immediately if your message got posted.
>
> if on the other hand you got a bounce message, you would know
> imediately that yuor message was classified as spam, and probably even
> why. if we start rejecting legitimate mail by lowering the
> spammassasin required hits number, we should at least be courteous
> enough to send message to users telling them why.
agreed, mail shouldn't just vanish into a black hole.
the trouble is that, in my experience, using spamassassin on a busy
mail server results in the mail queue being clogged with undeliverable
spam bounces - undeliverable because the from addresses on spam are
either forged or point to hosts that don't accept connections on port
25. what little of it that is deliverable usually just goes to some
poor bastard who is being victimised by spammers anyway (forging reply
addresses in order to mailbomb people who complain about spam has long
been a tactic of spammers).
with enough undeliverable crap in the queue, the performance of the
server will degrade way beyond unacceptable to completely unusable.
so, in this context, discarding spam is far better than bouncing it.
rejecting during the smtp transaction with a 5xx code would be better
(actually, ideal/perfect), but spamassassin doesn't work that way.
the best compromise solution, imo, is to configure spamassassin so that
actual spam scores very highly, discard to /dev/null anything that
scores over 20, and quarantine for human review anything between 10 &
20. allow anything under 10. the goal is to refine the rules so that
almost all real spam scores over 20 and never needs to waste anyone's
time.
the quarantined mail, upon review, is either forwarded to the list
manually or used as fodder for creating extra spamassassin rules.
i perform a more complicated version of the above on my own systems. my
SA threshold is 10. anything between 10 & 15 gets stored to a folder
called spam.low, between 15 & 20 to spam.medium, and everything above to
spam.high.
i check spam.low daily. i get the occasinal false-positive in here, and
adjust my whitelist or scoring rules accordingly. mostly, though, it
captures spam - which has new domains, ip addresses, phrases, etc to add
to my spamassassin rules.
spam.medium gets checked at least once/week. same procedure here.
spam.high only gets checked when i have lots of spare time...just to
make sure that my local SA rules aren't causing any false positives. i
don't even bother extracting URLs or phrases from here - they already
score highly enough.
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: