On 9/18/2013 4:27 AM, Emmanuel Fusté wrote:
> Le 18/09/2013 05:40, Viktor Dukhovni a écrit :
>> On Wed, Sep 18, 2013 at 01:00:48PM +1000, li...@sbt.net.au wrote:
>>
>>> Return-Path: <bayedfresc...@reuters.com>
>>> ...
>>> Received: from p2p (unknown [124.11.170.87])
>>> by geko.domain.tld (Postfix) with SMTP id 9E40A3827C6
>>> for <vvv...@domain.tld>; Wed, 18 Sep 2013 08:13:25 +1000 (EST)
>> Everything below this Received header is fiction. The EHLO name
>> is not an FQDN and the IP address does not have matching forward
>> and reverse addresses.
>>
>> You could try:
>>
>> main.cf:
>> # Preferred RE map type:
>> RE = pcre:${config_directory}/
>>
>> # HELO restrictions for remote clients
>> smtpd_helo_required = yes
>> smtpd_helo_restrictions =
>> permit_mynetworks,
>> permit_sasl_authenticated,
>> check_helo_access ${RE}helo.re
>>
>> helo.re
>> # Clients with non-fqdn HELO names MUST have working FCrDNS
>> /^[^.]*$/ reject_unknown_client_hostname
>>
>>
>> [...]
> Hello Viktor,
>
> In an "access" table, could I use any postfix "reject_xxx" and
> "permit_xxx" directive ?
> I did not find it in the documentation. It could be very powerfull.
It's mentioned, sparsely, in access(5):
OTHER ACTIONS
restriction...
Apply the named UCE restriction(s) (permit, reject,
reject_unauth_destination, and so on).
No, you cannot use "any" restriction. You must use only those that
apply to the context of the check_foo_access restriction which targets
the table. However, if you think clearly about this for a moment,
you'll realize that these nested restrictions using tables are
completely unnecessary.
What Viktor is doing here is suggesting a workaround using a barely
documented trick in an effort to make something work which should
already be working, but is not. I already stated what I believe the
problem is and the simple solution. Just because you're seeing
something used in a way you didn't previously know was possible does not
mean it is powerful, nor something you should try to imitate. And in
fact trying to use this will very likely only cause you additional
problems, while solving none.
--
Stan
