[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with upgrade from 0.2.0.0 to 0.3.1
From: |
Dan Nelson |
Subject: |
Re: Problem with upgrade from 0.2.0.0 to 0.3.1 |
Date: |
Mon, 3 Jul 2006 21:12:03 -0500 |
User-agent: |
Mutt/1.5.11 |
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