The checksenderaccess controls only apply to the envelope sender (MAIL FROM) address given at the start of the SMTP transaction, not the one specified in the "From: " header. If returnpath.idiotdomain.com is consistent, you should be able to simply put that hostname in the access file with a REJECT action; you don't have to specify a full user@domain address. (Or you could use .idiotdomain.com, depending on circumstances.)

It's possible to do content filtering on the "From: " header, but this is trickier to set up.

@Vance:

The checksenderaccess controls only apply to the envelope sender (MAIL FROM) address given at the start of the SMTP transaction, not the one specified in the "From: " header. If returnpath.idiotdomain.com is consistent, you should be able to simply put that hostname in the access file with a REJECT action; you don't have to specify a full user@domain address. (Or you could use .idiotdomain.com, depending on circumstances.)

It's possible to do content filtering on the "From: " header, but this is trickier to set up.

I should probably have used whateverdomain.com instead of idiotdomain.com to indicate that perhaps someone legitimate could use that same domain in the future.

Anyway, you claim that the header stuff is "trickier to set up". Are you sure? This website

~~[http://mattshaw.org/news/how-to-filter-mail-with-postfix-headerchecks/" target="blank">](http://mattshaw.org/news/how-to-filter- … er_checks/">http://mattshaw.org/news/how-to-filter-mail-with-postfix-header_checks/](

has some simple instructions for it. What do you think about this? He is doing it in a pretty simple way, but is there any reason not to do this?

I copy-paste his instructions here for future reference:

> #main.cf

headerchecks = regexp:/etc/postfix/headerchecks

/etc/postfix/header_checks

/^From: "spammer/ REJECT

/^To: bob@here.com/ REDIRECT bob@there.com

/^Subject:.*viagra/ DISCARD

List of actions: http://www.postfix.org/header_checks.5.html

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:

From: spammer@whateverdomain.com

From: =?US-ASCII?B?c3BhbW1lckB3aGF0ZXZlcmRvbWFpbi5jb20=?=

Your nemesis could also change the format of his From: address, like so:

From: <spammer@whateverdomain.com>
From: Joe Spammer <spammer@whateverdomain.com>
From: "Joe T. Spammer" <spammer@whateverdomain.com>
From: Joe
    Spammer <spammer@whateverdomain.com></spammer@whateverdomain.com></spammer@whateverdomain.com></spammer@whateverdomain.com></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.

/^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

From: "I hate spammer@whateverdomain.com" <notaspammer@anotherdomain.com></notaspammer@anotherdomain.com>

So "tricky" maybe isn't the right word, but there are possible hitches.

Using something that's designed for the task, e.g. procmail or Sieve is probably going to be better overall for this task.