On Thu, 05 Aug 2021 09:50:46 +0200, Marc Baaden said: > As a perfectly content long-time EXMH user, I would like to improve my > spam handling. which is my number one pain point. > I have spamassassin installed and it filters successfully > a low amount of the spam. I think the spammers are just too active or > vary their credentials too often. So I was wondering, whether in > addition there is an easy way through exmh/nmh to add a sender to a > list to be automatically refiled to my spam folder as well. > > Any hints of how to implement such a thing, or something related? I of > course am also grateful for your opinion whether that makes sense or if > there are better options.
There's better options. And this mail will be long because it's turning into a full-blown how-to rather than just hints. :) To quote Linus Torvalds, from a long time ago when the linux-kernel mailing list was only handling 100 to 150 pieces of mail a day: "Note that nobody reads every post in linux-kernel. In fact, nobody who expects to have time left over to actually do any real kernel work will read even half. Except Alan Cox, but he's actually not human, but about a thousand gnomes working in under-ground caves in Swansea. None of the individual gnomes read all the postings either, they just work together really well." What I've been doing with spam is somewhat specific to the rest of my email handling setup, which uses fetchmail and procmail for all the heavy lifting. Also, my mail goes via Gmail, which does a lot of stuff on the front end. You could theoretically use nmh's inc and slocal instead of fetchmail/procmail, but the processing language is nowhere near as powerful. One important point is that at one time, "because reasons" meant that just letting spam sit in a gmail folder wasn't an option, because I had to be able to find stuff tagged as spam based on text in the body of the message, and that was just *painful* to do using the gmail web interface. The basic theory - the email addresses I use end up hosted on gmail. I run fetchmail in the background, and every 5 minutes it uses IMAP to pull new mail down. It then hands the mail to sendmail, which then uses procmail for final delivery. (That was easier to set up than getting fetchmail to invoke procmail directly). procmail then does a *whole* bunch of sorting and pre-processing (we're talking 200+ folders and a slimmed-down 500 lines of procmail rules - it used to be up over 1200 at one point). In .fetchmailrc, I do two fetches - one for gmail 'inbox' and one for gmail 'spam' poll imap.gmail.com with proto IMAP and options user '[email protected]' there with sslcertck mimedecode folder 'inbox' password '*****' is 'valdis' here ssl fetchsizelimit 0 smtpaddress localhost.localdomain poll imap.gmail.com with proto IMAP and options user '[email protected]' there with sslcertck mimedecode folder '[Gmail]/Spam' password '*****' is 'valdis+spam' here ssl fetchsizelimit 0 smtpaddress localhost.localdomain Notice that for the spam folder, it gets handed to sendmail and thence procmail with a destination 'valdis+spam' - I use that in a moment... Various things I have in procmailrc: To totally drop something (this case was a site that sent a bounce message back to the From: address rather than the SMTP MAIL FROM: address, which meant every time I posted to bugtraq or full-disclosure I'd get a bounce that didn't get the guy removed because the nimrod was forwarding his mail to another address) :0 Ew: *^From: [email protected] /dev/null This was a ruleset I used to deal with a server with a faulty intrusion sensor, so I wanted to get hardware alert emails *unless* the *body* of the mail told me that it was the once-an-hour whine about the sensor; :0 EHB: * < 8192 *^From:.*[email protected] *Sensor Name: Intrusion /dev/null If the mail was from Greg Kroah-Hartman and it was a linux-stable patch-review bomb (often with 100 to 300 mails in the series, and multiple times a week) drop it into the same trash folder that 'rmm' and exmh 'delete' dump stuff :0 E *^(To:|cc:|X-mailing-list:).*[email protected] *^From: Greg Kroah-Hartman <[email protected]> *^Subject: \[PATCH [45].[0-9] trash/. If you want mail dropped into a folder and marked as unread: :0 Ew:kernelnewbies/$LOCKEXT *^(To:|cc:).*[email protected] |rcvstore +kernelnewbies (Note this need a lockfile so procmail only runs one at a time, because rcvstore doesn't lock .mh_sequences itself. I use a per-folder lockfile so deliveries to different folders can happen in parallel) And the part about fetching the spam folder separately? It relies on the fact that Sendmail supports + addressing, and hands the part after the + as a command-line argument to procmail, so if it was 'spam' that's the folder it goes into. 'test' and 'inbox' are mostly relics from testing. # Snarf up stuff that GMail put in spam folder ARG = $1 :0 w:.bcc/$LOCKEXT * ARG ?? (spam|test|inbox) $ARG/. I never got ambitious enough to generalize this to full sorting of plus-addresses - but it's there if you want it. And regarding Linus's quote - the stats for "so far this month and it's only the 5th": 389 stable-review mails to /dev/null, 4,759 other linux-kernel mails, 15 to the spam folder, and 638 scattered across 43 other folders.
pgp7rtO_RGeey.pgp
Description: PGP signature
_______________________________________________ Exmh-users mailing list [email protected] https://listman.redhat.com/mailman/listinfo/exmh-users
