Re: Problem with upgrade from 0.2.0.0 to 0.3.1

[Dan Nelson]

In the last episode (Jul 03), Eli Barzilay said:
> (Please CC me with replies, I'm not on this list.)
> 
> On Jun 27, Steven W. Orr wrote:
> > Dan I did some noodling last night but I'm really not good with
> > C++. (I'm ok with C.) I'm pretty sure that the milter is not
> > sending a reject back to sendmail.
> 
> I saw the same problem with an upgraded spamass-milter too.  When I
> saw the above message I had a look at the code.  I saw this:
> 
>   /* Summarily reject the message if SA tagged it, or if we have a minimum
>      score, reject if it exceeds that score. */
>   if (flag_reject)
>   {
>       bool do_reject = false;
>       if (reject_score == -1 && !assassin->spam_flag().empty())
>               do_reject = true;
>       if (reject_score != -1) { ... }
>       if (do_reject)
>       {
>               debug(D_MISC, "Rejecting");
>               smfi_setreply(ctx, "550", "5.7.1", "Blocked by SpamAssassin");
> 
>               if (flag_bucket)
>               {
>                       /* If we also want a copy of the spam, shell out to 
> sendmail and
>                          send another copy.  The milter API will not let you 
> send the
>                          message AND return a failure code to the sender, so 
> this is
>                          the only way to do it. */
>                       ... use sendmail to send a copy of the rejected mail ...
>               }
>               return SMFIS_REJECT;
>       }
>   }
> 
> 
> So it looks like the code is *intentionally* sending a copy of the
> rejected email before rejecting it, and even explains how it is
> difficult to do so!  I disabled that bit of code (the innermost block
> above), compiled and replaced my installed binary, and it now does
> what I expected it to do -- messages that are labeled as spam are
> caught in the spam bucket mailbox, and messages that are spammier than
> the -r flag are rejected and not kept anywhere.

That block of code would only fire if flag_bucket is set, though, which
means you have a -b or -B option on your commandline, which implies
that you actually wanted the described behaviour :)  Note that the
inside block sends the message to the argument of the -b/-B option, not
the original recipient, so I don't think it could be causing what
you're seeing.

-- 
        Dan Nelson
        address@hidden