On Tue, Jun 10, 2003 at 12:49:45AM +0100, Clive Menzies wrote: > On (09/06/03 17:36), Pigeon wrote: > > On Mon, Jun 09, 2003 at 02:38:42PM +0100, Clive Menzies wrote: > > > And I'm still struggling with my set up .... not > > > managed to implement procmail yet and the cron job to "getmail" is being > > > mailed to me every 5 five minutes... but that's another story;) > > > > Re procmail: I haven't found any need for this; personally I find that > > setting up Exim filtering rules in my ~/.forward, which may call > > shellscripts, suffices for my needs (delivering to different > > mailboxes, stripping off standard footers). Exim's language is a bit > > more legible than procmail's... (Useful command option: exim -bm. > > Handy for feeding a footer-stripped message back into the mail system > > for final delivery) > Do you also use this for filtering spam? I was thinking > procmail/spamassassin ... Ah, right. I haven't installed any spam-filtering tools yet because only recently has it begun to be a problem, and then more because of the offensive content than the volume; I am currently in process of accumulating a corpus of spam to feed to a Bayesian filter to start it off. I've sort of ruled out spamassassin because of its reputation for being a resource hog (due to personal conceptions of elegance rather than shortage of resources). So the following paragraph is not based on actual experience :-) Since Linux anti-spam tools tend to operate as spam-taggers, and leave other programs to do the filtering based on the tags, I don't see any particular reason you couldn't have a set of filtering rules that say: if tagged as spam, save in the "spam" box; if as ham, carry on with normal ham filtering; if untagged, pass to spam-tagger, which adds tags, then feeds the tagged message back in with exim -bm. > > Re cron job: modify it so that the command output which is currently > > being mailed to you is redirected to /dev/null. > > Sorry to be dense ;) Can you be a bit more explicit? Easiest with an example, I think... Sometimes my main box can't use the network after booting unless the networking services on the gateway, which is headless, are restarted as well. So I have a cron job on the gateway to periodically ping the main box and restart the networking if it can't get through. The command I run (with crontab gubbins snipped; pigeon is the name of the main box) is: ping -c 4 pigeon > /dev/null || /etc/init.d/networking restart > /dev/null The ping command produces the following output: PING pigeon.pigeonloft (192.168.1.1): 56 data bytes 64 bytes from 192.168.1.1: icmp_seq=0 ttl=64 time=0.5 ms 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.4 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.3 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.4 ms --- pigeon.pigeonloft ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.3/0.4/0.5 ms which would normally be mailed to me every time the cron job runs. However, the "> /dev/null" bit throws that output away. The second occurrence of "> /dev/null" throws away the "Reconfiguring network interfaces: done." message from the second part of the command. Because all the output is thrown away, there is nothing to go in the mail message that the cron daemon would be sending you, so it doesn't send it. If either of these commands produces an error, though, the error output is not thrown away. "Normal" output and "error" output are treated as two distinct streams, although this distinction is often masked by the fact that both streams write to the screen by default (or to the mail message, with a cron job). Therefore, I only get a mail message when something goes wrong. If I never wanted to get any mail from this job at all, I would stick "2> /dev/null" in there as well, to throw away the error output. Hope this makes sense. -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
Attachment:
pgptfRMI8am5R.pgp
Description: PGP signature