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/.*[:<] *//'`

* ? fgrep -qxis $FROM $PMDIR/killfile


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:


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

* ^To.*one@example.com

* ^To.*two@secondexample.net

This is much more cumbersome for entering new addresses.

  • 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... – Jeff Schaller Feb 7 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. – PeterCH Feb 7 at 18:02
  • is it a requirement that the spam destination addresses are in a file, versus in the procmailrc? – Jeff Schaller Feb 7 at 18:09
  • @JeffSchaller No, it doesn't really matter. It's just that I could enter the addresses in the killfile like this: one@example.com two@secondexample.net In procmailrc I'd have to do it that way, I think: :0: * ^To.*one@example.com /dev/null :0: * ^To.*two@secondexample.net /dev/null This is much more cumbersome for entering new addresses. – PeterCH Feb 7 at 18:15
  • I have added an explanation to my question, so it becomes clearer – PeterCH Feb 7 at 18:21

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

* ^TO_(one@example\.com|two@example\.com|three...)

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.

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

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

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

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.

  • 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 – PeterCH Feb 7 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. – tripleee Feb 8 at 4:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.