Re: Upgrading from 0.2.0 to CVS brings a recursing surprise

[Joe Maimon]

Dan Nelson wrote:

> 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).
>
>  
sendmail 8.12+ default MoOperation is to have the "submit" sendmail 
submit the email to the local/central daemon for delivery, or in the 
event the local/central daemon is down to queue it up into the 
submit-queue a.k.a the client-mqueue for more attempts later.

This allows the sendmail that just miltered it another crack at the 
resulting email.

It does not appear to be infinite, based on what has hit the spambucket 
and the postmaster from the double-bounces....but its a fairly large 
explosion.

detecting the -b|-B address sounds like it has promise..I will try that.

> > 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 have been experimenting with an -a switch (for what to do with a -r 
switch _and_ a -B switch)

snippet from my patch

cout << "   -a -1|num|0: bucket all spam, bucket spam scoring higher 
than num" << endl;
     cout << "                or bucket all spam that does not get 
rejected." << endl;

with 0 being the default in my patch..

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