On Wed, Apr 10, 2013 at 07:55:53AM -0700, Quanah Gibson-Mount wrote:
> >This said, I would take a different approach:
> ...
>
> Thanks Viktor, this looks interesting.
>
> I'm assuming I can do all of this via LDAP rather than flat files?
Why do you need to assume? All examples using indexed files are
a mechanism to demonstrate the required table contents. You should
know by now that all tables are logically equivalent provided they
return the same results for the same lookup keys.
> We have customers with thousands of domains, and number of which may
> be aliases for various of the defined domains, which is why we query
> all of this information from LDAP. Any solution that requires using
> flat files is a nonstarter.
This said, not all tables are operationally equivalent. All the
hoops jumped in my preferred configuration are designed to avoid
having an LDAP *transport* table. The transport table should
ideally be small, static and "indexed" (generated as a CDB or
similar local database in a file).
By rewriting users to mailstore-specific mailbox addresses, you
at most need transport table entries for each mail store, not
for each user. You can even do away with per-mailstore transport
entries if you set:
virtual_transport = lmtp
# Adjust if necessary
lmtp_tcp_port = 24
and ensure that all the mailstore-specific domain-parts resolve
in DNS. To that end you can rewrite users to:
lu...@example.com lu...@imap1.example.com
lus...@example.com lus...@imap2.example.com
...
and avoid the "invalid" TLD if that's preferred. You can still
disallow remote injection directly into the server domains, by
various mechanisms (mostly make sure to not include them in
relay_domains via parent_domain_matches_subdomains).
Lots of ways to skin this cat... I am not a fan of LDAP with
transport_maps, since this impacts queue-manager reliability
and performance. Also rewriting is more robust against loops.
Where-as forwarding the same address around based on transport
tables risks inconsistent configuration leading to loops.
If the per-user transport end-point is LMTP, the loop issue is
less of a concern, since LMTP servers are not expected to ever
forward mail.
--
Viktor.
