* On 2006.01.01, in <20060102013348.GA12175@mdssdev05>, * "Ed Peschko" <esp5@xxxxxxx> wrote: > hey all, > > I was wondering if mutt had an 'integrated killfile' type feature, ie: > that when mail is read into mutt, mutt checked each email for certain > patterns and deleted them silently before the mail was opened. > > I'd love to have something like this, rather than screwing around with > procmail and the like. I don't like using procmail for this either. I have this macro: macro index \;j "<enter-command>source '$HOME/.mutt/killfile.pl $DOMAIN |'<enter>" "Delete junk mail." $DOMAIN is really just an arbitrary selector for which killfile to use. Normally I base it on the location I'm running mutt in. In my primary configuration (at work) $DOMAIN is uchicago.edu. In other configurations it might be something else. ~/.mutt/killfile.pl is attached. It reads a killfile from disk and turns it into a sequence of mutt commands for weeding out messages. Because it's read from disk at execution time, mutt doesn't need to be restarted when you update the killfile. If your killfile is short, killfile.pl will produce a single compound pattern, and it will execute quickly. If your killfile is large, it might not be possible to get everything into one pattern (because of mutt's internal command length limit). In such a case, killfile.pl produces two or more patterns, and executes them all. This is somewhat slower. The killfile is stored in ~/.mutt/killfile.$DOMAIN. It's very simple: a list of mutt patterns to match, one per line. They can be compound patterns. Lines beginning with "#" are ignored, as are empty lines. I've attached my ~/.mutt/killfile.uchicago.edu as well, by way of example. (In fact, you can list multiple arguments to killfile.pl. "killfile.pl foo bar" would execute patterns from both killfile.foo and killfile.bar.) I find this fairly well in keeping with old trn killfiles, except that: a) It only does deletion (you can't use it to auto-tag or the like, as you could with trn). It would be straightforward to provide this, though, if you need it. b) You must manually maintain your killfile; there's no provision for "add messages like this one to the killfile". c) There's no direct provision for per-folder killfiles. But indirectly, if you wanted to have different killfiles for different folders, you could get creative with your macro definition and use the $DOMAIN parameter to select the per-folder killfile. -- -D. dgc@xxxxxxxxxxxx NSIT University of Chicago
Attachment:
killfile.pl
Description: Perl program
#~s 'DOS Track' #~s 'Hosts back on' #~s 'Network scan from' #~s 'adsync.sh' ~s 'Accounting Top Ten' ~s 'Mail glimpse' ~s '[a-z]+incident.sh' ~s '^ClamAV definitions' ~s '^E-MAIL MESSAGE SUMMARY ::' ~s '^Orca:' ~s '^Output from .cron. command' ~s '^Runorca ' ~s '^tripwire database init:' ~s 'checkpass.sh' ~s 'plaisance.s savegroup' ~s '^savegroup summary' ~s 'sshtrip' #~s 'test$' ~s 'tripwire:' ~s 'rotate.sh' ~t MAILER-DAEMON@ ~f krypton ~s 'Output from .cron. command' ~f mailman-owner ~s '^(Illegal|Listhost)' ~f news ~s '^okaybye|^control.pl' ~f root ~s '^Accounting' ~y secreport ~y maryamk ~y abuse ~s '^myNetWatchman Incident' ~y aegis ~s '^AEGIS' ~y avspam ~y backups ~s '^NSRnotify' ~y dmse ~s '^Staff.sh' ~y dmse ~s '^ldap numbers' ~y dmse ~s '^rotate.sh' ~y dmse ~s '^sss_.*\.sh ' ~y ensa ~s '^>>> (rightofway|oneway|eminent|domain): (pmx-qmeta-index|ppm upgrade|pmx-qexpire|pmx-qindex|pmx-queue|pmx upgrade)' ~y ensa ~s '^Returned mail: see transcript' ~y ensa ~f adm ~s '^$' ~y logs ~s '^Backup Status' ~y logs ~s '^Swatch Report' ~y logs ~s '^Tripwire Report' ~y mailman ~s '^Mailman queue files pending' ~y mailman ~s '^Returned mail: see transcript' ~y netsec ~s '^.automatic' ~y netsec ~s '^\\[UCHI-NSC' ~y nsc-tape ~s '^NSC' ~y quota ~f quota-admin@ ~C quota-admin@ ~y quota ~s '^(Your Email|Email deliv)' ~y usenet ~s '^news stats output' ~y usenet ~s '^okaybye output'