When I was taking my spam killers from 2.64 to 3.01 I discovered a bunch of
little wrinkles that frustrated me. One was that spamc was impossible and
per-user things didn't work even when connecting spamd. So I read some
spamassassin spamc code and rewrote my spamassassin plugin. I have all
sorts of ick in mine, but the core change of:
...
$transaction->body_resetpos;
print SPAMD "SYMBOLS SPAMC/1.2" . CRLF
or $self->log(LOGERROR, "Could not print to spamd: $!");
# or CHECK or REPORT or SYMBOLS
my $user = getpwuid($>);
if (defined $self->{_args}->{user}) {
$user = $self->{_args}->{user};
}
print SPAMD "User: ", $user, CRLF, CRLF
or $self->log(LOGERROR, "Could not print to spamd: $!");
print SPAMD join CRLF, split /\n/, $transaction->header->as_string
or $self->log(LOGERROR, "Could not print to spamd: $!");
print SPAMD CRLF
or $self->log(LOGERROR, "Could not print to spamd: $!");
...
Since I've gone to this, it's been silky smooth. I should pull the current
and submit a stream of patches against it with these and other things. One
thing have a hook where I'll soft-deny if it took more than X seconds for
spamassassin to scan, another posts the score into the transaction->notes
and so forth.
peter
On 1/16/05 3:15 AM, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
...
> I'm sure the problem is with 'spamc' itself, and not the plugin,
> because I have run messages through it directly, after it got through, and
> found all three of the same responses, at various times.
>
> I'm not sure if invoking spamassassin, separately, for each
> incoming does the same thing, but doing so is not very practical due to
> resource usage.
...
