(This turned out not to be how I fixed it. I just configured exim and /etc/mailname as I do always and that fixed it. However, exim does not run as the SMTP server listening on port 25, that is the postfix installed by Zimbra. I don’t know how and if this exim configuration conflicts with zimbra.)
I have a zimbra server fooled into thinking it hosts a particular domain. Part of the fooling involves setting a different SMTP server than localhost for all outgoing mail. Luckily, Zimbra can do that.
The downside of that is that when you send mail to “root”, the other SMTP server qualifies it with its domain and the mail appears to be coming from the wrong server.
To fix it, specify this in the /opt/zimbra/postfix/conf/main.cf:
myorigin = example.com
This seems to work without caveats. However, I don’t know if zimbra overwrites this config file at some point.
As always, pick a domain that exists, otherwise a lot of mailservers won’t accept it. You don’t even need an MX record, A or CNAME if enough.
Zimbra learns ham and spam by sending it to certain mailboxes. For our setup, this doesn’t work (easily), because our server is configured to always send mail to another SMTP server and not do any local delivery. I did that, because our zimbra server is not actually on the domain it thinks.
To disable the learning accounts, I did this:
zmprov mcf zimbraSpamIsSpamAccount ''
zmprov mcf zimbraSpamIsNotSpamAccount ''
I didn’t delete the accounts, so I can enable it later.
To enable it, I guess I have to configure these two accounts on our hosting provider’s servers, fetch and deliver them to Zimbra and it works. I’ll do that some time…
When configuring an LDAP addressbook, one thing that has given me a lot of trouble, is the LDAP filter. Here are two I use.
In Zimbra, I had to configure our ruby-ldapserver to never return more than 50 results, because in the configuration panel, it runs a test based on a search query which goes fine, but it does another query with the %s literally repeated. This causes the SQL condition that is generated to be %s% and that gives a whole lot of results, hanging Zimbra. It is beyond me why Zimbra runs this second query, but I guess it’s a bug.