On Mon, Mar 07, 2022 at 07:05:53PM -0500, Alex wrote:
> > Replace "reject_non_fqdn_helo_hostname" with:
> >
> > main.cf:
> > pcre = pcre:${config_directory}/
> >
> > # In the client, helo, sender or recipient restriction list
> > smtpd_..._restrictions =
> > ...
> > check_helo_access ${pcre}non-fdqn-helo.pcre
> > ...
> >
> > non-fdqn-helo.pcre:
> > /^cp4435$/ DUNNO
> > /^/ reject_non_fqdn_helo_hostname
>
> Okay, very interesting. I hadn't realized I could add commands to
> files referenced in restrictions.
Yes, anything that does not involve new table lookups can appear in the
RHS "action" of a table lookup.
> But I still want to leave the reject_invalid_helo_hostname parameter?
You are quite confused here, the above rejects invalid HELO names
whenever the name is not "cop4435", exactly as you asked, by using
"reject_invalid_helo_hostname". So either you want to exempt that
domain or you don't. Elementary logic says you get to choose exactly
one of these alternatives.
> I've now added the check_helo_access to smtpd_recipient_restrictions
> and smtpd_helo_restrictions,
Just once is enough.
> but do I really need smtpd_helo_restrictions if I'm also adding them
> to smtpd_recipient_restrictions?
Not necessarily. Only if you want to apply further restrictions, in the
next built-in class after short-circuiting one of the built-in classes
with "OK". The built-in restrction classes are:
- client
- helo
- sender
- recipient
- data
- end_of_data
With the strongly recommended default of "smtpd_delay_reject = yes", A
recipient is rejected if any of the first four fail, with success in the
first three still subject to further checks in the remaining one(s).
The "data" and "end_of_data" restrictions apply to the message as a
whole.
--
Viktor.
