Wietse Venema: > 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.
This can also be used to implement unequal preferences, by listing an IP address multiple times. Postfix will by default randomly shuffle the address list. > - Using MX lookups, and multiple MX records per name? This would > make sense if some hosts are more preferred than others. This requires some SMTP client code duplication. because MX lookups are not part of the LMTP protocol spec. > - Using smtp_fallback_relay? I don't know if that would be applicable > for LMTP-based storage access. This also requires some some SMTP client code duplication. > All three scenarios could take advantage of Postfix connection > caching to avoid wasting time on dead hosts. > > Wietse >
