Results 1 to 10 of 10

Thread: Modifying the Zimbra Postfix Configuration

  1. #1
    Bevan Bennett is offline Active Member
    Join Date
    May 2007
    Location
    Los Angeles, CA
    Posts
    31
    Rep Power
    8

    Default 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
    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 )
    Then add it to the MAY section of zimbraMailRecipient.

    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.
    Last edited by Bevan Bennett; 08-22-2007 at 10:16 AM.

  2. #2
    Bevan Bennett is offline Active Member
    Join Date
    May 2007
    Location
    Los Angeles, CA
    Posts
    31
    Rep Power
    8

    Default

    I know other people either know something about this or have similar questions because I've seen their posts... and some of these should be really easy to answer...

    I've initiated a Support Ticket to request answers, because this is now blocking my install from going live.

  3. #3
    fajarpri's Avatar
    fajarpri is offline Loyal Member
    Join Date
    Jul 2007
    Posts
    98
    Rep Power
    8

    Default

    Does anyone know how to answer question #3?
    I need to reject mail to unknown recipients too.
    Thank you.

  4. #4
    fajarpri's Avatar
    fajarpri is offline Loyal Member
    Join Date
    Jul 2007
    Posts
    98
    Rep Power
    8

    Default

    Sorry, replying to myself.
    Edit zmmta.cf, and change POSTCONF smtpd_reject_unlisted_recipient no to 'yes'. Reload postfix.

  5. #5
    sander is offline Junior Member
    Join Date
    Dec 2008
    Location
    Gothenburg, Sweden
    Posts
    8
    Rep Power
    6

    Default Regarding q2

    I want to rewrite an incomming e-mail address and thus have to change the sender_canonical_map according like this:

    create:
    /opt/zimbra/conf/postfix_sendermap (syntax gammal@domän ny@domän)
    rebuild db (if changed):
    /home/opt/zimbra/postfix-2.4.3.4z/sbin/postmap /opt/zimbra/conf/postfix_sendermap
    alter postfix config sender rewrite:
    /home/opt/zimbra/postfix-2.4.3.4z/sbin/postconf -e sender_canonical_maps=hash:/opt/zimbra/conf/postfix_sendermap,ldap:/opt/zimbra/conf/ldap-scm.cf
    apply on all incomming mail:
    /home/opt/zimbra/postfix-2.4.3.4z/sbin/postconf -e local_header_rewrite_clients=static:all


    this works great until postfix reload is run, or zimbra restarts - then the zmmta.cf entry for sender_canonial_maps overwrites my custom value.

    So my questin is. What does the line in zmmta.cf actually do - where does it find the "LOCAL" value? Can i just remove this row from zmmta.cf (is there a way to just comment it out?) or should i rewrite the line to append my custom string and keep the "LOCAL" setting?

  6. #6
    sander is offline Junior Member
    Join Date
    Dec 2008
    Location
    Gothenburg, Sweden
    Posts
    8
    Rep Power
    6

    Default

    after upgrading to 5.0.11 we are still experiencing the problem with the settings beeing reset... What is the correct way to make modifications to the postfix configuration?

  7. #7
    BernyB is offline Member
    Join Date
    Jan 2009
    Location
    Italy
    Posts
    10
    Rep Power
    6

    Default

    I have the same issue trying to use the return receipt zimlet. When following the guidelines at Adding a disclaimer (altermime) or footer - Zimbra :: Wiki my /opt/zimbra/postfix/conf/master.cf file is always overwritten, both with zmmtactl and zmcontrol. Any suggestion?

    Edit: after 5.0.12 the right file to change is .cf.in and not .cf: the relevant page should be updated as suggested in the discussion page.
    Last edited by BernyB; 02-05-2009 at 05:36 AM.

  8. #8
    phoenix is online now Zimbra Consultant & Moderator
    Join Date
    Sep 2005
    Location
    Vannes, France
    Posts
    23,492
    Rep Power
    56

    Default

    Quote Originally Posted by BernyB View Post
    Edit: after 5.0.12 the right file to change is .cf.ini and not .cf: the relevant page should be updated as suggested in the discussion page.
    The correct file is:

    /opt/zimbra/postfix/conf/master.cf.in
    Regards


    Bill


    Acompli: A new adventure for Co-Founder KevinH.

  9. #9
    BernyB is offline Member
    Join Date
    Jan 2009
    Location
    Italy
    Posts
    10
    Rep Power
    6

    Default

    Yes of course :-) I corrected the post above.

  10. #10
    phoenix is online now Zimbra Consultant & Moderator
    Join Date
    Sep 2005
    Location
    Vannes, France
    Posts
    23,492
    Rep Power
    56

    Default

    Quote Originally Posted by BernyB View Post
    Yes of course :-) I corrected the post above.
    I know you knew that, my post was just for posterity.

    Just for clarification, if you see any configuration files in Zimbra that end in .in then that means: a) they would be the ones to modify and b) they will get regenerated by Zimbra on a regular basis.
    Regards


    Bill


    Acompli: A new adventure for Co-Founder KevinH.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. QUE Failure
    By tbullock in forum Administrators
    Replies: 31
    Last Post: 07-30-2008, 12:17 PM
  2. Can't start Zimbra!
    By zibra in forum Administrators
    Replies: 5
    Last Post: 03-22-2007, 11:34 AM
  3. Replies: 16
    Last Post: 09-07-2006, 06:39 AM
  4. Seeming variety of problems on suse-9.1
    By Crexis in forum Installation
    Replies: 52
    Last Post: 03-04-2006, 12:19 AM
  5. Monitoring : Data not yet avalaible
    By s3nz3x in forum Installation
    Replies: 7
    Last Post: 11-30-2005, 07:18 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •