On Thu, Apr 21, 2011 at 02:59:27PM -0400, John Baker wrote:
> There are several ways to make this work right including virtual aliases
> but the cleanest way seemed to me to be a per user transport map lookups
> for cloud users.
I think that per-user transport lookups are unwise.
- Map each user's primary email address to a "mailbox" address
for delivery.
- Use a different "mailbox domain" for different hosting environments.
- If absolutely necessary (the destination only supports the primary
address), reverse the mapping via smtp_generic_maps in the master.cf
entry for the transport feeding the problem destination.
> But we only have two possible final destinations and don't
> want to end up with really large transport tables on different servers.
Your per-user primary -> mailbox tables will be identical everywhere. The
transport mappings for the various "mailbox domains" may need to be
server-specific in some cases, but often do not. All each server needs to
know is which if any of the domains in question are its responsibility
(mydestination or virtual_mailbox_domains) and which are remote
(relay_domains). Then just define "relay_transport" and "virtual_transport"
appropriately.
> We
> also split our local and external smtp to reduce spam scan related
> congestion so the next hop to the cloud is different depending in where the
> mail is coming from. So I wanted a way to do one simple ldap look up that
> would mean something different depending on the server.
Being too clever is often not a good idea, instead deploy the appropriate
table definition to the appropriate nodes.
> query_filter = (uid=%u)
> result_attribute = mailHost
> result_format = smtp:[%s]
This can be a transport table for remote users, provided local users
never have "mailHost" set, but this fails badly when the same LDAP data
needs to work on the mailHost machine.
> This seems to work great on my test server. If the query filter is true it
> delivers it to the next hop in the result_format and goes on to the domain
> defaults in my regular transport file if not. I like this a lot because it
> is very simple and uses an ldap attribute that can be multipurpose and the
> same for every cloud user or mail server.
>
> But as this seemed like an unintended use of result_format I wanted to be
> sure that it won't cause any side effects before I put it into production.
Fixed result formats are intentionally supported.
Fixed "query_filter" values generate a warning that you probably are
not doing the right thing.
--
Viktor.
