Quanah Gibson-Mount:
> I've been running into a really odd (bizarre) problem with Postfix that
> only seems to happen on Mac OSX 10.5 (leopard). I'm really at a loss to
> explain why things break the way they do, but it definitely happens. I
> thought maybe some folks on the list might have some insight.
>
> Here is the scenario: Client installs Zimbra on their server. Zimbra has
> its own Postfix build that it installs, with its own spool directory
> (/opt/zimbra/data/postfix/spool) and its own configuration files
> (/opt/zimbra/postfix/conf) etc. All the configuration files we ship only
> refer to our locations. When ZCS is up and running, everything on the
> system uses our postfix.
>
> Now, what we've seen is that if ZCS is not up and running and the ZCS user
> (zimbra) is not in existence, then the OSX Leopard box will fall back to
> its local postfix, which of course puts files in /var/spool/postfix. This
> in and of itself is not really a problem. The problem is, that once ZCS is
> back up and running, if there are files in /var/spool/postfix, eventually
> proxymap will stop being able to talk to the LDAP server:
>
> Feb 19 03:22:32 mx1 postfix/proxymap[53103]: error: dict_ldap_connect:
> Unable to set STARTTLS: -1: Can't contact LDAP server
>
> Removing the files from /var/spool/postfix makes this stop happening. I
> can't for the world think of why files existing in /var/spool/postfix would
> have any effect on our postfix which has no knowledge of that location, but
> cleaning out /var/spool/postfix always resolves the issue.
Speculation: as long as the MacOSX Postfix queue is not empty, some
bits and pieces of MacOSX Postfix will keep running and occupy some
resource that your Postfix would otherwise have provided.
> Anyone have an insight into why? Postfix version is 2.4.7.
This is really a platform-specific question, that can be answered
only by people who have access to the affected OS.
Wietse
