On Wed, Jan 16, 2002 at 05:30:55PM +0100, martin f krafft wrote:
| also sprach dman <[EMAIL PROTECTED]> [2002.01.16.1704 +0100]:
| > Exim doesn't run pipe commands immediately like procmail does (with
| > 'f' flag). It schedules the command to be run later, and later
| > (during the actual delivery) it runs the command. Thus the command
| > _must_ deliver the message to the final (next) destination or else it
| > will be lost because exim is finished with it. The technique, then,
| > is for the output from spamassassin to be directed back to exim. exim
| > sees this as a new messge to deliver, though. You can see how this
| > would lead to an infinite loop of spamscanning everything.
|
| sounds like (a) exim does it just like postfix.
dunno
| maybe they document it more sophisticatedly,
documentation for exim is _excellent_.
| (b) you doubling the load unnecessarily,
I don't think so. How much load can deciding, a second time but with
different results, where to deliver add? Certainly I'm increasing the
load because before spamassassin wasn't run and now it is :-).
| and (c) you are asking for trouble. why not let procmail be MDA?
The manual (man procmailrc) is incomplete, I didn't wholly understand
the configuration (which naturally limits what I can do), and I like
exim's filter syntax and style much better.
| > | > 1) no user prefs
| > |
| > | depends on the user base. for instance, the users on some of my systems
| > | can't even spell "shell account". so i do it globally anyway. those
| > | power users who want full control can create ~/.no-spamfilter and use
| > | spamassassin -P from their procmail. simple as that.
| >
| > Doesn't spamassassin combine the global (/etc/spamassassin.*) config
| > with the user's anyways?
|
| doesn't matter. once it copies one to the user directory, it takes
| precedence, so you can configure globally all you want.
Meaning ... the user inherits the global config and overrides whatever
they want, just like bash (and most everything else), right? Your
wording there throws me a little.
| expect to admin? are you *sure*? i mean, do you *really* want that? i'd
| think twice! no, thrice! no, n+1!
|
| > | i think this might even warrant a cronjob to do 0644 on
| > | /home/*/.spamassasin.rc
| >
| > Good idea, but what if someone changes the perms after the last cron
| > run and before the spamassassin run? This would probably need to be
| > done right before spamassassin is run, which would require root perms
| > in the spamcheck script (which can certainly be dropped, but still,
| > this doesn't seem right).
|
| i think spamassassin would deal just fine. the user's prefs wouldn't be
| incorporated, but i am sure it wouln't die because of a trivial thing
| like that.
it does, aside from that annoying output
| and: a cronjob to do anything to user homedirs is *not* a good idea...
I can't disagree here (well, we're not talking about the user's
crontab :-))
| > | well right, but i personally like the spamassasin report in the body (i
| > | can always delete it again with vi), and others simply hate it.
| >
| > Can't this be overridden by the user's config?
|
| yes, but not to the extent that i wanted...
Fair reason to write your own.
-D
--
The righteous hate what is false,
but the wicked bring shame and disgrace.
Proverbs 13:5
