2

I want to block mails with certain recipient addresses using procmailrc (temporary addresses that now only receive spam).

I found a code sample for using a killfile/blacklist, but it only applies to sender addresses (FROM).

FROM=`formail -xFrom: | sed -e 's/ *(.*)//; s/>.*//; s/.*[:<] *//'` :0 * ? fgrep -qxis $FROM $PMDIR/killfile /dev/null

How can I adapt this code so that it applies to recipient addresses (TO)? It would be really great to simply be able to list the unwanted recipient addresses in the text file.

I'm very inexperienced with RegEx, so I'm grateful for easy to understand answers.

My goal is to be able to list the addresses to be blocked simply under each other:

[email protected] [email protected]

In the procmailrc I'd have to do it that way:

:0: * ^To.*[email protected] /dev/null :0: * ^To.*[email protected] /dev/null

This is much more cumbersome for entering new addresses.

Improve this question
5
  • 1
    if there's not too many, I'd be tempted to just create an included file with a bunch of "^TOspam1 ... /dev/null" stanzas... Commented Feb 7, 2019 at 17:50
  • @JeffSchaller Thank you for the suggestion (even if I haven't quite understood it yet). But unfortunately there are more than a hundred addresses. Commented Feb 7, 2019 at 18:02
  • is it a requirement that the spam destination addresses are in a file, versus in the procmailrc? Commented Feb 7, 2019 at 18:09
  • @JeffSchaller No, it doesn't really matter. It's just that I could enter the addresses in the killfile like this: [email protected] [email protected] In procmailrc I'd have to do it that way, I think: :0: * ^To.*[email protected] /dev/null :0: * ^To.*[email protected] /dev/null This is much more cumbersome for entering new addresses. Commented Feb 7, 2019 at 18:15
  • I have added an explanation to my question, so it becomes clearer Commented Feb 7, 2019 at 18:21

2 Answers 2

Reset to default
1

I don't have procmail at hand to test, but here's one approach:

:0 * ^TO_(one@example\.com|two@example\.com|three...) /dev/null

The idea is to put every spam destination address as an alternation/possibility in the "^TO_" magic regular expression. A match on any of the spam addresses directs the email to /dev/null. I've pedantically escaped the periods in the email addresses so that they match periods instead of holding their usual regular-expression meaning of "any single character". Unlikely to be a problem in practice, as your spam-addresses won't likely receive emails destined for "one@exampleJcom" ("J" standing for any other random character).

I like this approach because it keeps the processing simple and within procmail.

If the list of spam targets changes frequently, I'd consider a different approach, such as an INCLUDERC that pulled in a generated file that contained "/dev/null" recipes for each spam target.

The "How can I do a logical OR of two or more conditions?" question in the Procmail FAQ covers the one|two|three syntax. The ^TO_ syntax is described in the Procmail Quick Reference or in your local man procmailrc.

Improve this answer
1
  • 1
    You could populate the list after ^TO_ from a disk file, like addrs=`tr '\n' '|' <killfile`; addrs="(${addrs}completelyunlikelystring) or whatever. Commented Feb 7, 2019 at 18:45
1

The recipe you found can easily be adapted to extract a To: address instead.

TO=`formail -xTo: | sed -e 's/ *(.*)//; s/>.*//; s/.*[:<] *//'` :0 * ? fgrep -qxis "$TO" killfile /dev/null

Of course, this could be extended to extract CC: and a number of other recipient headers as well. But the proper solution would be to configure these addresses to not deliver into your inbox in the first place.

Improve this answer
2
  • Thank you. This looks like a very good solution. The addresses werde created because I use a catchall domain. With each new registration somewhere in the Internet, I use a new individual address. If the address should be abused sometime, I can block it in this way. With my old webhoster it was very easy to do this via a web interface, my new webhoster only offers procmailrc. Is it very complicated to add cc addresses to your solution? Bcc addresses will hardly work. Or? But so far these are rarely used by spammers, in my personal experience. Translated with www.DeepL.com/Translator Commented Feb 7, 2019 at 19:09
  • Jeff's solution already addresses that, perhaps with my comment. There is no sane way to handle Bcc, no; that's one of the reasons why blocking earlier would be a better solution. Commented Feb 8, 2019 at 4:24

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.