On 08/29/03 01:37 PM, Larry Gilson sat at the `puter and typed:
> Hi Louis,
>
> > From: Louis LeBlanc
>
> > Sorry for barging in on this thread, but I'm trying to get this
> > working myself right now (spamd/spamc with procmail). I have one
> > question though.
>
> Join the party!
:-)
> > Regarding spamc, if the -f flag us used and it can't connect to
> > spamd, it returns without an exitcode set. Do you use this fact to
> > run the message through spamassassin as a backup? If not, do you
> > know whether this is possible?
>
> Honestly, I don't know. It is a good point and I would like to know the
> answer myself. I have not been using the -f flag. I have tested it though
> and if spamd is down, the message is still processed.
>
> Anyone know the answer to this?
>
>
> > Right now, I use the following in ~/.procmailrc:
> >
> > :0fw
> > * !^Subject:.*SAtalk
> > | spamassassin -a
> >
> > And for spamd/spamc, I'd probably use something like this:
> >
> > spamd -a -c -d
> >
> > and in ~/.procmailrc:
> > :0fw
> > | spamc -u LOGNAME
> >
> > What I'd like to do is check to see if spamd managed to tag a message
> > and if not, pipe it through the old spamassassin -a above (I could
> > probably just check for the X-Spam-Flag: header and pipe it through
> > if it doesn't exist). I still want to use per/user configs and bayes
> > dbs in either case.
> >
> > Can you tell me if I'm totally off here?
>
> I can't see your entire Procmail script and I really don't understand the
> mechanics of your system. It looks like you are trying to pipe to spamc
> through a site-wide configuration. If so, how are you getting the username
> for the -u option? I can think of how to perform a sitewide Procmail/SA
> solution with a user-based Procmail/SA solution but that would ential
> sending the message through SA twice. There is then a way to perform a
> site-wide only solution as well as a per-user only solution. What are you
> really trying to do?
Sorry, not real clear there. I'm calling spamassassin (or in my case
now, spamc) from a per user ~/.procmailrc file. The message is
processed through SA, then a recipe further down the script checks the
spam status header added by SA, filing it into the users appropriate
imap folder. The procmail setup I have is pretty well tweaked out -
except this little detail.
> My opinion . . . I think a combo site-wide and per-user solution is
> overkill. You should probablly stick to one or the other. Furthermore, I
> just don't see the need for a per-user solution unless you are forced to do
> it, like an ISP. Again these are just my opinions. If anyone has insight
> to counter my belief, I would love to be educated.
Yeah, I do have a global local.cf, but I'm pretty much set on sticking
to the per-user solution, with user overrides enabled. I'd just like
to see how that -f flag can be used to catch messages that spamc
couldn't get processed, and pipe them through the spamassassin script
as a last resort.
I've changed my own ~/.procmailrc file to look like the following:
#######################
## sundry setups and preliminary traps preceed . . .
:0fw
* !^Subject:.*SAtalk
| spamc -u "$LOGNAME"
:0H
* ^X-Spam-Status: Yes
* !^Subject:.*SAtalk
{
# domain specific bounces to pester those with email addresses
FOLDER=spam
}
:0
* FOLDER ?? !spam
{
# Various non-spam handlers
}
# and finally, deliver it to Cyrus imapd
:0 w
* FOLDER ?? .
| /usr/local/cyrus/bin/deliver -q -m "$FOLDER" -- "$LOGNAME"
:0 wE
| /usr/local/cyrus/bin/deliver -q -- "$LOGNAME"
EXITCODE=$?
LOG="
"
HOST
#######################
I hope that's been pared satisfactorily from 243 lines without making
it to obfuscated. BTW, I had lots of help with some of the more
complicated stuff here. Particularly the bit following the delivery.
As I understand it, the -f flag is unnecessary. According to the
spamc manpage, it defaults to on, and can't be turned off. It's only
kept in for backward compatibility, so I've just left it out. The
real question is how to check whether the return code was set and use
that to decide whether a rescan through spamassassin can be tried.
I thought about just checking for the presence of the X-Spam-Status
header, but that could match if the header were already present
anyway, even if spamc didn't succeed.
Thanks!
Lou
--
Louis LeBlanc [EMAIL PROTECTED]
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
http://www.keyslapper.org ԿԬ
Hlade's Law:
If you have a difficult task, give it to a lazy person --
they will find an easier way to do it.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Spamassassin-talk mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
