On Thu, Jul 24, 2008 at 08:10:40PM +0200, mouss wrote:
> >It is not obious how proxy_read_maps will cove to have the right value
> >when people use custom tables. I don't know that it is safe to allow
> >proxymap() to be "promiscuous" and allow any table to be opened.
> >
>
> I meant something like
>
> dont_proxy_maps =
> ldap:/this/one
> mysql:/that/one
> ...
>
> this would not allow one to use the same map with and without proxy
> depending on context (where it is used), but I don't think there is a
> real use case for such thing.
This does not address the problem of giving proxymap a complete list
of maps that clients are allowed to query.
This still leaves (the internal API) problem of designating map types to
auto-proxy, and clients that want to suppress this. Note, with:
virtual_mailbox_maps = proxy:ldap:...
the virtual(8) daemon uses an unproxied table, while smtpd(8) doing
recipient validation, uses a proxied table. If "ldap:" is automatically
proxied at the dict_open() layer, virtual(8) needs to pass new flags
to turn this off...
The complexity is quite high, for 2.6 at least, I think it is best to
not start along this path. If the dictionary interface is redesigned
for a hypothetical 3.x release-train, with composite and chained tables,
... lots of other bells/whistles, perhaps then proxying could become more
transparent... The configuration would also need to be more centralized,
with proxymap "knowing" what tables all the other services are configured
to use. This is essentially a new MTA, that looks a lot like Postfix,
but is a signficant rewrite.
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:[EMAIL PROTECTED]>
If my response solves your problem, the best way to thank me is to not
send an "it worked, thanks" follow-up. If you must respond, please put
"It worked, thanks" in the "Subject" so I can delete these quickly.
