also sprach dman <dsh8290@rit.edu> [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. maybe they document it
more sophisticatedly, (b) you doubling the load unnecessarily, and (c)
you are asking for trouble. why not let procmail be MDA?
> | why do you insist on using exim till the actual delivery?
>
> I like my filter file :-). Perhaps the above explanation helps too.
oh lord...
> | > 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.
> | > 2) play some tricks to set $HOME and tell users that mail/mail
> | > must be able to read their prefs
> |
> | good luck! telling users anything :)
>
> :-). Fortunately for me, I'm the only user right now. Still, I want
> the setup to be "proper" and allow for customization at the user
> level, especially since I expect to admin larger systems at some
> point.
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.
and: a cronjob to do anything to user homedirs is *not* a good idea...
> | 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...
> | the spam flag will always be there, but i've had users who objected
> | to a program even having access to their mail. i refrained from
> | explaining what postfix does. these are executives ;)
>
> LOL! If a program doesn't touch the mail ... then the mail must be
> only a figment of your imagination (or hand-written snail-mail).
word.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:"; net@madduck
"it would be truly surprising
if sound were not capable of suggesting colour,
if colours could not give the idea of the melody,
if sound and colour were not adequate to express ideas."
-- claude debussy
Attachment:
pgpO65YsjDIGL.pgp
Description: PGP signature