On 5/27/24 4:59 AM, gil...@poolp.org wrote:
May 27, 2024 2:53 AM, "Ian Darwin" <i...@darwinsys.com> wrote:
On 5/26/24 8:45 PM, gil...@poolp.org wrote:
May 27, 2024 12:41 AM, "Ian Darwin" <i...@darwinsys.com> wrote:
On 5/26/24 5:40 PM, gil...@poolp.org wrote:
May 26, 2024 9:46 PM, "Ian Darwin" <i...@darwinsys.com> wrote:
I'd like to use the fcrdns filter but one of my users has a non-negotiable need
to get mail from a
site with inept administration. Is there a way to let this one site bypass this
one filter?
I have two fairly standard 'listen' clauses and the corresponding matches. I
had fcrdns on the
first one for a day or two until the flames started.
...
so basically here's how builtin filters work:
filter check_fcrdns phase connect match !fcrdns \
disconnect "550 no FCrDNS is so 80s"
they hook to a specific phase of the session and match session parameters,
then apply an action if the criterias are matched.
in this case, you hook the connect phase and match !fcrdns, so you will be
killing any client that doesn't have fcrdns immediately.
there are multiple ways to tackle your problem, depending on what info you
have about the clients you want to allow:
a- if you know their IP address, you can keep your check at connect phase,
and add a bypass filter for these specific addresses:
filter check_fcrdns_bypass phase connect match src <sometable> bypass
filter check_fcrdns phase connect match !fcrdns \
disconnect "550 no FCrDNS is so 80s"
Woot - that one worked, thanks!
And, I went with the simplest config, not combining them, so it'll be
easier to remove the bypass when it's no longer needed (you never know,
the inept admin might take my advice and configure their dns correctly
:-)).
Thanks
Ian
