On Fri, Feb 13, 2004 at 05:24:37PM -0800, Bart Schaefer wrote:
On Sat, 14 Feb 2004, Dallman Ross wrote:
As far as I've been able to determine the ONLY way to discover that
spamc failed to connect to spamd is to allow it to (attempt to)
rewrite the message header, and then look at the header to see whether
the X-Spam- lines have been added (if they weren't, no spamd).
I don't think I agree entirely. First of all, I don't ever allow spamc
to touch my headers. I don't want it writing to them; and I don't want
them changed by it. (For example, spamc *changes* tabs to spaces and
changes the whitespace quantum and wrapping in headers. I don't like
that at all.) So I use the -c option and merely collect the score in a
variable. Recipes below that decide what to do with the score.
Here's what the recipe capture is supposed to look like:
SA_OUT = 9.9/5.0
The spamc man pages say that failures will be visible by "0/0" showing
up there.
However, you have diagnosed something very important that I'd missed for
the last full year. I'm quite surprised, and -- well, let's just say
I'm flabbergasted. Hmm, let's take a look:
we were just saying that
:0 W
CS_OUT=| clamscan --options -
is not working, and you said it's because it finds a virus with
a positive exit status, which it indeed does; but you say the
status causes the output to be thrown out. And maybe you're
right. But then, why doesn't this --
:0 W
SA_OUT=| spamc
cause the results to be thrown out?
My point was that I strongly suspect the latter DOES cause the
results to be thrown out. Unless I missed something (overtrimmed
when excerpting), your recipes never look at the results in any case
I didn't believe this, so I just tested it. You know what? You are
absolutely right! Sheesh. I've been operating for the last year under
the assumption that that recipe set operated just peachy. I've even
built new recipes modeled on the concept. But it turns out it doesn't
work right at all! No variable capture takes place for found spam. It
only works when it finds (what it determines to be) non-spam, i.e., when
we're below my spam threshold for spamc.
The reason the failure was transparent to me all this time is as you
also implied: everything thrown out -- which is almost always spam, in
this case (it's either spam or a[nother] spamc "error") -- gets tagged
by my next recipe as SpamAssassin-identified spam. Like I said, yeesh!
I have to rewrite the whole thing. Thanks, Bart, for pulling the wool
from my eyes! Okay, w/W does not function at all under the premises I
had presumed it did for error-status results.
ObAddendum, a year or so ago I had tried this type of syntax:
:0
* HB ?? ! ? spamassassin -options
And that works fine as far as procmail goes. There was a very
odd, hard-to-discern bug in SA back then, though, that caused
a buffer overrun when some messages were fed to it via the pipe that
way. The bug baffled us who were discussing it locally for a
couple of weeks until Mike Peeler looked at the source code and
figured it out. So we couldn't use that syntax with that version
of SA. (I think the current version is different enough for this
problem to have vanished.) But anyway, I wanted to capture the
value of spamc's -c option in the variable. So I went with what
I posted. Never caught that it didn't do what I thought!
The above syntax will work for clamscan. I use it (for testing only;
I still rely on Virus Snaggers in production). Its only drawback
that I can see is that it does not permit the variable capture.
The following recipe to the above will, indeed, read the exit
status correctly.
But anyway, now we come to a big caveat about we have been mostly
silent, but which is pretty important: Procmail's var-capture code
(VAR=| program) is flawed. We already know that it fails on some
systems under some compiles. What is also known to me is that it
destroys memory space willy-nilly due to a bug in the code. In general,
for the current release of procmail, I find it a dangerous thing to use.
It seems to work (for those systems where it does not fail outright);
but it is zapping memory locations. This is what I understand from
what a programmer who studied the source code said, it's not what I can
see myself. I'm not trained well enough in reading source code to know
first-hand about what I'm saying. (And it might be that I'm restating
this all slightly wrongly, I don't know.) But in my recipes that I
craft for the general use of others, I try always to avoid the syntax.
I'll use "VAR = `program`" instead.
Personally, I do use a private compile of procmail that has this and
several other bugs fixed, and that offers some other extended
features, the biggest being left-match capturing. It's very cleverly
conceived by Mike Peeler. I do not know if Mike wishes to make
his code public or not.
Okay, thanks once again, Bart, for the eye-opener.
Back to the drawing board on my spamc code,
Dallman
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail