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 <nmi...@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
