spamass-milt-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Upgrading from 0.2.0 to CVS brings a recursing surprise


From: Dan Nelson
Subject: Re: Upgrading from 0.2.0 to CVS brings a recursing surprise
Date: Wed, 22 Sep 2004 13:21:23 -0500
User-agent: Mutt/1.5.6i

In the last episode (Sep 22), Joe Maimon said:
> Dan Nelson wrote:
> >In the last episode (Sep 22), Joe Maimon said:
> > > -B in CVS happens also when message is rejected
> > >
> > > Also again when the spambucket address rejects the rejected
> > > copy....recurse.
> >
> > If your BCC address somehow causes another SMTP session back into
> > the machine, then yes this might happen.
>
> How is this? Spam that is rejected with the -r flag also gets the
> -b|-B flag applied to them in CVS. This is direct change from 0.2.0
>
> When this combination happens, spamass-milter does the spambucketing
> by spawning a sendmail and emailing the new message again -- through
> the very system that just rejected it.

But it doesn't inject via SMTP; it execs sendmail directly, which means
that the milter shouldn't get called (since milters only process SMTP
traffic).
 
> Thus virtually guaranteeing a loop unless the -b|-B address or local
> mailling are protected from SA.
> 
> I submit that this SHOULD NOT be default behavior.
> 
> The old behavior was that -b|-B only happened if -r did not. It did
> not spawn a sendmail for the bucketing. Again sub-optimal to not have
> some choice here.....

I'm open to suggestions here; my best idea is add the ability to
specify a range of scores that each flag applies to.  So something
like:

-B ">0<5 address@hidden"
-b ">=5<20 address@hidden"
-r ">=20<50 Almost certainly spam. Go away plzkthx"

which will cause a bcc to one address at low scores, a full redirect to
another at medium scores, and a bounce with a custom message at really
high scores.

> > I recommend adding all internal SMTP servers to the -i list, so
> > internally-routed mail isn't checked.  Also speeds up routing,
> > because a message is only checked once as it enters the system.
>
> Perhaps a -l that automatically did not scan email detected as local?

That was suggested at one point, but "-i 127.0.0.1" does the same
thing, and leaves -l open for something else.

-- 
        Dan Nelson
        address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]