Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Ronald F. Guilmette (rfgtristatelogic.com)
Date: Sat Aug 23 2008 - 14:44:37 CDT
In message <48AFE865.4060503jpkessler.info>,
"Jan P. Kessler" <postfixjpkessler.info> wrote:
>Noel Jones schrieb:
>> Ronald F. Guilmette wrote:
>>> It's easy enough to just pass a copy of $mynetworks to an external
>>> server, e.g. via the command line argv.
>This won't work for policy servers which are not called by postfix
>spawn. Maybe it'd be better to exec "postconf mynetworks".
Hay! I like that solution! Thanks.
>Anyway - all of these approaches like parsing main.cf or calling
>"postconf mynetworks" suffer from difficulties in multi instance setups.
>And in any case there's a lot of overhead to compute things (fopen, cidr
>compare, ...), which have already been determined by postfix. So, I'd
>agree to say that sth like 'client_within_mynetworks=(yes/no)' could be
>a useful extension to the policy delegation protocol.
Well, it did seem to me that it definitely wouldn't hurt. But then
Wietse pointed out that it might, e.g. because implementing that might
start to drag in lots and lots of other requests for other Postfix
configuration parameters to be passed via the protocol too. (And he
might be right about that. I don't really know.)
>smtpd_*_restrictions like tls-* oder sasl_* values are already reflected
>by attributes, which allows to use them in a very efficient way - why
>not follow the same logic for mynetworks?