Well, there are
limitations. To briefly summarize those that may apply to your situation:
1. The filter doesn't decode RFC 2047-encoded headers, so your regular expression would need to account for this if it's a possibility.
2. The header check applies no matter who the recipient is, so you can't exclude the spammy From: address for some of your users but not others.
3. If you use a large number of rules, system performance can suffer to the point where the mail queues get backed up.
Plus one that isn't listed there...
4. A poorly-constructed regular expression may reject legitimate mail.
To describe #1, the following two header lines are equivalent:
Code:
From: spammer@whateverdomain.com
From: =?US-ASCII?B?c3BhbW1lckB3aGF0ZXZlcmRvbWFpbi5jb20=?=
Your nemesis could also change the format of his From: address, like so:
Code:
From: <spammer@whateverdomain.com>
From: Joe Spammer <spammer@whateverdomain.com>
From: "Joe T. Spammer" <spammer@whateverdomain.com>
From: Joe
Spammer <spammer@whateverdomain.com>
These are all legitimate formats for the From: header.
If this person is using a consistent format, and you aren't going to be adding a bunch of rules, I don't think you'd have a problem with doing something like the below.
Code:
/^From: .*spammer@whateverdomain\.com/ REJECT
Keep in mind the cautions above. For example, that rule would also reject someone who (probably unlikely) is using the address
Code:
From: "I hate spammer@whateverdomain.com" <notaspammer@anotherdomain.com>
So "tricky" maybe isn't the right word, but there are possible hitches.