Whitelisting mail servers

[amavisuser at skopos.be]

Hello Nick,

As suggested by Matus, the MTA seems the better place to whitelist
those servers.

Such a check at MTA level is relatively cheap (in terms of server load),
and because a match results in an immediate OK decision, no further
checks are needed, so it reduces the load on your amavis process, on RBL
blocklists etc. - and thus on the MTA as a whole.

Also, it is a simple yes/no decision. No need to carefully adjust the
weight of the various filter criteria. These are very useful to make
educated guesses about an unknown client, but in your case you don't
need to "guess" (and occasionally get it wrong).


If you are running Postfix, I would do as you describe below,
i.e. with a check_client_access map.

I'd suggest one "cosmetic" change, however. Since it's possible to have
multiple "check_client_access" statements, I would not add the bank
IP's to your existing rbl_override map, but use a new, separate one
with a more descriptive name instead (e.g. "whitelisted_bank_servers").


The only problem then is to collect (and maintain!) the list of all the
bank server IP's, but you could lookup their SPF records to get you
started (for those banks that have them).

As you noted, you can also use client names instead of IP's, but that
is a little bit less reliable (because it needs a DNS lookup to
succeed). OTOH nothing stops you from listing both in your map.


If one particular bank server is not (yet) on your whitelist, that's
no disaster, as it will still go through all the usual checks as before.

As a safety net, you could add a "check_helo_access" and/or
"check_sender_access" map, to list valid EHLO/FROM names that your
banks are using. Of course these are easily faked, so whitelisting is
not a good idea here. But you can use a "DEFER_IF_REJECT" action
(assuming that your amavis does not silently "discard" them, but does a
regular bounce). The "defer" would prevent that bounce and buy you
some time to add the new IP to your whitelist.

Of course, that means that you must be willing to "babysit" your mail
server, watching the logs and whitelisting the new IP in time for
a next retry.

An extra advantage of these checks is that - in my experience - phishing
mail tends to use minor variations on valid names (such as nbgr instead
of nbg), and they recycle these for some time. If you detect that, you
can add them to your map(s) with a "REJECT" action.

This advice is of course worth what you paid for it <g>.

If you have any questions, feel free to ask - possibly off-list as this
postfix stuff may be a little bit off-topic on an amavis list.

Luc

-----Oorspronkelijk bericht-----
From: Nikolaos Milas <nmilas at noa.gr>
Date: Sun, 27 Nov 2022 20:35:07 +0200

>Matus, you suggested to make an exception at the MTA level. I guess
>you mean something like (in Postfix):
>
>    smtpd_recipient_restrictions = reject_invalid_hostname,
>                                    reject_unauth_pipelining,
>                                    permit_mynetworks,
>                                    permit_sasl_authenticated,
>                                    reject_unauth_destination,
>                                    check_client_access
> hash:/etc/postfix/rbl_override, ...
>
>where /etc/postfix/rbl_override is:
>
>    1.2.3.4 OK
>    1.2.3.5 OK
>    mail.freemailer.tld OK