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

Re: Setting up virtual domains correctly

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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.