8

I am getting a lot of spam messages from a certain country. They all have the same pattern in the source. I want to write a procmail rule to automatically move all those emails to my Spam folder.

The source of a spam email might look like this ("[REDACTED]" added by me to protect my privacy):

Return-Path: <>
X-Original-To: [REDACTED]
Delivered-To: [REDACTED]
Received: from [REDACTED] ([REDACTED] [REDACTED])
    by [REDACTED] (Postfix) with ESMTPS id 2AC8E731E799DC
    for <[REDACTED]>; Sat,  9 Jul 2022 20:16:41 +0000 (UTC)
Received: from [REDACTED].org ([REDACTED].ru [REDACTED])
    by [REDACTED] (Postfix) with ESMTP id 6F1865ECD8
    for <[REDACTED]>; Sat,  9 Jul 2022 20:16:40 +0000 (UTC)
[...]

What I want to do is look at the "Received" headers and throw everything that comes from .ru TLD into Spam.

My attempt is this:

:0 H
* ^Received:*\.ru
.Spam/

However, I'm new to writing procmail rules. How can I go about testing my new rule so I know it's correct?

RommelTJ
  • 183
  • 1
    If you really are that bombarded, why not just wait for the actual spam and just check the the matching folder or the logs? Alternatively this provider offers a throwaway mail address with sending option from a Russian domain. Still means sending yourself an email, though. – FelixJN Jul 10 '22 at 21:14

2 Answers2

7

procmail accepts the mail message from standard input, so will act on anything you pipe to it. Ideally what you pipe to it should be the same as what the Mail Transport Agent will send. Also to test use a custom rules file before including the new rules in the .procmailrc proper:

# rm output
# cat testmessage
From user@example.org
To: user@example.org
Subject: foo

test


cat testrules


:0 H


    

  • ^
    • 



output


procmail testrules < testmessage


cat output


From user@example.org
To: user@example.org
Subject: foo


test
thrig
  • 34,938
4

Procmail has an -m option which lets you test a rule file without delivering a message anywhere; it turns off delivering to your inbox $DEFAULT if none of your rules matched. The option requires you to pass in the file name of the rule file you want to run, and allows you to set variables like VERBOSE=yes on the command line.

procmail -m test.rc VERBOSE=yes <test.msg

Perhaps see also https://www.iki.fi/era/mail/procmail-debug.html (old but still vaguely relevant).

For your concrete rule, it's prone to false positives. Remember that the regex engine will accept any partial match; so your rule will trigger on e.g.

Received: from postfix.rules.example.com ...

because it matches the substring .ru. You can somewhat guard against this by requiring a word boundary after ru:

:0
* ^Received:.*\.ru\>
.Spam/

Notice also how the regular expression for "any text" is .*, where . matches any one character, and * says to repeat the previous expression as many times as possible, but accept zero repetitions, too. (Thus your attempt would permit zero or more colons after Received but only if immediately followed by the literal text .ru.)

You might be able to tighten this up some more, but Received: headers are notoriously poorly standardized. Many servers run Postfix or Sendmail which both create Received: headers where the first portion after the colon indicate from HELONAME (RDNS [IP]) where IP is the actual IP address, RDNS is the result of a reverse DNS lookup (possibly empty) and HELONAME is tha name the remote client indicated for itself when it initiated the SMTP transaction with a HELO or EHLO command (the client can put anything they want here; some put obvious forgeries, which are good spam filter fodder!) ... but also, many other servers run different software which uses a different format, or encourages the local admin to configure their own format (ugh, Exim). The Received: headers near the top of each message are from servers which are the most local to you, and thus somewhat more predictable and reliable than the more distant ones, which could easily contain entirely made-up information.

Anyway, this is ultimately somewhat unsatisfying. If you can convince your ISP to block these unwanted messages during SMTP transmission (effictively killing the delivery attempt as if your mailbox was unavailable) that's far more efficent. Some providers offer their users access to e.g. SpamAssassin which lets you block messages in the Russian language (though the precision is not exactly stellar; the mechanism is not very good at distinguishing between e.g. Russian and Serbian, so you'll want to block or allow all Cyrillic languages actually) and some will block traffic on the IP level so that known spammers are unable to even connect. But as a last line of defense against the vandals, Procmail is obviously vastly better than nothing.

tripleee
  • 7,699