From:
[email protected]
So do
# grep --files-without-match \> /home/*/.procmailrc
etc. to root them out instead for now.
"M" == Mark Symonds <[email protected]> writes:
hrmm yes. Perhaps a script run from exim.conf at delivery time?
I was thinking of a less automated more personal approach, but...
Otherwise running such on every homedir at frequent enough intervals
could be very expensive, lots of users on that box and all it takes is
for one to implement a bad procmailrc moments after the last check was
made and the box still gets crashed.
Also have to check for those who put in an extra 0 or three after their
.
Which brings us back to the current check - simply ignore .procmailrc's
on mails over 200k.
We don't care about the limits they put in there;
we have already enforced the maximum.
Hey, wait! Can you still execute the old way using your |.forward file
pipe command? Oh my!
Anyway, even if above thought doesn't work, I think we might be able to lsearch a flatfile of users for whom this test is excluded. This way everyone has the 200k ignore thing except for those in the special
privilege list. What do you think?
One wants a wrapper /usr/bin/spamassassin that will say,
Dear $USER,
You have attempted to send an incoming mail that was bigger than
200000 bytes thru spamassassin. This will create too much of a burden
on the system, therefore you will see we let it bypass spamassassin.
Please see /usr/share/doc/spamassassin/procmailrc.example or use spamc
(after it gets debugged, and it passes big messages too)
And then calls cat, else /usr/bin/spamassassin_real, apparently.
All these antics wouldn't be needed if spamassassin implemented
limits, like spamc, which is the bug I'm CCing to.
--
To UNSUBSCRIBE, email to
[email protected]
with a subject of "unsubscribe". Trouble? Contact
[email protected]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)