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

forwarding mail to another MX on same domain

Expand Messages
  • Khosrow Ebrahimpour
    Hi postfix-users, We recently migrated from a Sendmail/Cyrus environment to a Postfix/Courier setup. Some of the users had .forward files that would forward
    Message 1 of 22 , Nov 21, 2008
    • 0 Attachment
      Hi postfix-users,

      We recently migrated from a Sendmail/Cyrus environment to a Postfix/Courier
      setup. Some of the users had ".forward" files that would forward their mail
      to an exchange server in our network, and this was done with a file like this
      one :

      ===
      @...:John.Doe@...
      ===

      Since the migration, this feature doesn't work anymore. ms-exch is a virtual
      host that maps to one of three actual servers. And the so simply putting a
      rule that would forward mail to John.Doe@... doesn't work.
      I've looked at transport maps but I'm not sure this problem can be solved
      using them.. as per the following thread:
      http://groups.google.com/group/list.postfix.users/browse_thread/thread/733c642ef2ccab35/d7cac2e02e313d36

      Any help is appreciated.

      Thank you,
      /Khosrow
    • Brian Evans - Postfix List
      ... .forward files are only used on delivery by local(8) and must be in alias(5) map format ... transport(5) maps, like the documentation says, can use any key
      Message 2 of 22 , Nov 21, 2008
      • 0 Attachment
        Khosrow Ebrahimpour wrote:
        > Hi postfix-users,
        >
        > We recently migrated from a Sendmail/Cyrus environment to a Postfix/Courier
        > setup. Some of the users had ".forward" files that would forward their mail
        > to an exchange server in our network, and this was done with a file like this
        > one :
        >
        > ===
        > @...:John.Doe@...
        > ===
        >
        >

        .forward files are only used on delivery by local(8) and must be in
        alias(5) map format
        > Since the migration, this feature doesn't work anymore. ms-exch is a virtual
        > host that maps to one of three actual servers. And the so simply putting a
        > rule that would forward mail to John.Doe@... doesn't work.
        > I've looked at transport maps but I'm not sure this problem can be solved
        > using them.. as per the following thread:
        > http://groups.google.com/group/list.postfix.users/browse_thread/thread/733c642ef2ccab35/d7cac2e02e313d36
        >

        transport(5) maps, like the documentation says, can use any key listed
        in the Table Search Order section, including user@..., to route
        mail.
        As mouss notes in that archived post, transport maps are highly
        sensitive to outages.
        Database maps (ldap,*sql) are allowed but must have high availability.

        I suggest fully reading http://www.postfix.org/transport.5.html

        Brian
      • Wietse Venema
        ... This is SMTP syntax that has been deprecated forever. RFC 822 (released 1982) discourages its use and later RFCs do the same. Postfix supports this syntax
        Message 3 of 22 , Nov 21, 2008
        • 0 Attachment
          Khosrow Ebrahimpour:
          > Hi postfix-users,
          >
          > We recently migrated from a Sendmail/Cyrus environment to a Postfix/Courier
          > setup. Some of the users had ".forward" files that would forward their mail
          > to an exchange server in our network, and this was done with a file like this
          > one :
          >
          > ===
          > @...:John.Doe@...


          This is SMTP syntax that has been deprecated forever. RFC 822
          (released 1982) discourages its use and later RFCs do the same.

          Postfix supports this syntax only in SMTP commands, by removing
          the @...: portion. And that would not work for you,
          since you have multiple servers that accept only user@...
          not user@....

          > Since the migration, this feature doesn't work anymore. ms-exch is a virtual
          > host that maps to one of three actual servers. And the so simply putting a
          > rule that would forward mail to John.Doe@... doesn't work.
          > I've looked at transport maps but I'm not sure this problem can be solved
          > using them.. as per the following thread:

          A transport maps entry like this:

          John.Doe@... smtp:ms-exch.example.com

          Should do the job.

          Wietse
        • Victor Duchovni
          ... But may cause a loop if the mail ultimately returns to the same server for final delivery. The OP has to explain the situation in more detail if that is is
          Message 4 of 22 , Nov 21, 2008
          • 0 Attachment
            On Fri, Nov 21, 2008 at 02:31:38PM -0500, Wietse Venema wrote:

            > > Since the migration, this feature doesn't work anymore. ms-exch is a virtual
            > > host that maps to one of three actual servers. And the so simply putting a
            > > rule that would forward mail to John.Doe@... doesn't work.
            > > I've looked at transport maps but I'm not sure this problem can be solved
            > > using them.. as per the following thread:
            >
            > A transport maps entry like this:
            >
            > John.Doe@... smtp:ms-exch.example.com
            >
            > Should do the job.

            But may cause a loop if the mail ultimately returns to the same
            server for final delivery. The OP has to explain the situation
            in more detail if that is is the case.

            --
            Viktor.

            Disclaimer: off-list followups get on-list replies or get ignored.
            Please do not ignore the "Reply-To" header.

            To unsubscribe from the postfix-users list, visit
            http://www.postfix.org/lists.html or click the link below:
            <mailto:majordomo@...?body=unsubscribe%20postfix-users>

            If my response solves your problem, the best way to thank me is to not
            send an "it worked, thanks" follow-up. If you must respond, please put
            "It worked, thanks" in the "Subject" so I can delete these quickly.
          • Ville Walveranta
            ... Interesting. I think this may answer the question I posted last night about Preventing local forwarding for some local domains . Rather than preventing
            Message 5 of 22 , Nov 21, 2008
            • 0 Attachment
              On Fri, Nov 21, 2008 at 1:31 PM, Wietse Venema <wietse@...> wrote:
              > A transport maps entry like this:
              >
              > John.Doe@... smtp:ms-exch.example.com
              >
              > Should do the job.

              Interesting. I think this may answer the question I posted last night
              about "Preventing local forwarding for some local domains". Rather
              than preventing local forwarding, I can just map the users to another
              smtp server.

              Ville
            • Khosrow Ebrahimpour
              First, thanks for the response everyone. ... I tried that solution, and it in fact caused a loop. My exact setup was the following: in main.cf I had
              Message 6 of 22 , Nov 21, 2008
              • 0 Attachment
                First, thanks for the response everyone.

                > > A transport maps entry like this:
                > >
                > > John.Doe@... smtp:ms-exch.example.com
                > >
                > > Should do the job.
                >
                > But may cause a loop if the mail ultimately returns to the same
                > server for final delivery. The OP has to explain the situation
                > in more detail if that is is the case.

                I tried that solution, and it in fact caused a loop. My exact setup was the
                following:

                in main.cf I had

                transport_maps=/etc/postfix/transport

                and in /etc/postfix/transport I had

                John.Doe@... smtp:ms-exch.cmc.ec.gc.ca

                the end result of this was that no mail was getting to user
                John.Doe@...

                I think this is due to the fact that we also have ms-exch defined as the
                fallback_transport in main.cf. I will re-read
                http://www.postfix.org/transport.5.html as has been suggested. Any insight is
                definitely welcome.

                cheers,
                /Khosrow
              • Victor Duchovni
                ... What sort of loop did it cause? How do you expect Postfix to differentiate between the recipient when created via list expansion, and the same recipient
                Message 7 of 22 , Nov 21, 2008
                • 0 Attachment
                  On Fri, Nov 21, 2008 at 08:34:35PM +0000, Khosrow Ebrahimpour wrote:

                  > > > A transport maps entry like this:
                  > > >
                  > > > John.Doe@... smtp:ms-exch.example.com
                  > > >
                  > > > Should do the job.
                  > >
                  > > But may cause a loop if the mail ultimately returns to the same
                  > > server for final delivery. The OP has to explain the situation
                  > > in more detail if that is is the case.
                  >
                  > I tried that solution, and it in fact caused a loop. My exact setup was the
                  > following:

                  What sort of loop did it cause? How do you expect Postfix to differentiate
                  between the recipient when created via list expansion, and the same
                  recipient when mail returns to you after external filtering?

                  > in main.cf I had
                  >
                  > transport_maps=/etc/postfix/transport
                  >
                  > and in /etc/postfix/transport I had
                  >
                  > John.Doe@... smtp:ms-exch.cmc.ec.gc.ca
                  >
                  > the end result of this was that no mail was getting to user
                  > John.Doe@...

                  Think it through, and post a flow description, showing all the steps
                  the mail will traverse, what the recipient addresses are at each stage,
                  and how you want the mail processed.

                  > I think this is due to the fact that we also have ms-exch defined as the
                  > fallback_transport in main.cf. I will re-read
                  > http://www.postfix.org/transport.5.html as has been suggested. Any insight is
                  > definitely welcome.

                  Don't guess, design and document. Once you have a design, we can refine
                  the implementation strategy.

                  --
                  Viktor.

                  Disclaimer: off-list followups get on-list replies or get ignored.
                  Please do not ignore the "Reply-To" header.

                  To unsubscribe from the postfix-users list, visit
                  http://www.postfix.org/lists.html or click the link below:
                  <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                  If my response solves your problem, the best way to thank me is to not
                  send an "it worked, thanks" follow-up. If you must respond, please put
                  "It worked, thanks" in the "Subject" so I can delete these quickly.
                • Khosrow Ebrahimpour
                  Just a correction. The solution that Wietse had suggested does work. I had forgotten one crucial step: re-building the lookup table. After I ran postmap
                  Message 8 of 22 , Nov 21, 2008
                  • 0 Attachment
                    Just a correction. The solution that Wietse had suggested does work. I had
                    forgotten one crucial step: re-building the lookup table. After I
                    ran "postmap /etc/postfix/transport" the forwarding now works correctly.
                  • Ville Walveranta
                    ... It also seems to be possible to redirect an entire domain to another smtp server.. @example.com smtp:ms-exch.example.com This is good news! :-)
                    Message 9 of 22 , Nov 21, 2008
                    • 0 Attachment
                      On Fri, Nov 21, 2008 at 1:31 PM, Wietse Venema <wietse@...> wrote:
                      > A transport maps entry like this:
                      >
                      > John.Doe@... smtp:ms-exch.example.com

                      It also seems to be possible to redirect an entire domain to another
                      smtp server..

                      @... smtp:ms-exch.example.com

                      This is good news! :-)

                      Ville
                    • Victor Duchovni
                      ... Wrong syntax. In the transport table, domains don t start with an @ . -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored. Please
                      Message 10 of 22 , Nov 21, 2008
                      • 0 Attachment
                        On Fri, Nov 21, 2008 at 11:13:51PM -0600, Ville Walveranta wrote:

                        > On Fri, Nov 21, 2008 at 1:31 PM, Wietse Venema <wietse@...> wrote:
                        > > A transport maps entry like this:
                        > >
                        > > John.Doe@... smtp:ms-exch.example.com
                        >
                        > It also seems to be possible to redirect an entire domain to another
                        > smtp server..
                        >
                        > @... smtp:ms-exch.example.com
                        >

                        Wrong syntax. In the transport table, domains don't start with
                        an "@".

                        --
                        Viktor.

                        Disclaimer: off-list followups get on-list replies or get ignored.
                        Please do not ignore the "Reply-To" header.

                        To unsubscribe from the postfix-users list, visit
                        http://www.postfix.org/lists.html or click the link below:
                        <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                        If my response solves your problem, the best way to thank me is to not
                        send an "it worked, thanks" follow-up. If you must respond, please put
                        "It worked, thanks" in the "Subject" so I can delete these quickly.
                      • Ville Walveranta
                        On Fri, Nov 21, 2008 at 11:18 PM, Victor Duchovni ... Ok, I corrected it (although it seemed to work with an @ , too). Ville
                        Message 11 of 22 , Nov 21, 2008
                        • 0 Attachment
                          On Fri, Nov 21, 2008 at 11:18 PM, Victor Duchovni
                          <Victor.Duchovni@...> wrote:
                          > Wrong syntax. In the transport table, domains don't start with
                          > an "@".

                          Ok, I corrected it (although it seemed to work with an "@", too).

                          Ville
                        • Victor Duchovni
                          ... Your observations were in error: http://www.postfix.org/transport.5.html -- Viktor. Disclaimer: off-list followups get on-list replies or get ignored.
                          Message 12 of 22 , Nov 21, 2008
                          • 0 Attachment
                            On Fri, Nov 21, 2008 at 11:29:55PM -0600, Ville Walveranta wrote:

                            > On Fri, Nov 21, 2008 at 11:18 PM, Victor Duchovni
                            > <Victor.Duchovni@...> wrote:
                            > > Wrong syntax. In the transport table, domains don't start with
                            > > an "@".
                            >
                            > Ok, I corrected it (although it seemed to work with an "@", too).

                            Your observations were in error:

                            http://www.postfix.org/transport.5.html

                            --
                            Viktor.

                            Disclaimer: off-list followups get on-list replies or get ignored.
                            Please do not ignore the "Reply-To" header.

                            To unsubscribe from the postfix-users list, visit
                            http://www.postfix.org/lists.html or click the link below:
                            <mailto:majordomo@...?body=unsubscribe%20postfix-users>

                            If my response solves your problem, the best way to thank me is to not
                            send an "it worked, thanks" follow-up. If you must respond, please put
                            "It worked, thanks" in the "Subject" so I can delete these quickly.
                          • Ville Walveranta
                            On Fri, Nov 21, 2008 at 11:41 PM, Victor Duchovni ... You re correct. I hadn t refreshed the system after I made the change. Ville
                            Message 13 of 22 , Nov 21, 2008
                            • 0 Attachment
                              On Fri, Nov 21, 2008 at 11:41 PM, Victor Duchovni
                              <Victor.Duchovni@...> wrote:
                              > Your observations were in error..

                              You're correct. I hadn't refreshed the system after I made the change.

                              Ville
                            • Ville Walveranta
                              I ll continue here since Krosrow s issue has been resolved (so I m not really hijacking the thread). I now have the following defined in
                              Message 14 of 22 , Nov 21, 2008
                              • 0 Attachment
                                I'll continue here since Krosrow's issue has been resolved (so I'm not
                                really hijacking the thread).

                                I now have the following defined in mailbox_transport_maps:

                                me@... smtp:mx.myexternaldomain.com

                                Yet when I attempt to send mail to the local system at
                                me@... I get

                                554 5.7.1 <me@...>: Relay access denied
                                quit
                                221 2.0.0 Bye

                                Why? Shouldn't the smtp transport map deliver the message to the
                                defined external MX even when the user/domain me@...
                                is not locally defined since the configuration page says about
                                mailbox_transport_maps: `Optional lookup tables with per-recipient
                                message delivery transports to use for local(8) mailbox delivery,
                                whether or not the recipients are found in the UNIX passwd database.',
                                and since there is nothing higher in precedence (above
                                mailbox_transport_maps) of local overriding the mail delivery
                                instructions? The user/domain "me@..." is currently
                                not defined anywhere else on the local system except in
                                mailbox_transport_maps.

                                My main.cf:

                                ## DELTAS TO MAIN.CF.DEFAULT
                                ##
                                ## For the syntax, and for a complete parameter list,
                                ## see the postconf(5) manual page ("man 5 postconf"),
                                ## or see http://www.postfix.org/postconf.5.html

                                #soft_bounce = no
                                debug_peer_level = 9
                                debug_peer_list = 127.0.0.1

                                data_directory = /var/db/postfix
                                queue_directory = /var/spool/postfix
                                command_directory = /usr/local/sbin
                                daemon_directory = /usr/local/libexec/postfix
                                manpage_directory = /usr/local/man
                                sendmail_path = /usr/local/sbin/sendmail
                                newaliases_path = /usr/local/bin/newaliases
                                mailq_path = /usr/local/bin/mailq
                                readme_directory = $config_directory/README_FILES
                                sample_directory = /usr/local/etc/postfix
                                html_directory = no

                                mail_owner = postfix
                                setgid_group = maildrop

                                myhostname = my.localdomain.com
                                mydomain = my.localdomain.com
                                myorigin = $myhostname

                                mydestination =
                                $myhostname
                                localhost.$mydomain
                                localhost

                                mynetworks_style = host
                                mynetworks = 192.168.1.0/24
                                relay_domains = $mydestination
                                #delay_warning_time = 4h

                                # define here the listening interfaces
                                # that do _not_ have custom rules
                                inet_interfaces = 127.0.0.1, 192.168.1.99

                                # execute `postsuper -r ALL' & reload if you disable content_filter!
                                content_filter = scan:[127.0.0.1]:10025
                                receive_override_options = no_address_mappings

                                smtpd_helo_required = yes
                                smtpd_sasl_auth_enable = yes
                                smtpd_sasl_type = dovecot
                                smtpd_sasl_path = private/auth-client
                                broken_sasl_auth_clients = yes
                                disable_vrfy_command = yes
                                dovecot_destination_recipient_limit = 1

                                mailbox_transport_maps = hash:$config_directory/tables/mailbox_transport_maps
                                mailbox_transport = dovecot
                                mailbox_command = /usr/local/libexec/dovecot/deliver

                                virtual_transport = dovecot
                                virtual_mailbox_base = /home/vmail
                                virtual_mailbox_domains = $config_directory/tables/virtual_mailbox_domains
                                virtual_mailbox_maps = hash:$config_directory/tables/virtual_mailbox_maps
                                virtual_alias_domains = $config_directory/tables/virtual_alias_domains
                                virtual_alias_maps =
                                hash:$config_directory/tables/virtual_alias_maps
                                pcre:$config_directory/tables/virtual_alias_maps_pcre

                                virtual_uid_maps = static:2000
                                virtual_gid_maps = static:2000

                                smtpd_client_restrictions =
                                permit_mynetworks
                                permit_inet_interfaces
                                reject

                                smtpd_client_restrictions_katharion =
                                permit_mynetworks
                                permit_sasl_authenticated
                                check_client_access
                                hash:$config_directory/tables/smtpd_client_access_katharion
                                reject

                                smtpd_helo_restrictions =
                                reject_invalid_helo_hostname
                                reject_non_fqdn_helo_hostname
                                permit_mynetworks
                                permit_sasl_authenticated
                                reject_unknown_helo_hostname

                                smtpd_etrn_restrictions =
                                permit_mynetworks
                                reject

                                smtpd_recipient_restrictions =
                                reject_non_fqdn_recipient
                                reject_non_fqdn_sender
                                reject_unknown_sender_domain
                                reject_unknown_recipient_domain
                                reject_unverified_recipient
                                check_recipient_access
                                pcre:$config_directory/tables/smtpd_recipient_access
                                # permit_mynetworks #disabled for testing purposes
                                permit_sasl_authenticated
                                reject_non_fqdn_hostname
                                reject_invalid_hostname
                                reject_unauth_destination

                                smtpd_recipient_restrictions_katharion =
                                reject_non_fqdn_recipient
                                reject_non_fqdn_sender
                                reject_unknown_sender_domain
                                reject_unknown_recipient_domain
                                reject_unverified_recipient
                                check_recipient_access
                                pcre:$config_directory/tables/smtpd_recipient_access_katharion
                                permit_mynetworks
                                permit_sasl_authenticated
                                reject_non_fqdn_hostname
                                reject_invalid_hostname
                                reject_unauth_destination

                                smtpd_data_restrictions =
                                reject_multi_recipient_bounce
                                reject_unauth_pipelining

                                --

                                smtpd_recipient_tables (the interface I'm trying to send through) includes

                                # reject domains that are served by Katharion
                                # on the generic smtpd interface
                                /(@virtualdomain1\.com|
                                @virtualdomain2\.com|
                                @virtualdomain3\.com|
                                @virtualdomain4\.com|
                                @virtualdomain5\.com)$/ REJECT



                                --

                                Many thanks for any insights!

                                Ville
                              • Ville Walveranta
                                I just realized that this would not resolve the issue because the remote MX would just redeliver it to the local server which is the final destination of the
                                Message 15 of 22 , Nov 22, 2008
                                • 0 Attachment
                                  I just realized that this would not resolve the issue because the
                                  remote MX would just redeliver it to the local server which is the
                                  final destination of the domain. I'm probably better off with a simple
                                  alias domain forward.

                                  So while it's not worth considering how to tweak my specific
                                  configuration, I'd still be curious to know why the transport map..

                                  me@... smtp:mx.myexternaldomain.com

                                  ..produces a "Relay access denied" error. Does the relay access need
                                  to be specifically allowed for that destination even though the
                                  transport is "internal" by a mapping?

                                  Ville
                                • mouss
                                  ... http://www.postfix.org/postconf.5.html#reject_unauth_destination
                                  Message 16 of 22 , Nov 22, 2008
                                  • 0 Attachment
                                    Ville Walveranta a écrit :
                                    > I just realized that this would not resolve the issue because the
                                    > remote MX would just redeliver it to the local server which is the
                                    > final destination of the domain. I'm probably better off with a simple
                                    > alias domain forward.
                                    >
                                    > So while it's not worth considering how to tweak my specific
                                    > configuration, I'd still be curious to know why the transport map..
                                    >
                                    > me@... smtp:mx.myexternaldomain.com
                                    >
                                    > ..produces a "Relay access denied" error. Does the relay access need
                                    > to be specifically allowed for that destination even though the
                                    > transport is "internal" by a mapping?
                                    >



                                    http://www.postfix.org/postconf.5.html#reject_unauth_destination
                                  • Wietse Venema
                                    ... For Postfix to accept mail for myexternaldomain.com, it must be listed in (exactly) one of the following: mydestination virtual_alias_domains
                                    Message 17 of 22 , Nov 22, 2008
                                    • 0 Attachment
                                      Ville Walveranta:
                                      > I'll continue here since Krosrow's issue has been resolved (so I'm not
                                      > really hijacking the thread).
                                      >
                                      > I now have the following defined in mailbox_transport_maps:
                                      >
                                      > me@... smtp:mx.myexternaldomain.com
                                      >
                                      > Yet when I attempt to send mail to the local system at
                                      > me@... I get
                                      >
                                      > 554 5.7.1 <me@...>: Relay access denied
                                      > quit
                                      > 221 2.0.0 Bye
                                      >
                                      > Why?

                                      For Postfix to accept mail for myexternaldomain.com, it must
                                      be listed in (exactly) one of the following:

                                      mydestination
                                      virtual_alias_domains
                                      virtual_mailbox_domains
                                      relay_domains.

                                      For more information see http://www.postfix.org/ADDRESS_CLASS_README.html.

                                      Wietse
                                    • Ville Walveranta
                                      Couple of messages earlier in this thread I posted the following pcre smtpd_recipient_access table: # reject domains that are served by Katharion # on the
                                      Message 18 of 22 , Nov 22, 2008
                                      • 0 Attachment
                                        Couple of messages earlier in this thread I posted the following pcre
                                        smtpd_recipient_access table:

                                        # reject domains that are served by Katharion
                                        # on the generic smtpd interface
                                        /(@virtualdomain1\.com|
                                        @virtualdomain2\.com|
                                        @virtualdomain3\.com|
                                        @virtualdomain4\.com|
                                        @virtualdomain5\.com)$/ REJECT

                                        That was of wrong format. In case someone is reading this later in the
                                        archives, here's the corrected version:

                                        /virtualdomain1\.com$/ REJECT
                                        /virtualdomain2\.com$/ REJECT
                                        /virtualdomain3\.com$/ REJECT
                                        /virtualdomain4\.com$/ REJECT
                                        /virtualdomain5\.com$/ REJECT

                                        PCRE statements can't be broken on multiple lines, of course, so if
                                        there are many items on the list it's better to break up the boolean
                                        statement. Also, I had initially (though not in the earlier post)..

                                        /^/ OK

                                        .. in the end, thinking that the ones that are not explicitly rejected
                                        should be allowed in the context of this PCRE table. But since the
                                        table is called from smtpd_recipient_restrictions, such a statement
                                        creates an open relay.

                                        Ville
                                      • Henrik K
                                        ... http://www.postfix.org/pcre_table.5.html Sure you can do multi-line, have a look at option x. /@(virtualdomain1 .com| virtualdomain2 .com|
                                        Message 19 of 22 , Nov 23, 2008
                                        • 0 Attachment
                                          On Sun, Nov 23, 2008 at 12:15:43AM -0600, Ville Walveranta wrote:
                                          > Couple of messages earlier in this thread I posted the following pcre
                                          > smtpd_recipient_access table:
                                          >
                                          > # reject domains that are served by Katharion
                                          > # on the generic smtpd interface
                                          > /(@virtualdomain1\.com|
                                          > @virtualdomain2\.com|
                                          > @virtualdomain3\.com|
                                          > @virtualdomain4\.com|
                                          > @virtualdomain5\.com)$/ REJECT
                                          >
                                          > That was of wrong format. In case someone is reading this later in the
                                          > archives, here's the corrected version:
                                          >
                                          > /virtualdomain1\.com$/ REJECT
                                          > /virtualdomain2\.com$/ REJECT
                                          > /virtualdomain3\.com$/ REJECT
                                          > /virtualdomain4\.com$/ REJECT
                                          > /virtualdomain5\.com$/ REJECT
                                          >
                                          > PCRE statements can't be broken on multiple lines, of course, so if
                                          > there are many items on the list it's better to break up the boolean
                                          > statement. Also, I had initially (though not in the earlier post)..

                                          http://www.postfix.org/pcre_table.5.html

                                          Sure you can do multi-line, have a look at option x.

                                          /@(virtualdomain1\.com|
                                          virtualdomain2\.com|
                                          virtualdomain3\.com|
                                          virtualdomain4\.com|
                                          virtualdomain5\.com
                                          )$/x REJECT

                                          It's also basic regexp that lots of alternations are much likely to be
                                          faster than executing separate clauses. Especially if you use the @ as
                                          starting point. You could even use perl Regexp::Assemble to create optimized
                                          monsters. Of course all this is marginal if you don't have thousands of
                                          domains and CDB would be much more efficient anyway.
                                        • mouss
                                          ... As Henrik says, you can break them with /x. Note that in this example, pcre is too much. a hash (or cdb) will do fine: virtualdomain1.com REJECT
                                          Message 20 of 22 , Nov 23, 2008
                                          • 0 Attachment
                                            Ville Walveranta a écrit :
                                            > Couple of messages earlier in this thread I posted the following pcre
                                            > smtpd_recipient_access table:
                                            >
                                            > # reject domains that are served by Katharion
                                            > # on the generic smtpd interface
                                            > /(@virtualdomain1\.com|
                                            > @virtualdomain2\.com|
                                            > @virtualdomain3\.com|
                                            > @virtualdomain4\.com|
                                            > @virtualdomain5\.com)$/ REJECT
                                            >
                                            > That was of wrong format. In case someone is reading this later in the
                                            > archives, here's the corrected version:
                                            >
                                            > /virtualdomain1\.com$/ REJECT
                                            > /virtualdomain2\.com$/ REJECT
                                            > /virtualdomain3\.com$/ REJECT
                                            > /virtualdomain4\.com$/ REJECT
                                            > /virtualdomain5\.com$/ REJECT
                                            >
                                            > PCRE statements can't be broken on multiple lines, of course, so if
                                            > there are many items on the list it's better to break up the boolean
                                            > statement.

                                            As Henrik says, you can break them with /x.

                                            Note that in this example, pcre is too much. a hash (or cdb) will do fine:

                                            virtualdomain1.com REJECT
                                            virtualdomain2.com REJECT
                                            ....


                                            > Also, I had initially (though not in the earlier post)..
                                            >
                                            > /^/ OK
                                            >
                                            > .. in the end, thinking that the ones that are not explicitly rejected
                                            > should be allowed in the context of this PCRE table. But since the
                                            > table is called from smtpd_recipient_restrictions, such a statement
                                            > creates an open relay.
                                            >

                                            it doesn't look like you need that line anyway (you want to continue
                                            processing other checks, no?).

                                            Anyway, when such checks are to be performed before
                                            reject_unauth_destination, it is safer to put them in
                                            smtpd_sender_restrictions.
                                          • Ville Walveranta
                                            ... Got it to work after realizing a blank space is needed in front of the continuation lines... ... There is another (PCRE) clause in the file to prepend a
                                            Message 21 of 22 , Nov 25, 2008
                                            • 0 Attachment
                                              On Sun, Nov 23, 2008 at 3:35 AM, mouss <mouss@...> wrote:
                                              > As Henrik says, you can break them with /x.

                                              Got it to work after realizing a blank space is needed in front of the
                                              continuation lines...

                                              > Note that in this example, pcre is too much. a hash (or cdb) will do fine:
                                              >
                                              > virtualdomain1.com REJECT
                                              > virtualdomain2.com REJECT

                                              There is another (PCRE) clause in the file to prepend a header, though
                                              I suppose I could split it in two files since cdbs are faster to
                                              discern domains.

                                              >> .. in the end, thinking that the ones that are not explicitly rejected
                                              >> should be allowed in the context of this PCRE table. But since the
                                              >> table is called from smtpd_recipient_restrictions, such a statement
                                              >> creates an open relay.
                                              > it doesn't look like you need that line anyway (you want to continue
                                              > processing other checks, no?).
                                              >
                                              > Anyway, when such checks are to be performed before
                                              > reject_unauth_destination, it is safer to put them in
                                              > smtpd_sender_restrictions.

                                              Correct. But does Postfix know about the recipient information at
                                              smtpd_sender_restrictions stage to check for recipient access? I
                                              should re-read the stage document but it seems, if I remember
                                              correctly, that both the sender and recipient information are
                                              validated at the same time (i.e. a failed smtpd_sender_restrictions
                                              check doesn't produce an error until after RCPT TO has been issued).

                                              Ville
                                            • mouss
                                              ... yes, in the default setup (smtpd_delay_reject=yes).
                                              Message 22 of 22 , Nov 25, 2008
                                              • 0 Attachment
                                                Ville Walveranta a écrit :
                                                > On Sun, Nov 23, 2008 at 3:35 AM, mouss <mouss@...> wrote:
                                                >> As Henrik says, you can break them with /x.
                                                >
                                                > Got it to work after realizing a blank space is needed in front of the
                                                > continuation lines...
                                                >
                                                >> Note that in this example, pcre is too much. a hash (or cdb) will do fine:
                                                >>
                                                >> virtualdomain1.com REJECT
                                                >> virtualdomain2.com REJECT
                                                >
                                                > There is another (PCRE) clause in the file to prepend a header, though
                                                > I suppose I could split it in two files since cdbs are faster to
                                                > discern domains.
                                                >
                                                >>> .. in the end, thinking that the ones that are not explicitly rejected
                                                >>> should be allowed in the context of this PCRE table. But since the
                                                >>> table is called from smtpd_recipient_restrictions, such a statement
                                                >>> creates an open relay.
                                                >> it doesn't look like you need that line anyway (you want to continue
                                                >> processing other checks, no?).
                                                >>
                                                >> Anyway, when such checks are to be performed before
                                                >> reject_unauth_destination, it is safer to put them in
                                                >> smtpd_sender_restrictions.
                                                >
                                                > Correct. But does Postfix know about the recipient information at
                                                > smtpd_sender_restrictions stage to check for recipient access? I
                                                > should re-read the stage document but it seems, if I remember
                                                > correctly, that both the sender and recipient information are
                                                > validated at the same time (i.e. a failed smtpd_sender_restrictions
                                                > check doesn't produce an error until after RCPT TO has been issued).
                                                >

                                                yes, in the default setup (smtpd_delay_reject=yes).
                                              Your message has been successfully submitted and would be delivered to recipients shortly.