Quanah Gibson-Mount:
> As part of making Zimbra more robust, we're abstracting our data layer.
> Currently, LMTP delivery is configured to point at a specific mailstore,
> which accepts delivery and stores the email in a SQL database. As part of
> the abstraction, we're moving to a SQL cluster, which means that LMTP
> delivery can be to any mailstore for any user. The general idea is that
> there should be no dependency on any given mailstore for the system to
> function.
>
> However, postfix LMTP seems to only take a single destination address
> (please correct me if I'm wrong. ;) ). A possible solution we've
> considered is requiring a load balancer be deployed between postfix and the
> mailstores. Another potential solution would be if postfix could take a
> list of LMTP destinations and failover between them, similarly to what is
> done with LDAP URLs. Other thoughts welcome.
The Postfix scheduler does not do lists of destinations, and I am
not inclined to change that for LMTP.
Before inventing new lookup mechanisms, have you considered the
possibility of making the existing mechanisms available for LMTP?
- Using multiple A records per name? If all hosts are equivalent
that would be the way to go.
- Using MX lookups, and multiple MX records per name? This would
make sense if some hosts are more preferred than others.
- Using smtp_fallback_relay? I don't know if that would be applicable
for LMTP-based storage access.
All three scenarios could take advantage of Postfix connection
caching to avoid wasting time on dead hosts.
Wietse
