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

Re: Configuring a mail gateway

Expand Messages
  • Nikolaos Milas
    ... Hello again, I am returning to this matter after some time. I have read the documentation indicated, and would like to ask some clarifications (I will be
    Message 1 of 20 , Sep 3, 2011
    • 0 Attachment
      On 18/2/2011 6:48 μμ, Victor Duchovni wrote:

      > On Fri, Feb 18, 2011 at 06:43:28PM +0200, Nikolaos Milas wrote:
      >
      >> What is the suggested way to configure Postfix to play this role, i.e. to
      >> simply send all incoming (clean, after filtering) mail to another mail
      >> server?
      > http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
      >

      Hello again,

      I am returning to this matter after some time. I have read the
      documentation indicated, and would like to ask some clarifications (I
      will be running latest Postfix (2.8.5) on CentOS 5.6):

      On the firewall/gateway example, the following configuration is proposed
      to NOT accept messages for subdomains:

      parent_domain_matches_subdomains =
      debug_peer_list smtpd_access_maps

      My question: In our case we DO want to accept mail for subdomains too.
      So, how should the example be modified to accept mail for some
      (particular ones) or all of the subdomains of example.com ?

      Thanks,
      Nick
    • Noel Jones
      ... To accept mail for specified subdomains, add those domains to the relay_domains parameter. This is the recommended solution. Accepting mail for all
      Message 2 of 20 , Sep 3, 2011
      • 0 Attachment
        On 9/3/2011 1:31 PM, Nikolaos Milas wrote:
        > On 18/2/2011 6:48 μμ, Victor Duchovni wrote:
        >
        >> On Fri, Feb 18, 2011 at 06:43:28PM +0200, Nikolaos Milas wrote:
        >>
        >>> What is the suggested way to configure Postfix to play this role,
        >>> i.e. to
        >>> simply send all incoming (clean, after filtering) mail to another
        >>> mail
        >>> server?
        >>
        >> http://www.postfix.org/STANDARD_CONFIGURATION_README.html#firewall
        >>
        >
        > Hello again,
        >
        > I am returning to this matter after some time. I have read the
        > documentation indicated, and would like to ask some clarifications
        > (I will be running latest Postfix (2.8.5) on CentOS 5.6):
        >
        > On the firewall/gateway example, the following configuration is
        > proposed to NOT accept messages for subdomains:
        >
        > parent_domain_matches_subdomains =
        > debug_peer_list smtpd_access_maps
        >
        > My question: In our case we DO want to accept mail for subdomains
        > too. So, how should the example be modified to accept mail for some
        > (particular ones) or all of the subdomains of example.com ?

        To accept mail for specified subdomains, add those domains to the
        relay_domains parameter. This is the recommended solution.

        Accepting mail for all subdomains is the historical default
        behavior. To get that behavior, just leave
        parent_domain_matches_subdomains at the build-in default, or make
        sure its value includes relay_domains.


        -- Noel Jones
      • Nikolaos Milas
        ... Thanks Noel, And to route incoming mails to different mail servers would we use: transport_maps = hash:/etc/postfix/transport /etc/postfix/transport:
        Message 3 of 20 , Sep 3, 2011
        • 0 Attachment
          On 3/9/2011 9:41 μμ, Noel Jones wrote:

          > To accept mail for specified subdomains, add those domains to the
          > relay_domains parameter. This is the recommended solution.

          Thanks Noel,

          And to route incoming mails to different mail servers would we use:

          transport_maps = hash:/etc/postfix/transport

          /etc/postfix/transport:
          example.com smtp:[mailserver1.example.com]
          sub1.example.com smtp:[mailserver1.example.com]
          sub2.example.com smtp:[mailserver1.example.com]
          sub3.example.com smtp:[mailserverx.sub3.example.com]
          ...

          ...??

          Thanks,
          Nick
        • Noel Jones
          ... Yes, although you may want to use relay: rather than smtp: as the transport name. The different name allows postfix to more efficiently schedule delivery
          Message 4 of 20 , Sep 3, 2011
          • 0 Attachment
            On 9/3/2011 1:52 PM, Nikolaos Milas wrote:
            > On 3/9/2011 9:41 μμ, Noel Jones wrote:
            >
            >> To accept mail for specified subdomains, add those domains to the
            >> relay_domains parameter. This is the recommended solution.
            >
            > Thanks Noel,
            >
            > And to route incoming mails to different mail servers would we use:
            >
            > transport_maps = hash:/etc/postfix/transport
            >
            > /etc/postfix/transport:
            > example.com smtp:[mailserver1.example.com]
            > sub1.example.com smtp:[mailserver1.example.com]
            > sub2.example.com smtp:[mailserver1.example.com]
            > sub3.example.com smtp:[mailserverx.sub3.example.com]
            > ...
            >


            Yes, although you may want to use relay: rather than smtp: as the
            transport name. The different name allows postfix to more
            efficiently schedule delivery for those domains, and allows you to
            use different relay delivery settings if needed.



            -- Noel Jones
          • Nikolaos Milas
            ... Thanks for the valuable info. One more bit. If we use: relay_recipient_maps = (that is, empty) then *all* recipients for the hosted domains (those listed
            Message 5 of 20 , Sep 3, 2011
            • 0 Attachment
              On 3/9/2011 10:10 μμ, Noel Jones wrote:

              > Yes, although you may want to use relay: rather than smtp: as the
              > transport name. The different name allows postfix to more efficiently
              > schedule delivery for those domains, and allows you to use different
              > relay delivery settings if needed. -- Noel Jones

              Thanks for the valuable info.

              One more bit.

              If we use:

              relay_recipient_maps =

              (that is, empty) then *all* recipients for the hosted domains (those
              listed in relay_domains) are accepted/forwarded?

              Is there a way we can configure the gateway server to ask the final
              delivery server (as defined in /etc/postfix/transport) whether the user
              is valid and decide to allow or reject the mail transfer? In this way we
              don't have to maintain a list of recipients.

              Alternatively, we can use ldap-based checking (because our users are
              LDAP-hosted), but what about their aliases (which are also LDAP-based)?
              On the main destination server we use: virtual_mailbox_maps and
              virtual_alias_maps with ldap-based definitions. Can/should we use those
              for relay_recipient_maps? An additional problem is that on the mail
              servers of some subdomains the users are not LDAP-hosted but standard
              local unix users. Asking directly the destination server for recipient
              validation would solve all these problems.

              Thanks again for your Saturday night kind assistance, :-)
              Nick
            • Noel Jones
              ... Yes. That turns you into a backscatter source, clogging your queue with undeliverable mail and eventually getting you blacklisted. Not recommended. ...
              Message 6 of 20 , Sep 3, 2011
              • 0 Attachment
                On 9/3/2011 2:52 PM, Nikolaos Milas wrote:
                > On 3/9/2011 10:10 μμ, Noel Jones wrote:
                >
                >> Yes, although you may want to use relay: rather than smtp: as the
                >> transport name. The different name allows postfix to more
                >> efficiently schedule delivery for those domains, and allows you to
                >> use different relay delivery settings if needed. -- Noel Jones
                >
                > Thanks for the valuable info.
                >
                > One more bit.
                >
                > If we use:
                >
                > relay_recipient_maps =
                >
                > (that is, empty) then *all* recipients for the hosted domains (those
                > listed in relay_domains) are accepted/forwarded?

                Yes. That turns you into a backscatter source, clogging your queue
                with undeliverable mail and eventually getting you blacklisted.

                Not recommended.

                > Is there a way we can configure the gateway server to ask the final
                > delivery server (as defined in /etc/postfix/transport) whether the
                > user is valid and decide to allow or reject the mail transfer? In
                > this way we don't have to maintain a list of recipients.

                http://www.postfix.org/ADDRESS_VERIFICATION_README.html

                This requires that the next-hop server reply with a 5xx response to
                nonexistent recipients.


                > Alternatively, we can use ldap-based checking (because our users are
                > LDAP-hosted), but what about their aliases (which are also
                > LDAP-based)? On the main destination server we use:
                > virtual_mailbox_maps and virtual_alias_maps with ldap-based
                > definitions. Can/should we use those for relay_recipient_maps? An
                > additional problem is that on the mail servers of some subdomains
                > the users are not LDAP-hosted but standard local unix users. Asking
                > directly the destination server for recipient validation would solve
                > all these problems.
                >

                You can use ldap for valid recipients. Structure your query so that
                valid aliases are also included.

                For your Unix users, you can do an automated periodic dump to a hash
                file and rsync it to the server. You can use both ldap and a hash
                map in relay_recipient_maps -- that's why the parameter is named
                "_maps" plural.

                Or just use active recipient verification. Whichever works best for
                your environment.



                -- Noel Jones
              • Nikolaos Milas
                ... OK, I understand. ... So, in order to implement such a solution, would it be sufficient to do something like the following, on the *gateway* mail server:
                Message 7 of 20 , Sep 5, 2011
                • 0 Attachment
                  On 3/9/2011 11:09 μμ, Noel Jones wrote:

                  > If we use:
                  >
                  > relay_recipient_maps =
                  >
                  > (that is, empty) then *all* recipients for the hosted domains (those
                  > listed in relay_domains) are accepted/forwarded?
                  > Yes. That turns you into a backscatter source, clogging your queue
                  > with undeliverable mail and eventually getting you blacklisted.
                  >
                  > Not recommended.

                  OK, I understand.

                  >> Is there a way we can configure the gateway server to ask the final
                  >> delivery server (as defined in /etc/postfix/transport) whether the
                  >> user is valid and decide to allow or reject the mail transfer? In
                  >> this way we don't have to maintain a list of recipients.
                  > http://www.postfix.org/ADDRESS_VERIFICATION_README.html
                  >
                  > This requires that the next-hop server reply with a 5xx response to
                  > nonexistent recipients.

                  So, in order to implement such a solution, would it be sufficient to do
                  something like the following, on the *gateway* mail server:

                  smtpd_recipient_restrictions =
                  permit_mynetworks, reject_unverified_recipient,
                  reject_unauth_destination

                  and on the *final destination* (next hop) mail server:

                  unverified_recipient_reject_code = 550

                  ...??

                  I guess this is what you mean by "active recipient verification". Right?

                  Thanks again,
                  Nick
                • Nikolaos Milas
                  ... ...and, if so, I guess we *still* need the directive: relay_recipient_maps = (empty) ?? Nick
                  Message 8 of 20 , Sep 5, 2011
                  • 0 Attachment
                    On 5/9/2011 3:26 μμ, Nikolaos Milas wrote:

                    > So, in order to implement such a solution, would it be sufficient to
                    > do something like the following, on the *gateway* mail server:
                    >
                    > smtpd_recipient_restrictions =
                    > permit_mynetworks, reject_unverified_recipient,
                    > reject_unauth_destination
                    >
                    > and on the *final destination* (next hop) mail server:
                    >
                    > unverified_recipient_reject_code = 550
                    >
                    > ...??
                    >
                    > I guess this is what you mean by "active recipient verification". Right?
                    >
                    >

                    ...and, if so, I guess we *still* need the directive:

                    relay_recipient_maps =

                    (empty) ??

                    Nick
                  • Noel Jones
                    ... Hash: SHA1 ... Typically the order would be smtpd_recipient_restrictions = permit_mynetworks reject_unauth_destination (local UCE controls)
                    Message 9 of 20 , Sep 5, 2011
                    • 0 Attachment
                      -----BEGIN PGP SIGNED MESSAGE-----
                      Hash: SHA1

                      On 9/5/2011 7:26 AM, Nikolaos Milas wrote:
                      > On 3/9/2011 11:09 μμ, Noel Jones wrote: So, in order to
                      > implement such a solution, would it be sufficient to do
                      > something like the following, on the *gateway* mail server:
                      >
                      > smtpd_recipient_restrictions = permit_mynetworks,
                      > reject_unverified_recipient, reject_unauth_destination

                      Typically the order would be
                      smtpd_recipient_restrictions =
                      permit_mynetworks
                      reject_unauth_destination
                      (local UCE controls)
                      reject_unverified_recipient

                      ie. do the "expensive" recipient verification as late as possible
                      - -- it should always be after "permit_mynetworks,
                      reject_unauth_destination".


                      >
                      > and on the *final destination* (next hop) mail server:
                      >
                      > unverified_recipient_reject_code = 550

                      Yes.

                      > I guess this is what you mean by "active recipient
                      > verification". Right?

                      Yes.

                      > ...and, if so, I guess we *still* need the directive:
                      >
                      > relay_recipient_maps =
                      >
                      > (empty) ??

                      Yes, you'll be using reject_unverified_recipient for all your
                      relay_domains, so the explicit listing isn't needed.


                      -- Noel Jones
                      -----BEGIN PGP SIGNATURE-----
                      Version: GnuPG v2.0.17 (MingW32)
                      Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

                      iQEcBAEBAgAGBQJOZPZAAAoJEJGRUHb5Oh6gncwH/j8RbF9z0uK8Q0mLk03ll7cS
                      ix+pFl5o8ZEYZZi3HsEZag9kJKpVZkjDJH73m4SCTGW+v69eEyK9oieWoTAYiVv+
                      XSzaUKzHXqU2eis5NcrJlRZ18j5X65YrZgAaExXULdcwScKRvI6q2x0KVr6E4jIi
                      Jc7AzhNBcy9+z/uMEuFG4ODc2iYOtI0mN9O4LxlbKa5Ql8cbgwxKWIoQuWQHuLOF
                      j/lsWVrQrNKgQLrWjjJfPftyt+iFv1HARJQ8fedpxJPMd3OGdT0zwNF0vP0Vezus
                      hKiAWBasmPdLevWePEvg2olrZlY4adw91JALghaK0gsDSmur8//4gwbd4/NrBQg=
                      =g4f9
                      -----END PGP SIGNATURE-----
                    • Nikolaos Milas
                      Thanks to Noel (and to the Postfix community in general) for the guidance, my mail gateway is now running (still in test mode), together with spamassassin,
                      Message 10 of 20 , Sep 9, 2011
                      • 0 Attachment
                        Thanks to Noel (and to the Postfix community in general) for the
                        guidance, my mail gateway is now running (still in test mode), together
                        with spamassassin, clamav and amavis-new.

                        Now, one more thing:

                        Since this is just a relay, mail is not stored locally; yet, I would
                        like to train spamassassin (if that makes any sense! - any
                        advice/experience on spamassassin training?) which requires local
                        directories of spam and non-spam. So I was thinking I should configure
                        postfix/spamassassin to keep local copies of spam (to be also available
                        for checking using IMAP) and non-spam mail so as to make training feasible.

                        Another option is to disable spamassassin entirely on the gateway server
                        and install/use it on the internal (final) mail server (used as outgoing
                        gateway and internal POP/IMAP).

                        At the moment, I would prefer to use the former approach, as it fits
                        better in our current mail receiving "architecture".

                        Any advice?

                        Also, to disable sending outgoing mails from this server (which is only
                        there to receive mail from the Internet as MX-designated mail server and
                        work as a local relay to internal mail server) I am planning to use the
                        setting:

                        mynetworks = <empty>

                        Would this have any impact on the relay role of the server; which means:
                        would relaying of relay_domains as defined in transport_maps be
                        inhibited in any way)? I believe no, but I am asking, just in case?

                        Thanks,
                        Nick
                      • Wietse Venema
                        ... mynetworks is used by the permit_mynetworks feature. If you don t use permit_mynetworks at all (check with: postconf | grep permit_mynetworks ), then
                        Message 11 of 20 , Sep 9, 2011
                        • 0 Attachment
                          Nikolaos Milas:
                          > Also, to disable sending outgoing mails from this server (which is only
                          > there to receive mail from the Internet as MX-designated mail server and
                          > work as a local relay to internal mail server) I am planning to use the
                          > setting:
                          >
                          > mynetworks = <empty>
                          >
                          > Would this have any impact on the relay role of the server; which means:
                          > would relaying of relay_domains as defined in transport_maps be
                          > inhibited in any way)? I believe no, but I am asking, just in case?

                          mynetworks is used by the permit_mynetworks feature.

                          If you don't use permit_mynetworks at all (check with: "postconf |
                          grep permit_mynetworks"), then mynetworks can be empty.

                          To allow mail from local programs that send SMTP mail through the
                          loopback interface, you could set one of the following:

                          mynetworks = 127.0.0.1/32
                          mynetworks = 127.0.0.1/32 [::1]/128

                          Wietse
                        • Nikolaos Milas
                          ... Thanks Wietsie, mynetworks = 127.0.0.1/32 [::1]/128 seems the right solution. In fact I am using permit_mynetworks as the first entry in
                          Message 12 of 20 , Sep 9, 2011
                          • 0 Attachment
                            On 9/9/2011 4:00 μμ, Wietse Venema wrote:

                            > If you don't use permit_mynetworks at all (check with: "postconf |
                            > grep permit_mynetworks"), then mynetworks can be empty.

                            Thanks Wietsie,

                            mynetworks = 127.0.0.1/32 [::1]/128

                            seems the right solution.

                            In fact I am using permit_mynetworks as the first entry in
                            smtpd_recipient_resctrictions. It seems it doesn't make any sense there,
                            so I can remove it?

                            Also, should the above mynetworks setting cover postscreen needs (since
                            postscreen_access_list = permit_mynetworks)?

                            # postconf | grep permit_mynetworks
                            postscreen_access_list = permit_mynetworks
                            smtpd_recipient_restrictions = permit_mynetworks,
                            reject_unauth_destination, reject_invalid_hostname,
                            reject_unauth_pipelining, reject_non_fqdn_sender,
                            reject_unknown_sender_domain, reject_non_fqdn_recipient,
                            reject_unknown_recipient_domain, reject_unverified_recipient,
                            reject_rbl_client b.barracudacentral.org, reject_rbl_client
                            zen.spamhaus.org, reject_rbl_client psbl.surriel.com,
                            reject_rhsbl_client dbl.spamhaus.org, reject_rhsbl_sender
                            dbl.spamhaus.org, reject_rhsbl_helo dbl.spamhaus.org, permit

                            Also:

                            # postconf | grep postscreen
                            postscreen_access_list = permit_mynetworks
                            postscreen_bare_newline_action = ignore
                            postscreen_bare_newline_enable = no
                            postscreen_bare_newline_ttl = 30d
                            postscreen_blacklist_action = ignore
                            postscreen_cache_cleanup_interval = 12h
                            postscreen_cache_map = btree:$data_directory/postscreen_cache
                            postscreen_cache_retention_time = 7d
                            postscreen_client_connection_count_limit =
                            $smtpd_client_connection_count_limit
                            postscreen_command_count_limit = 20
                            postscreen_command_filter =
                            postscreen_command_time_limit = ${stress?10}${stress:300}s
                            postscreen_disable_vrfy_command = $disable_vrfy_command
                            postscreen_discard_ehlo_keyword_address_maps =
                            $smtpd_discard_ehlo_keyword_address_maps
                            postscreen_discard_ehlo_keywords = $smtpd_discard_ehlo_keywords
                            postscreen_dnsbl_action = enforce
                            postscreen_dnsbl_reply_map =
                            postscreen_dnsbl_sites = b.barracudacentral.org*2, zen.spamhaus.org*2,
                            psbl.surriel.com*2
                            postscreen_dnsbl_threshold = 2
                            postscreen_dnsbl_ttl = 1h
                            postscreen_enforce_tls = $smtpd_enforce_tls
                            postscreen_expansion_filter = $smtpd_expansion_filter
                            postscreen_forbidden_commands = $smtpd_forbidden_commands
                            postscreen_greet_action = enforce
                            postscreen_greet_banner = $smtpd_banner
                            postscreen_greet_ttl = 1d
                            postscreen_greet_wait = ${stress?2}${stress:6}s
                            postscreen_helo_required = $smtpd_helo_required
                            postscreen_non_smtp_command_action = drop
                            postscreen_non_smtp_command_enable = no
                            postscreen_non_smtp_command_ttl = 30d
                            postscreen_pipelining_action = enforce
                            postscreen_pipelining_enable = no
                            postscreen_pipelining_ttl = 30d
                            postscreen_post_queue_limit = $default_process_limit
                            postscreen_pre_queue_limit = $default_process_limit
                            postscreen_reject_footer = $smtpd_reject_footer
                            postscreen_tls_security_level = $smtpd_tls_security_level
                            postscreen_use_tls = $smtpd_use_tls
                            postscreen_watchdog_timeout = 10s

                            Thanks,
                            Nick
                          • Wietse Venema
                            ... See my previous reply. If you need to run programs that send mail via 127.0.0.1 or [::1], then you need permit_mynetworks. Wietse
                            Message 13 of 20 , Sep 9, 2011
                            • 0 Attachment
                              Nikolaos Milas:
                              > On 9/9/2011 4:00 ??, Wietse Venema wrote:
                              >
                              > > If you don't use permit_mynetworks at all (check with: "postconf |
                              > > grep permit_mynetworks"), then mynetworks can be empty.
                              >
                              > Thanks Wietsie,
                              >
                              > mynetworks = 127.0.0.1/32 [::1]/128
                              >
                              > seems the right solution.
                              >
                              > In fact I am using permit_mynetworks as the first entry in
                              > smtpd_recipient_resctrictions. It seems it doesn't make any sense there,
                              > so I can remove it?

                              See my previous reply. If you need to run programs that send mail
                              via 127.0.0.1 or [::1], then you need permit_mynetworks.

                              Wietse
                            • Nikolaos Milas
                              ... Can we configure the gateway mail server (postfix) to keep local copies of mail messages while relaying them or this should be done using other means e.g.
                              Message 14 of 20 , Sep 9, 2011
                              • 0 Attachment
                                On 9/9/2011 3:14 μμ, Nikolaos Milas wrote:

                                > Since this is just a relay, mail is not stored locally;
                                > ...
                                > So I was thinking I should configure postfix/spamassassin to keep
                                > local copies of spam (to be also available for checking using IMAP)
                                > and non-spam mail so as to make training feasible.

                                Can we configure the gateway mail server (postfix) to keep local copies
                                of mail messages while relaying them or this should be done using other
                                means e.g. some plugin?

                                I think always_bcc would not be relevant in this context.

                                Thanks,
                                Nick
                              • jeffrey j donovan
                                ... Greetings, use local recipient map for your local users and transport maps for the delivery of others. You will have to tell amavisd how to relay local and
                                Message 15 of 20 , Sep 9, 2011
                                • 0 Attachment
                                  On Sep 9, 2011, at 10:28 AM, Nikolaos Milas wrote:

                                  > On 9/9/2011 3:14 μμ, Nikolaos Milas wrote:
                                  >
                                  >> Since this is just a relay, mail is not stored locally;
                                  >> ...
                                  >> So I was thinking I should configure postfix/spamassassin to keep local copies of spam (to be also available for checking using IMAP) and non-spam mail so as to make training feasible.
                                  >
                                  > Can we configure the gateway mail server (postfix) to keep local copies of mail messages while relaying them or this should be done using other means e.g. some plugin?
                                  >
                                  > I think always_bcc would not be relevant in this context.
                                  >
                                  > Thanks,
                                  > Nick
                                  >

                                  Greetings,
                                  use local recipient map for your local users and transport maps for the delivery of others. You will have to tell amavisd how to relay local and remote.
                                  do what Weiste said and allow programs to relay mail via localhost.
                                  -j
                                • Nikolaos Milas
                                  ... Thanks Jeffrey, I guess we could (??) also (if not using local agent) use virtual_mailbox_domains = gatewayhostrname.example.com and virtual_mailbox_maps =
                                  Message 16 of 20 , Sep 9, 2011
                                  • 0 Attachment
                                    On 9/9/2011 5:52 μμ, jeffrey j donovan wrote:

                                    > use local recipient map for your local users and transport maps for the delivery of others. You will have to tell amavisd how to relay local and remote.
                                    > do what Weiste said and allow programs to relay mail via localhost.

                                    Thanks Jeffrey,

                                    I guess we could (??) also (if not using local agent) use

                                    virtual_mailbox_domains = gatewayhostrname.example.com

                                    and

                                    virtual_mailbox_maps = ...

                                    for "virtualized" "local" users to define mailboxes on the gateway mail
                                    server - which is the localhost of course - for local delivery using the
                                    postfix virtual agent (to addresses of the form
                                    xxxxx@...).

                                    But could you give any details (or at least a start point for
                                    researching) on how to tell amavis to generate mail copies and address
                                    them to one destination if they have been designated as spam and to
                                    another destination if they have been designated as non-spam and then
                                    handle them to postfix for delivery to the above addresses? (I know this
                                    is more related to amavis, yet not off-topic.)

                                    Thanks again,
                                    Nick
                                  Your message has been successfully submitted and would be delivered to recipients shortly.