On 2017-10-20 21:28:29 (+0200), Rick van Rein wrote:
On 2017-10-20 21:17:26 (+0200), Philip Paeps wrote:
On 2017-10-20 19:51:07 (+0200), Rick van Rein wrote:
Wouldn't it be a lot easier simply to reject those with SPF? If
you're seeing mail from one of your domains coming in from a host you
know couldn't have legitimately sent it, you can reject it outright.
That would block not just the spam, but also legitimate bypassing
through forwarders and email lists (if they don't do VERP). I would
prefer not to go there for something that could be solved with local
information.
It would break legitimate forwarders, but that's easy to whitelist
because (hopefully) you know your forwarders. The salient part of my
configuration is:
smtpd_sender_restrictions =
permit_mynetworks
reject_unknown_sender_domain
check_client_access cidr:$config_directory/access_client.cidr
check_client_access hash:$config_directory/access_forwarders
check_recipient_access pcre:$config_directory/access_recipient.pcre
check_spf
The `access_forwarders` table lists all legitimate forwarders. There
are a couple of forwarders in `access_recipient` too: forwarders whose
IP addresses I can't (easily) control, I configure to forward to a
unique (and opaque and non-guessable) alias.
But SPF does rely on information that is not local (to Postfix).
If you don't want to use SPF, you could use a combination of a
check_client_access to whitelist your hosts followed by a
check_sender_access.
That's a neat work-around. It hinges on not having any checks or
rejects after these ones, but for the sender_restrictions, that is
currently true.
Since there's not all that much you can check in sender restrictions,
that shouldn't be a big problem. You may be able to fiddle with (not)
deferring reject if that's a limitation for you.
If you don't want to rely on SPF, you should be able to modify my
configuration by adding a `check_sender_access` after the whitelists.
One way to go could be to create a database of sender domains to
validate, enter my own domains in it, and use "external" access to my
own MTA and probing it. But that leads to cyclic probing! I suppose
I am really looking for something simpler -- namely an invocation of
the virtual(8) server for addresses on the said lists.
Why bother validating the address?
Because that is the vital piece of information that sets the attempts
by spammers aside from proper behaviour. Because that gives a good
source for detecting, with high degree of certainty, that a party is
sending spam.
If you really have no control over your forwarders, this is true.
It may be worth the effort to take control over the forwarders though.
SPF blocks a lot of crap. As I wrote: the forwarders you know by IP
address can simply be a check_client_access. Forwarders whose IP
addresses are variable can hopefully be taught to forward to a unique
address.
For bootstrapping new restrictions, I find `warn_if_reject` extremely
helpful.
Good luck.
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
