LinkBack URL
About LinkBacks
Modifying the Zimbra Postfix Configuration
I'm working on preparing a Zimbra deployment, and I want to make some modifications to the postfix configuration, but I'm a little confused by the Zimbra-introduced indirection.
I understand postfix and am comfortable with it's configuration file, but want to make sure I don't break it's close ties to zimbra. Most of these questions will, no doubt, turn out to be fairly simple and straightforward, but if they get answered here maybe they'll help other people in the future...
Question 1:
ZIMBRA_HOME/postfix/conf/aliases appears to contain the 'main' aliases separate from any account or distribution list aliases I create. Can this file be directly edited or is Zimbra controlling it from somewhere else? Does zimbra even look at this file? It looks like Zimbra configures postfix with 'alias_maps = hash:/etc/aliases' by default, so it ends up pointing over to /etc/aliases rather than /opt/zimbra/postfix/conf/aliases, but then that file -could- be manually edited to contain whatever extra fixed aliases I need.
Specifically, I have a bug-tracking system with an email interface that needs to be hooked up with alias entries like:
report-bug: "|/usr/data/bugmail.pl BugDatabase"
Answer 1
Zimbra doesn't care about the contents of that file, so you should be able to modify it manually without any side effects.
Question 2:
It looks like postscript is predominantly configured via zimbra internal variables through ZIMBRA_HOME/conf/zmmta.cf's mta section.
We currently use a canonical map to force the following mappings:
/^(\w+)@internal\.example\.com/ $1@real-example.com
/^(\w+)@\w+\.internal\.example\.com/ $1@real-example.com
Zimbra has sender_canonical_maps set (to an LDAP query) which appears to be set by
POSTCONF sender_canonical_maps LOCAL postfix_sender_canonical_maps
in zmmta.cf and
in localconfig.xml
Since zmmta.cf doesn't use "canonical_maps", would the correct answer be:
A) Just add a canonical_maps entry and file to postfix/main.cf like we used to have (and let Zimbra remain unaware of what's going on.)
B) Add a new key to localconfig.xml "postfix_canonical_maps", a new entry to zmmta.cf and a new file such that zimbra creates a main.cf that looks like the one I would have created in step A.
C) Use some internal zimbra method to achieve the same results that I've missed.
Answer 2
See the "Domain Forwarding" and "Domain Masquerading" sections of Managing Domains in the Wiki. They should do what you're trying to accomplish without any postfix hacking.
[I was leery of zimbraMailCatchAllCanonicalAddress in this context, but it does appear to be the answer.]
Question 3:
In a similar vein, we currently only accept SMTP connections for valid recipients (this cuts down on a -lot- of spam processing). We do this by setting "local_recipient_maps" to our alias files and user lookup. This is also how the postfix default main.cf does things, but zimbra doesn't appear to use the local_recipient_maps variable at all.
Is there a proper Zimbra way to enable this functionality?
Will Zimbra get upset if I add the following to postfix/main.cf?
local_recipient_maps= ldap:/opt/zimbra/conf/ldap-vam.cf,$alias_maps
Would this be sufficient or would I need a new ldap search in order to return the list of valid LDAP-stored recipients?
Is "virtual_alias_maps" somehow already supposed to be performing this functionality?
Answer 3:
Edit zmmta.cf, and change POSTCONF smtpd_reject_unlisted_recipient no to 'yes'. Reload postfix.
(Thanks fajarpri!)
Question 4:
As a modification to the above to keep our large company aliases from collecting spam, we eventually created two alias lists "aliases" and "aliases-internal", the latter containing aliases that are for internal use only.
In main.cf we then have:
alias_maps = hash:/etc/postfix/aliases, hash:/etc/postfix/aliases-internal
ext_alias_maps = hash:/etc/postfix/aliases
and in master.cf we modify the configuration of the "public" listening smtp process by replacing $alias_maps with $ext_alias_maps in local_recipient_maps.
With number 3 answered this shouldn't be an issue, although I'd like to implement it by adding to the zimbra LDAP schema... something like
Then add it to the MAY section of zimbraMailRecipient.Code:objectIdentifier zimbraKeepEmailPrivate ZimbraAttrType:503 attributetype ( zimbraKeepEmailPrivate NAME ( 'zimbraKeepEmailPrivate' ) DESC 'Disallow external users from sending to this address' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 EQUALITY booleanMatch SINGLE-VALUE )
Could someone there set aside an OID for me to play with enabling this so I don't run into trouble with future updates? If not I can assign one of my company OIDs, but that will make it weird if you wanted to merge in the future.
Then we create a modified version of the LDAP query that solves #3 that includes &((ORIGINAL_QUERY)(zimbraKeepEmailPrivate!=true)) and use that instead of the original on the public smtp interface. Anything without this attribute is still considered public (like it is now) for backwards compatibility. Eventually a checkbox could be added to the GUI for setting this, or we can do it by hand for the lists we want it for.
Question 5:
zmmta.cf doesn't appear to control postfix/conf/master.conf... can we hand edit this file to:
* Add additional interfaces to listen on?
* Turn on listening on the "submission" port?
* Make the public/private split described in #4?
If it can't be hand-edited, where is it controlled from and what's the approved way to modify it?
Answer 5
You can edit master.cf by hand. You'll need to watch out when upgrades happen, because the file can be overwritten by the upgrade, so you'll want to back up your copy and merge it back in along with any changes that have been introduced by the upgrade.
Question 6:
I know shared folders are "coming soon", but I have a large number of them currently in use. I'm thinking my best migration path is as follows, does anyone have experiences with this or an alternative?
1) Create a distribution list for each shared folder with the existing name.
2) Create a 'user' for each shared folder named 'listname-user'.
3) Migrate existing emails to listname-user's INBOX
4) Add current real users with access and listname-user to the distribution list.
5) Run Zimbra for the forseeable future, users get shared messages directly and have to deal with them... listname-user serves as an archive.
6) When shared folder support comes out, remove the distribution list, change the user to listname and share INBOX to the real users with access.
Answer 6
I don't know of other customers that are doing what you describe, but it sounds like a reasonable path to having things ready to go when full folder sharing comes out. Just FYI, we do have shared folders implemented on our in-house mail server, and are working through the usability bugs with it now. It's not going to be too far out.
Originally Posted by BernyB 
