Am 20.11.2014 um 09:10 schrieb Michael Ströder:
li...@rhsoft.net wrote:
but LDAP is a very limited database missing things like joins, views and a lot
of other things you can easily do with a SQL query
While you're right you don't recommend using joins for productive use, do you?
surely - if i work only with a flat table i don't need SQL at all
CREATE ALGORITHM=UNDEFINED DEFINER=`root`@`localhost` SQL SECURITY
DEFINER VIEW `dbma_recipients` AS select `dbmail_aliases`.`alias` AS
`alias` from `dbmail_aliases` where (not((`dbmail_aliases`.`alias` like
'%@'))) union (select concat('@',`dbma_mta`.`mydestination`) AS `alias`
from `dbma_mta` where (`dbma_mta`.`transport` <>
'dbmail-lmtp:127.0.0.1:24')) union (select
`dbma_recipient_relay`.`mydestination` AS `alias` from
`dbma_recipient_relay`) union (select `dbma_aliases_global`.`alias` AS
`alias` from `dbma_aliases_global`)
- don't blame the messenger
and just setup a wrapper fetching the data from LDAP and present them in a SQL
database for postfix
Hmm, wouldn't it be better to sync the data with a local DB then?
In this case you could transform the data in any lookup form needed which
should get much better performance.
depends what you want to achieve
our inbound MX has hash-tables re-created on demand every 5 minutes from
the sql databases, the backend servers just use happily views, joins and
a lot of SQL
so the views above are only part of the game for the 5% messages making
it through the first server
did something similar recently for a inbound mail-gateway by fetching data
from a infinite count of final destination servers each with it's own mysql
configuration and present them on the gateway server including the transport
table with the target machines
that's finally a cronjob running every 5 minutes - such data don't change
every second
Hmm, running a CRON job every 5 minutes which does almost nothing is a waste
of resources when data sets are big.
on a machine running SpamAssassin and ClamAV that "waste of ressources"
is meaningless
In case of OpenLDAP as data source one could write a syncrepl client.
Food for thought:
Following DN reference attributes with additional LDAP lookups is not very
performant either. With OpenLDAP's slapo-deref postfix could use the deref
extended control [1] to fetch referenced entries with one query
