On 06.11.08 17:00, Joe Dragotta wrote:
> With the forwarding to SA active in both the system and user level
> procmailrc files, I was noting some odd behavior. The system level
> filtering was correctly tagging about 90% of the spam as spam and
> sending it to /dev/null/, and therefore was not being delivered.


If the system-wide procmailrc is sourced by procmail running under users'
accounts, it should use users' config files (user_prefs).

However if you run procmail before delivering of mail under any account,
that account's user_prefs is used for scoring.

Note that dropping mail in such case is quite risky - sender sees mail was
sent, recipient won't see it and you'll be unable to see what in the mail
caused the problem.

I would advise you to run SA at SMTP level (milter or other kind of filter),
but rejects only score over 10 or so - we've had FPs when rejecting mail
with score over 7.

> However some email was making it through for processing by the user
> level procmailrc file, being again forwarded to SA, and then SA was
> rewriting the subject to ID it as spam (the user_prefs file was not set
> to send spam to /dev/null). Thusly, I was receiving a small amount of
> email tagged as spam.


> As it turns out, the user_prefs file has higher scores assigned to some
> of the tests. Therefore the system level filtering was not identifying
> the email as spam (correctly so), but when the user_prefs file was
> invoked, by way of the second call to SA (by the user level procmailrc)
> the email was being tagged as spam, due to the higher scores in user_prefs.


That's quite correct and I would advise you calling SA twice - with safe
system settings from filter at SMTP level (so the mail would get rejected)
and from users' procmail (or whatever) with users' settings.

If you have enough of computer power, of course.

Also note that system-wide filter (like milter) can pass the username to
spamd, so mail received for one user will be checked with the users'
settings already for the first time. However that is impossible if your
system receives one mail for more users, which is still wuite common.

Filter then must choose which user will it pass to spamd, whcih will mean
users' configs and scoress won't be used, unless they pass the mail to SA
again.

> In any event, I am moving to use the spamd/c combination, in lieu of
> invoking SA from procmail.


hardly "in the lieu". You cannot replace procmail by spamc. You can replace
spamassassin with spamc from procmail, or you can replace procmail for
milter, amavis or different filter.

> <100% opinion>
> It may be a gray area, but perhaps as a point of future reference (and
> perhaps policy), it would seem that questions regarding the invocation
> of SA using procmail are well within the topic of this group.


Not the way you first raised the question.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Windows 2000: 640 MB ought to be enough for anybody