090106 Harry Putnam wrote: > Philip Webb <purs...@ca.inter.net> writes: >> 090106 Willie Wong wrote: >>> you may want to change the root line to "root=purslow", >>> so the mail gets sent to purslow instead of postmaster >>> (which according to /etc/mail/aliases becomes root again). >> That doesn't work, but adding '> /dev/null' or '-s' in crontab does. >> The latter seems simpler, so that's what I've done. >> It doesn't explain why the problem suddenly arose last Sunday >> after I made a simple editing change in .fetchmailrc >> & nothing like this had happened before >> with the same crontab & ssmtp.conf : perhaps there's an obscure bug, >> but the irritating problem has been resolved & I have other jobs today. > I don't see the actual change made to fetchmailrc.
The problem started after I commented the line 'set logfile "/home/purslow/Mail/logfile"'. > You can introduce an unprintable CHAR into a *.rc file > and not be able to see it. you might want to use vim to check each line. > You can hit the el (l) lowercase on each line > to expose most kinds of unprintable char: > 1) : 2) l 3) enter > Then the line appears in the command area with any unprintable chars, I tried that, but there's no sign of an unprintable character. > Do you control this machine ? Yes, I built it & no-one else ever gets near it. Nearly all of the problem seems clear now, so for the record: the basic problem arose because when I went over to downloading mail via a user cronjob for security, I didn't add '-s' to 'fetchmail'; as a result, Fetchmail was writing several lines to ~/Mail/logfile every 5 min with the obvious result that the file got very big; frustrated by this, I took a quick look & the simple fix seemed to be to remove the line in ~/.fetchmailrc which defined it (see above); as soon as I did this (early Sun), msgs starting arriving in my spamtrap mysteriously originating at 'r...@myisp'; moreover, other lines continued to be added to logfile , which I realised came from Procmail, so I altered ~/.procmailrc to suppress those (successfully); to try to stop the mail msgs, I restored the original ~/.fetchmailrc , but that had no effect, at which point I sought help via this list. The correct procedure is to stop the msgs at source with 'fetchmail -s', so having done that, the real-life irritation has gone away. It's also clear how the rogue e-mails arose: when a cronjob ouputs msgs, they are handled by Cron itself (see 'man cron'), not eg by Fetchmail, so Cron sent them to 'root', which led all around the haystack. What remains unclear is why restoring the original ~/.fetchmailrc didn't cause the msgs to be sent again to ~/Mail/logfile , but that's not important enough to take more of my time. -- ========================,,============================================ SUPPORT ___________//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT `-O----------O---' purslowatchassdotutorontodotca
