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.
>>>> listen on egress inet4 port 25 \
>>>> tls pki darwinsys.com \
>>>> filter { check_dyndns, check_rdns, rspamd } \
>>>> tag INCOMING
>>>> listen on egress port submission \
>>>> filter { check_dyndns, check_rdns, rspamd } \
>>>> tls-require pki darwinsys.com \
>>>> auth tag AUTH
>>>>> TIA if anyone can help.
>>>> You need to share more than the listen lines.
>>>> You have omitted the check_rdns filter definition which is where we could
>>>> plug a bypass...
>>> Ah, my bad. Here are all the filter def'ns, right out of somebody's blog :-)
>>> filter check_dyndns phase connect match rdns regex { '.*\.dyn\..*',
>>> '*\.dsl\..*' } \
>>> disconnect "550 no residential connections"
>>> filter check_rdns phase connect match !rdns \
>>> disconnect "550 no rDNS is so 80s"
>>> filter check_fcrdns phase connect match !fcrdns \
>>> disconnect "550 no FCrDNS is so 80s"
>>> filter "rspamd" proc-exec "filter-rspamd"
>> 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"
>> b- if you don't know their IP address, you can use the same logic but you
>> hook a later phase so the session has more informations:
>> filter check_fcrdns_bypass phase mail-from match mail-from <sometable> bypass
>> filter check_fcrdns phase mail-from match !fcrdns \
>> disconnect "550 no FCrDNS is so 80s"
>> maybe you can compact them in a single rule with multiple criterias, along
>> the lines of:
>> filter check_fcrdns phase mail-from match !mail-from <foo> !fcrdns \
>> disconnect "550 no FCrDNS is so 80s"
>> it probably works but it's late and I'm tired so maybe not.
> Great, thanks for the reply! I'll try it in the morning :-)
>
> And just to clarify, in "match !mail-from <foo> !fcrdns" i.e., any match with
> multiple conditions,
> are they ANDed or ORed? The man page is vague:
>
> match options action name If at least one mail envelope matches the options
> of one match action
> directive,
>
They are ANDed, like match rules, it is the only way rules can be unambiguous.
