Re: tcp_table and propose for new lookup table 'pipe_table'

2 msg	MASQUERADING FROM BUT NOT TO
3 msg	Probably not a Postfix problem...?
3 msg	Quick question with user/virtual aliases.
4 msg	Sending healty batch emails
5 msg	use of relayhost, relaydomain?
6 msg	naming the mail server
1 msg	Re: statistics by client ip address - SOLVED
3 msg	question marks on permissions/owner
2 msg	Configuring Postfix to Receive Mail from Outloo...

tcp_table and propose for new lookup table 'pip...
\ Davi Baldin (14 Mar 2008)
. \ (Wietse Venema) (14 Mar 2008)
. \ mouss (14 Mar 2008)

12 msg	About date spoofing
3 msg	Overriding DNS lookups for a specific domain
2 msg	redirecting a single email address/alias (not a...
1 msg	statistics by client ip address
2 msg	sender+ip restrictions
14 msg	postfix-2.5 RPMs available
1 msg	Setting up Postfix on Solaris 10
8 msg	Yet another virtual domain problem - do not lis...
2 msg	getting a user permissions error
2 msg	551 mail refused

Subject:	Re: tcp_table and propose for new lookup table 'pipe_table'
Group:	Postfix-users
From:	mouss
Date:	14 Mar 2008

Davi Baldin wrote:
> Postfix list,
>
> I'm responsible to implement dozens new postfix servers year by year,
> that's need LDAP integration over many directory services. But today, I use
> custom perl scripts into crontab to read users attributes and build sender
> and recipient restrictions hash maps for lookup. But for simple LDAP
> servers I can run without the "script", using the simple LDAP database
> lookup.
>
> Now I think it's time to leave de script+cron and use some complex lookup
> map. My fight today is mapping user address and permission based on
> directory structure like this:
>
> a) If use has member of some group like "Internal mail user", the user
> cannot receive and sent mail to non local domains;
>

search for local_only.
> b) If mail is sent to address designated to a group into directory, the
> virutal lookup need to map the address for all users inside this group;
>

virtual_alias_maps?
> c) If the user exists into some OU, the restrictions applied for this OU,
> need to be recursive to the user, like permissions for sent inside/outside
> users;
>

just call a check that returns OU restrictions for a user.
> d) If the use exists into some OU or domain, the final SMTP server for this
> user need to be calculated from an entry inside cn=Configuration,dc=domain
> (like this);
>

use a map that returns the transport based on the OU or domain.
something like

transport_maps =
ldap:/etc/postfix/ldap/transport_per_user
ldap:/etc/postfix/ldap/transport_per_ou
ldap:/etc/postfix/ldap/transport_per_domain

as usual, first match wins.
> d) etc etc.
>
> Many configurations I can do by the ldap_table, but the conditional and
> recursive way its bit difficult or impossible. The tcp_table maybe the
> answer for this challenge but it's not part from the production postfix
> release, and if I use many ldap_table lookup in heavy smtp servers, the
> LDAP server become a bottleneck for performance because the latency for
> queries grow very fast.
>
> MY QUESTION:
>
> It's possible the tcp_table become part of production release version? I
> think to use then for localhost daemons, that's act a proxy for LDAP
> queries and implement my conditional result.
>
> It's interesting create new lookup table that's query some program (like an
> script) and read the STDOUT as result for lookup? With this "pipe_table", I
> can configure wherever we need to lookup and the result become a response
> for the lookup key.
>
> What you think about these two ways?
>