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

Setting up virtual domains correctly

Expand Messages
  • Quanah Gibson-Mount
    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
    Message 1 of 8 , Apr 9, 2013
      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.
      However, I'm completely unclear as to what I should be setting
      virtual_transport 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


      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.

      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
    • 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 2 of 8 , Apr 9, 2013
        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 3 of 8 , Apr 9, 2013
          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 4 of 8 , Apr 9, 2013
            --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 5 of 8 , Apr 9, 2013
              --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 6 of 8 , Apr 9, 2013
                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 7 of 8 , Apr 10, 2013
                  --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 8 of 8 , Apr 10, 2013
                    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.