Loading ...
Sorry, an error occurred while loading the content.

Re: Setting up virtual domains correctly

Expand Messages
  • btb@...
    ... likely, the reason this works is because virtual_transport is never being used, if actual delivery for every recipient is passed off somewhere else via
    Message 1 of 8 , Apr 9, 2013
    • 0 Attachment
      On Apr 9, 2013, at 19.56, Quanah Gibson-Mount <quanah@...> wrote:

      > I'm trying to fix my virtual domain configuration with postfix, which as noted in a prior discussion was done incorrectly by some unknown to me person in the past.
      >
      > The main issue right now is that it has:
      >
      > virtual_transport = error
      >
      > which I was told makes little sense, so I'm trying to correct our configuration.
      >
      > First, all of our data is stored in LDAP (domains, users, etc). For my test setup, the "real" domain is zre-ldap002.eng.vmware.com. I've created a virtual (alias) domain "example.com".
      >
      > With my default configuration, if I send mail to user@... AND the user exists as user@..., mail delivery occurs.

      likely, the reason this "works" is because virtual_transport is never being used, if actual delivery for every recipient is passed off somewhere else via lmtp as you seem to perhaps indicate below.

      > postmap on my base transport works for this:
      > zimbra@zre-ldap002:~$ postmap -q user@... ldap:/opt/zimbra/conf/ldap-transport.cf
      > lmtp:zre-ldap002.eng.vmware.com:7025

      please supply postconf -nf and postconf -Mf, or if an older version, postconf -n and master.cf with comments removed.

      what is lmtp:zre-ldap002.eng.vmware.com:7025? if you're not actually doing delivery with the postfix virtual(8) lda, i'd suggest that using virtual at all doesn't really make much sense. instead, consider using the relay domain class.

      also, based solely on the attribute names, it's not quite clear to me what exactly is supposed to happen with various scenarios. that being said, using catchalls is rarely if ever a good idea. they will be abused, and at the very least, problematic.
    • Noel Jones
      ... virtual_transport is the default transport used by virtual_mailbox_domains. ... virtual_alias_domains are always (MUST be) rewritten to some other domain.
      Message 2 of 8 , Apr 9, 2013
      • 0 Attachment
        On 4/9/2013 6:56 PM, Quanah Gibson-Mount wrote:
        > I'm trying to fix my virtual domain configuration with postfix,
        > which as noted in a prior discussion was done incorrectly by some
        > unknown to me person in the past.
        >
        > The main issue right now is that it has:
        >
        > virtual_transport = error

        virtual_transport is the default transport used by
        virtual_mailbox_domains.


        >
        > which I was told makes little sense, so I'm trying to correct our
        > configuration.
        >
        > First, all of our data is stored in LDAP (domains, users, etc). For
        > my test setup, the "real" domain is zre-ldap002.eng.vmware.com.
        > I've created a virtual (alias) domain "example.com".

        virtual_alias_domains are always (MUST be) rewritten to some other
        domain. The transport used is controlled by the "real" domain. See
        ADDRESS_CLASS_README.



        >
        > With my default configuration, if I send mail to user@...
        > AND the user exists as user@..., mail
        > delivery occurs. However, I'm completely unclear as to what I should
        > be setting virtual_transport

        Looks as if virtual_transport isn't used in this setup. Either
        zre-ldap002.eng.vmware.com isn't in virtual_mailbox_domains, or you
        override the default.


        > to be that isn't error that will allow
        > delivery to occur. I've been reading over
        > <http://www.postfix.org/LDAP_README.html#example_virtual>, but it
        > assumes that you have matching user entries for every user in the
        > alias domain for LDAP lookups to work. What is just a base domain
        > entry:
        >
        > dn: dc=example,dc=com
        > zimbraDomainType: alias
        > zimbraMailCatchAllForwardingAddress: @...
        > zimbraDomainAliasTargetId: 4791b22a-9d9f-4a1b-b334-e3fd3244c561
        > zimbraDomainStatus: active
        > objectClass: dcObject
        > objectClass: organization
        > objectClass: zimbraDomain
        > objectClass: amavisAccount
        > zimbraId: 4e14bf2f-de63-4068-bb54-ee3327ad69b1
        > zimbraCreateTimestamp: 20130409230803Z
        > zimbraDomainName: example.com
        > zimbraMailStatus: enabled
        > zimbraMailCatchAllAddress: @...
        > o: example.com domain
        > dc: example
        >
        > The catchall domain (real domain) is stored in the
        > zimbraMailCatchAllForwardingAddress line.
        >
        >
        > The (real) user entry looks like:
        >
        > zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:// -D cn=config -w
        > zimbra -b "dc=zre-ldap002,dc=eng,dc=vmware,dc=com" uid=user
        > dn: uid=user,ou=people,dc=zre-ldap002,dc=eng,dc=vmware,dc=com
        > objectClass: inetOrgPerson
        > objectClass: zimbraAccount
        > objectClass: amavisAccount
        > zimbraId: 3f59de93-52d8-4f43-89cd-ecadd78e1929
        > zimbraCreateTimestamp: 20130409235225Z
        > zimbraAccountStatus: active
        > zimbraMailHost: zre-ldap002.eng.vmware.com
        > zimbraMailTransport: lmtp:zre-ldap002.eng.vmware.com:7025
        > zimbraMailStatus: enabled
        > zimbraMailDeliveryAddress: user@...
        > mail: user@...
        > cn: user
        > sn: user
        > uid: user
        > userPassword:: =
        > zimbraPasswordModifiedTime: 20130409235225Z
        >
        >
        > postmap on my base transport works for this:
        > zimbra@zre-ldap002:~$ postmap -q user@...
        > ldap:/opt/zimbra/conf/ldap-transport.cf
        > lmtp:zre-ldap002.eng.vmware.com:7025

        OK, this looks as if you're overriding the virtual_transport entry
        here. If all the zre-ldap002.eng.vmware.com users use the same
        endpoint, you can set
        virtual_transport = lmtp:zre-ldap002.eng.vmware.com:7025
        and get rid of the transport lookup.



        >
        >
        > However, I don't see a way to get postfix to understand it should
        > look for @... (from the
        > zimbraMailCatchAllForwardingAddress attribute) anytime it gets an
        > email for @... (from the zimbraMailCatchAllAddress
        > attribute), and then do the lookup as user@....
        >
        > Pointers *much* appreciated.

        Sorry, can't help with LDAP.



        -- Noel Jones

        >
        > Thanks!
        >
        >
        > --Quanah
        >
        >
        > --
        >
        > Quanah Gibson-Mount
        > Sr. Member of Technical Staff
        > Zimbra, Inc
        > A Division of VMware, Inc.
        > --------------------
        > Zimbra :: the leader in open source messaging and collaboration
      • Quanah Gibson-Mount
        ... Yes, delivery is to the server that actually hosts the mailbox for the user, via LMTP. ... postconf -nf: alias_maps = hash:/etc/aliases
        Message 3 of 8 , Apr 9, 2013
        • 0 Attachment
          --On Tuesday, April 09, 2013 8:18 PM -0400 btb@... wrote:

          > On Apr 9, 2013, at 19.56, Quanah Gibson-Mount <quanah@...> wrote:
          >
          >> I'm trying to fix my virtual domain configuration with postfix, which as
          >> noted in a prior discussion was done incorrectly by some unknown to me
          >> person in the past.
          >>
          >> The main issue right now is that it has:
          >>
          >> virtual_transport = error
          >>
          >> which I was told makes little sense, so I'm trying to correct our
          >> configuration.
          >>
          >> First, all of our data is stored in LDAP (domains, users, etc). For my
          >> test setup, the "real" domain is zre-ldap002.eng.vmware.com. I've
          >> created a virtual (alias) domain "example.com".
          >>
          >> With my default configuration, if I send mail to user@... AND
          >> the user exists as user@..., mail delivery occurs.
          >
          > likely, the reason this "works" is because virtual_transport is never
          > being used, if actual delivery for every recipient is passed off
          > somewhere else via lmtp as you seem to perhaps indicate below.

          Yes, delivery is to the server that actually hosts the mailbox for the
          user, via LMTP.

          >> postmap on my base transport works for this:
          >> zimbra@zre-ldap002:~$ postmap -q user@...
          >> ldap:/opt/zimbra/conf/ldap-transport.cf
          >> lmtp:zre-ldap002.eng.vmware.com:7025
          >
          > please supply postconf -nf and postconf -Mf, or if an older version,
          > postconf -n and master.cf with comments removed.

          postconf -nf:
          alias_maps = hash:/etc/aliases
          always_add_missing_headers = yes
          bounce_notice_recipient = postmaster
          bounce_queue_lifetime = 5d
          broken_sasl_auth_clients = yes
          command_directory = /opt/zimbra/postfix/sbin
          config_directory = /opt/zimbra/postfix-2.10.0.2z/conf
          content_filter = smtp-amavis:[127.0.0.1]:10024
          daemon_directory = /opt/zimbra/postfix/libexec
          delay_warning_time = 0h
          disable_dns_lookups = no
          header_checks =
          import_environment =
          in_flow_delay = 1s
          inet_protocols = ipv4
          lmtp_connection_cache_destinations =
          lmtp_connection_cache_time_limit = 4s
          lmtp_host_lookup = dns
          local_header_rewrite_clients = permit_mynetworks,permit_sasl_authenticated
          mail_owner = postfix
          mailbox_size_limit = 0
          mailq_path = /opt/zimbra/postfix/sbin/mailq
          manpage_directory = /opt/zimbra/postfix/man
          maximal_backoff_time = 4000s
          message_size_limit = 10240000
          minimal_backoff_time = 300s
          mydestination = localhost
          myhostname = zre-ldap002.eng.vmware.com
          mynetworks = 127.0.0.0/8 10.137.242.0/24 [::1]/128 [fc00:10:137:242::]/64
          [fe80::]/64
          newaliases_path = /opt/zimbra/postfix/sbin/newaliases
          non_smtpd_milters =
          notify_classes = resource,software
          propagate_unmatched_extensions = canonical
          queue_directory = /opt/zimbra/data/postfix/spool
          queue_run_delay = 300s
          recipient_delimiter =
          relayhost =
          sender_canonical_maps = proxy:ldap:/opt/zimbra/conf/ldap-scm.cf
          sendmail_path = /opt/zimbra/postfix/sbin/sendmail
          setgid_group = postdrop
          smtp_cname_overrides_servername = no
          smtp_fallback_relay =
          smtp_helo_name = $myhostname
          smtp_sasl_auth_enable = no
          smtp_sasl_mechanism_filter =
          smtp_sasl_password_maps =
          smtp_sasl_security_options = noplaintext,noanonymous
          smtp_tls_security_level = may
          smtpd_banner = $myhostname ESMTP $mail_name
          smtpd_client_restrictions = reject_unauth_pipelining
          smtpd_data_restrictions = reject_unauth_pipelining
          smtpd_end_of_data_restrictions =
          smtpd_helo_required = yes
          smtpd_milters =
          smtpd_recipient_restrictions = reject_non_fqdn_recipient,
          reject_unlisted_recipient, reject_invalid_helo_hostname,
          reject_non_fqdn_sender, permit
          smtpd_reject_unlisted_recipient = no
          smtpd_relay_restrictions = permit_sasl_authenticated, permit_mynetworks,
          reject_unauth_destination
          smtpd_sasl_auth_enable = yes
          smtpd_sasl_authenticated_header = no
          smtpd_sasl_security_options = noanonymous
          smtpd_sasl_tls_security_options = $smtpd_sasl_security_options
          smtpd_sender_restrictions = check_sender_access
          regexp:/opt/zimbra/postfix/conf/tag_as_originating.re,
          permit_mynetworks,
          permit_sasl_authenticated, permit_tls_clientcerts, check_sender_access
          regexp:/opt/zimbra/postfix/conf/tag_as_foreign.re
          smtpd_tls_auth_only = yes
          smtpd_tls_cert_file = /opt/zimbra/conf/smtpd.crt
          smtpd_tls_key_file = /opt/zimbra/conf/smtpd.key
          smtpd_tls_loglevel = 1
          smtpd_tls_security_level = may
          transport_maps = proxy:ldap:/opt/zimbra/conf/ldap-transport.cf
          virtual_alias_domains = proxy:ldap:/opt/zimbra/conf/ldap-vad.cf
          virtual_alias_expansion_limit = 10000
          virtual_alias_maps = proxy:ldap:/opt/zimbra/conf/ldap-vam.cf
          virtual_mailbox_domains = proxy:ldap:/opt/zimbra/conf/ldap-vmd.cf
          virtual_mailbox_maps = proxy:ldap:/opt/zimbra/conf/ldap-vmm.cf
          virtual_transport = proxy:ldap:/opt/zimbra/conf/ldap-vtransport.cf



          postconf -Mf
          smtp inet n - n - - smtpd
          -o content_filter=scan:[127.0.0.1]:10030
          465 inet n - n - - smtpd
          -o content_filter=scan:[127.0.0.1]:10030 -o smtpd_tls_wrappermode=yes
          -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=
          -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions=
          -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=
          -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
          -o syslog_name=postfix/smtps -o milter_macro_daemon_name=ORIGINATING
          submission inet n - n - - smtpd
          -o content_filter=scan:[127.0.0.1]:10030 -o
          smtpd_etrn_restrictions=reject
          -o smtpd_sasl_auth_enable=yes -o smtpd_tls_security_level=may
          -o smtpd_client_restrictions=permit_sasl_authenticated,reject
          -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions=
          -o smtpd_helo_restrictions= -o smtpd_recipient_restrictions=
          -o smtpd_relay_restrictions=permit_sasl_authenticated,reject
          -o syslog_name=postfix/submission -o
          milter_macro_daemon_name=ORIGINATING
          scan unix - - n - 10 smtp
          -o smtp_send_xforward_command=yes -o disable_mime_output_conversion=yes
          -o smtp_generic_maps=
          pickup unix n - n 60 1 pickup
          cleanup unix n - n - 0 cleanup
          qmgr unix n - n 300 1 qmgr
          tlsmgr unix - - n 1000? 1 tlsmgr
          rewrite unix - - n - - trivial-rewrite
          bounce unix - - n - 0 bounce
          defer unix - - n - 0 bounce
          trace unix - - n - 0 bounce
          verify unix - - n - 1 verify
          flush unix n - n 1000? 0 flush
          proxymap unix - - n - - proxymap
          smtp unix - - n - - smtp
          relay unix - - n - - smtp
          showq unix n - n - - showq
          error unix - - n - - error
          retry unix - - n - - error
          discard unix - - n - - discard
          local unix - n n - - local
          virtual unix - n n - - virtual
          lmtp unix - - n - - lmtp
          anvil unix - - n - 1 anvil
          scache unix - - n - 1 scache
          maildrop unix - n n - - pipe
          flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient}
          old-cyrus unix - n n - - pipe
          flags=R user=cyrus argv=/cyrus/bin/deliver -e -m ${extension} ${user}
          cyrus unix - n n - - pipe
          user=cyrus argv=/cyrus/bin/deliver -e -r ${sender} -m ${extension}
          ${user}
          uucp unix - n n - - pipe
          flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail
          ($recipient)
          ifmail unix - n n - - pipe
          flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
          bsmtp unix - n n - - pipe
          flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop
          $recipient
          smtp-amavis unix - - n - 10 smtp
          -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes
          -o disable_dns_lookups=yes -o max_use=20
          [127.0.0.1]:10025 inet n - n - - smtpd
          -o content_filter= -o local_recipient_maps= -o virtual_mailbox_maps=
          -o virtual_alias_maps= -o relay_recipient_maps=
          -o smtpd_restriction_classes= -o smtpd_delay_reject=no
          -o smtpd_client_restrictions=permit_mynetworks,reject
          -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions=
          -o smtpd_helo_restrictions= -o smtpd_milters= -o
          smtpd_sender_restrictions=
          -o smtpd_reject_unlisted_sender=no -o smtpd_relay_restrictions=
          -o smtpd_recipient_restrictions=permit_mynetworks,reject
          -o mynetworks_style=host -o mynetworks=127.0.0.0/8,[::1]/128
          -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0
          -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000
          -o smtpd_client_connection_count_limit=0
          -o smtpd_client_connection_rate_limit=0
          -o
          receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings
          -o local_header_rewrite_clients= -o syslog_name=postfix/amavisd
          [127.0.0.1]:10030 inet n - n - - smtpd
          -o local_recipient_maps= -o virtual_mailbox_maps= -o virtual_alias_maps=
          -o relay_recipient_maps= -o smtpd_restriction_classes=
          -o smtpd_delay_reject=no -o smtpd_milters=inet:localhost:8465
          -o smtpd_client_restrictions=permit_mynetworks,reject
          -o smtpd_sender_restrictions= -o smtpd_helo_restrictions=
          -o smtpd_recipient_restrictions=permit_mynetworks,reject
          -o smtpd_reject_unlisted_sender=no -o smtpd_relay_restrictions=
          -o smtpd_data_restrictions= -o smtpd_end_of_data_restrictions=
          -o syslog_name=postfix/dkimmilter
          -o content_filter=smtp-amavis:[127.0.0.1]:10032

          --Quanah

          --

          Quanah Gibson-Mount
          Sr. Member of Technical Staff
          Zimbra, Inc
          A Division of VMware, Inc.
          --------------------
          Zimbra :: the leader in open source messaging and collaboration
        • Quanah Gibson-Mount
          --On Tuesday, April 09, 2013 8:00 PM -0500 Noel Jones ... This is just a small test setup. In a production setup, not all users will have the same endpoint.
          Message 4 of 8 , Apr 9, 2013
          • 0 Attachment
            --On Tuesday, April 09, 2013 8:00 PM -0500 Noel Jones
            <njones@...> wrote:


            > OK, this looks as if you're overriding the virtual_transport entry
            > here. If all the zre-ldap002.eng.vmware.com users use the same
            > endpoint, you can set
            > virtual_transport = lmtp:zre-ldap002.eng.vmware.com:7025
            > and get rid of the transport lookup.

            This is just a small test setup. In a production setup, not all users will
            have the same endpoint. For example, our production service has 3 mailbox
            servers (LMTP) and 2 MTAs. So the lmtp result would differ depending on
            which mailbox server homes a user.

            --Quanah


            --

            Quanah Gibson-Mount
            Sr. Member of Technical Staff
            Zimbra, Inc
            A Division of VMware, Inc.
            --------------------
            Zimbra :: the leader in open source messaging and collaboration
          • Viktor Dukhovni
            ... Actually, it is not always a bad idea. If you have a virtual_mailbox domain, solely for the purpose of recipient validation: indexed =
            Message 5 of 8 , Apr 9, 2013
            • 0 Attachment
              On Tue, Apr 09, 2013 at 04:56:28PM -0700, Quanah Gibson-Mount wrote:

              > The main issue right now is that it has:
              >
              > virtual_transport = error
              >
              > which I was told makes little sense, so I'm trying to correct our
              > configuration.

              Actually, it is not always a bad idea. If you have a virtual_mailbox
              domain, solely for the purpose of recipient validation:

              indexed = ${default_database_type}:${config_directory}/
              virtual_mailbox_domains = example.com
              virtual_mailbox_maps = ${indexed}vmbox

              and if delivery to real users in example.com is always via LMTP or
              some other transport that requires an explicit user mapping (say
              to a specific IMAP server, ...) then it may make sense to set:

              virtual_transport = error:5.1.1 User unknown
              transport_maps = ${indexed}transport

              with:

              /etc/postfix/vmbox:
              luser@... ok

              /etc/postfix/transport:
              luser@... lmtp:inet:imap.example.com:24

              with the result that mail to <luser@...> is delivered to
              the virtual mailbox, while mail for <bogus@...> is not
              only rejected by smtpd(8) (since bogus is not in virtual_mailbox_maps),
              but also bounces if generated locally, since it resolves to the
              error transport without the need to contact the LMTP server (which
              may in some cases be configured to create mailboxes on the fly).

              This said, I would take a different approach:

              main.cf:
              # Use virtual alias domains for mail routing, not per-user
              # transport entries.
              #
              indexed = ${default_database_type}:${config_directory}/
              virtual_alias_domains = example.com
              virtual_alias_maps = ${indexed}valias
              virtual_mailbox_domains = ${indexed}vmdomains
              transport_maps = ${indexed}transport

              # Optional, undo virtual(5) rewrites.
              smtp_generic_maps = ${indexed}generic

              # Refuse mail to user@invalid or user@...
              smtpd_relay_restrictions =
              permit_mynetworks, permit_sasl_authenticated,
              reject_unauth_destination
              smtpd_recipient_restrictions =
              check_recipient_access ${indexed}rcpt-access

              /etc/postfix/rcpt-access
              # Don't allow explicit addressing of ".invalid" namespace.
              invalid REJECT 5.1.2 invalid destination domain
              .invalid REJECT 5.1.2 invalid destination domain

              /etc/postfix/valias:
              # One entry per valid user
              luser@... luser@...
              luser2@... luser@...
              ...

              /etc/postfix/generic:
              # Optional, needed if the LMTP servers don't like
              # luser@lmtp<N>.virtual.invalid and need the original
              # external address.
              luser@... luser@...

              /etc/postfix/transport:
              # One entry per LMTP server
              lmtp1.virtual.invalid lmtp:inet:server1.example.com:24
              lmtp2.virtual.invalid lmtp:inet:server1.example.com:24
              ...

              /etc/postfix/vmdomains:
              # One entry per LMTP server
              lmtp1.virtual.invalid virtual
              lmtp2.virtual.invalid virtual
              ...

              --
              Viktor.
            • Quanah Gibson-Mount
              --On Wednesday, April 10, 2013 1:27 AM +0000 Viktor Dukhovni ... ... Thanks Viktor, this looks interesting. I m assuming I can do all of this via LDAP rather
              Message 6 of 8 , Apr 10, 2013
              • 0 Attachment
                --On Wednesday, April 10, 2013 1:27 AM +0000 Viktor Dukhovni
                <postfix-users@...> wrote:

                > On Tue, Apr 09, 2013 at 04:56:28PM -0700, Quanah Gibson-Mount wrote:
                >
                >> The main issue right now is that it has:
                >>
                >> virtual_transport = error
                >>
                >> which I was told makes little sense, so I'm trying to correct our
                >> configuration.
                >
                > Actually, it is not always a bad idea. If you have a virtual_mailbox
                > domain, solely for the purpose of recipient validation:
                >
                > indexed = ${default_database_type}:${config_directory}/
                > virtual_mailbox_domains = example.com
                > virtual_mailbox_maps = ${indexed}vmbox
                >
                > and if delivery to real users in example.com is always via LMTP or
                > some other transport that requires an explicit user mapping (say
                > to a specific IMAP server, ...) then it may make sense to set:
                >
                > virtual_transport = error:5.1.1 User unknown
                > transport_maps = ${indexed}transport
                >
                > with:
                >
                > /etc/postfix/vmbox:
                > luser@... ok
                >
                > /etc/postfix/transport:
                > luser@... lmtp:inet:imap.example.com:24
                >
                > with the result that mail to <luser@...> is delivered to
                > the virtual mailbox, while mail for <bogus@...> is not
                > only rejected by smtpd(8) (since bogus is not in virtual_mailbox_maps),
                > but also bounces if generated locally, since it resolves to the
                > error transport without the need to contact the LMTP server (which
                > may in some cases be configured to create mailboxes on the fly).
                >
                > This said, I would take a different approach:
                ...

                Thanks Viktor, this looks interesting.

                I'm assuming I can do all of this via LDAP rather than flat files? We have
                customers with thousands of domains, and number of which may be aliases for
                various of the defined domains, which is why we query all of this
                information from LDAP. Any solution that requires using flat files is a
                nonstarter.

                --Quanah

                --

                Quanah Gibson-Mount
                Sr. Member of Technical Staff
                Zimbra, Inc
                A Division of VMware, Inc.
                --------------------
                Zimbra :: the leader in open source messaging and collaboration
              • Viktor Dukhovni
                ... Why do you need to assume? All examples using indexed files are a mechanism to demonstrate the required table contents. You should know by now that all
                Message 7 of 8 , Apr 10, 2013
                • 0 Attachment
                  On Wed, Apr 10, 2013 at 07:55:53AM -0700, Quanah Gibson-Mount wrote:

                  > >This said, I would take a different approach:
                  > ...
                  >
                  > Thanks Viktor, this looks interesting.
                  >
                  > I'm assuming I can do all of this via LDAP rather than flat files?

                  Why do you need to assume? All examples using indexed files are
                  a mechanism to demonstrate the required table contents. You should
                  know by now that all tables are logically equivalent provided they
                  return the same results for the same lookup keys.

                  > We have customers with thousands of domains, and number of which may
                  > be aliases for various of the defined domains, which is why we query
                  > all of this information from LDAP. Any solution that requires using
                  > flat files is a nonstarter.

                  This said, not all tables are operationally equivalent. All the
                  hoops jumped in my preferred configuration are designed to avoid
                  having an LDAP *transport* table. The transport table should
                  ideally be small, static and "indexed" (generated as a CDB or
                  similar local database in a file).

                  By rewriting users to mailstore-specific mailbox addresses, you
                  at most need transport table entries for each mail store, not
                  for each user. You can even do away with per-mailstore transport
                  entries if you set:

                  virtual_transport = lmtp
                  # Adjust if necessary
                  lmtp_tcp_port = 24

                  and ensure that all the mailstore-specific domain-parts resolve
                  in DNS. To that end you can rewrite users to:

                  luser@... luser@...
                  luser2@... luser2@...
                  ...

                  and avoid the "invalid" TLD if that's preferred. You can still
                  disallow remote injection directly into the server domains, by
                  various mechanisms (mostly make sure to not include them in
                  relay_domains via parent_domain_matches_subdomains).

                  Lots of ways to skin this cat... I am not a fan of LDAP with
                  transport_maps, since this impacts queue-manager reliability
                  and performance. Also rewriting is more robust against loops.
                  Where-as forwarding the same address around based on transport
                  tables risks inconsistent configuration leading to loops.
                  If the per-user transport end-point is LMTP, the loop issue is
                  less of a concern, since LMTP servers are not expected to ever
                  forward mail.

                  --
                  Viktor.
                Your message has been successfully submitted and would be delivered to recipients shortly.