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

Another sanity check request

Expand Messages
  • Russell Jones
    Hi all, Upgrading mail server from Postfix 2.9 to 2.10. Could I get a quick sanity check to ensure my (fairly simple) setup is sane with the new
    Message 1 of 12 , Apr 13, 2013
    • 0 Attachment
      Hi all,

      Upgrading mail server from Postfix 2.9 to 2.10. Could I get a quick
      sanity check to ensure my (fairly simple) setup is sane with the new
      smtpd_relay_restrictions? Thanks :-)

      smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
      reject_unauth_destination
      smtpd_recipient_restrictions = permit_mynetworks
      permit_sasl_authenticated check_client_access
      hash:/etc/postfix/rbl_override reject_rbl_client zen.spamhaus.org


      Also, just as a sanity check on my own understanding of this option
      being split into two now.... The relay_restrictions section is pretty
      self-explanatory, however in the docs it recommends also keeping
      permit_mynetworks and permit_sasl_authenticated in the
      recipient_restrictions section to exclude those clients from RBL
      lookups. This would only come into play when a user of the server is
      sending mail to another local user on the box, correct?


      Thanks again for the help!
    • Reindl Harald
      ... if your setup was safe before it is now also and with the new default a litle more in doubt ... smtpd_relay_restrictions = permit_mynetworks,
      Message 2 of 12 , Apr 13, 2013
      • 0 Attachment
        Am 13.04.2013 21:33, schrieb Russell Jones:
        > Hi all,
        >
        > Upgrading mail server from Postfix 2.9 to 2.10. Could I get a quick sanity check to ensure my (fairly simple) setup
        > is sane with the new smtpd_relay_restrictions? Thanks :-)

        if your setup was safe before it is now also and with the new default a litle more in doubt

        > smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination

        smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination
        works fine with in combination with "smtpd_recipient_restrictions"

        > smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access
        > hash:/etc/postfix/rbl_override reject_rbl_client zen.spamhaus.org

        i would ALWAYS include "reject_unauth_destination" BEFORE "check_client_access" here
      • btb@...
        ... really, neither of permit_mynetworks nor permit_sasl_authenticated belong in any global restrictions. smtp auth [e.g sasl] is for submission clients,
        Message 3 of 12 , Apr 13, 2013
        • 0 Attachment
          On Apr 13, 2013, at 15.33, Russell Jones <russell@...> wrote:

          > Hi all,
          >
          > Upgrading mail server from Postfix 2.9 to 2.10. Could I get a quick sanity check to ensure my (fairly simple) setup is sane with the new smtpd_relay_restrictions? Thanks :-)
          >
          > smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
          > smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/rbl_override reject_rbl_client zen.spamhaus.org

          really, neither of permit_mynetworks nor permit_sasl_authenticated belong in any global restrictions. smtp auth [e.g sasl] is for submission clients, which should be using submission/587, and these days, i really just discourage use of permit_mynetworks altogether.

          -ben
        • Reindl Harald
          ... fine - in the real life you start not from scratch have fun calling hundrets and thousands of users especially with broken clients like a iPhone and
          Message 4 of 12 , Apr 13, 2013
          • 0 Attachment
            Am 13.04.2013 21:42, schrieb btb@...:
            >
            > On Apr 13, 2013, at 15.33, Russell Jones <russell@...> wrote:
            >
            >> Hi all,
            >>
            >> Upgrading mail server from Postfix 2.9 to 2.10. Could I get a quick sanity check to ensure my (fairly simple) setup is sane with the new smtpd_relay_restrictions? Thanks :-)
            >>
            >> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
            >> smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/rbl_override reject_rbl_client zen.spamhaus.org
            >
            > really, neither of permit_mynetworks nor permit_sasl_authenticated belong in any global restrictions.
            > smtp auth [e.g sasl] is for submission clients, which should be using submission/587, and these days,

            fine - in the real life you start not from scratch

            have fun calling hundrets and thousands of users especially with broken
            clients like a iPhone and explain them what to do to change the port

            in a perfect world i would even close port 25 from the WAN because
            the MX is a dedicated spam-firewall, but as said above this world
            exists mostly only if you are a startup with no existing customers

            > i really just discourage use of permit_mynetworks altogether

            if you are not stupid enough to add a /24 network there it is pretty fine
            you do not want to pass every internal server sending a system-message to
            check_recipient_access which may be a spam-filter
          • Russell Jones
            ... Thanks Reindl! It was before, however I read on the Postfix docs that reject_unauth_destination is no longer necessary in the recipient_restrictions
            Message 5 of 12 , Apr 13, 2013
            • 0 Attachment

              On 4/13/2013 2:39 PM, Reindl Harald wrote:
              i would ALWAYS include "reject_unauth_destination" BEFORE "check_client_access" here


              Thanks Reindl!

              It was before, however I read on the Postfix docs that reject_unauth_destination is no longer necessary in the recipient_restrictions section, hence why I removed it. Is it considered better practice to leave it in place?

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

              # reject_unauth_destination is not needed here if the mail
              	# relay policy is specified under smtpd_relay_restrictions
              	# (available with Postfix 2.10 and later)
              
              
              > really, neither of permit_mynetworks nor permit_sasl_authenticated belong in any global restrictions.  
              smtp auth [e.g sasl] is for submission clients, which should be using submission/587, and these days,
              
              
              This is contrary to what is in the docs as an example, however I have port 25 closed off in master.cf to prevent authentication anyway. 587 is the only port I permit authenticated relaying against.
              
              smtpd -o smtpd_sasl_auth_enable=no 
              
              
              
              
              
            • btb@...
              ... in the real world, both [and more] things happen. ... perhaps, perhaps not. ... huh? ... sorry, i have no idea what you re talking about.
              Message 6 of 12 , Apr 13, 2013
              • 0 Attachment
                On Apr 13, 2013, at 15.48, Reindl Harald <h.reindl@...> wrote:

                >
                > Am 13.04.2013 21:42, schrieb btb@...:
                >>
                >> On Apr 13, 2013, at 15.33, Russell Jones <russell@...> wrote:
                >>
                >>> Hi all,
                >>>
                >>> Upgrading mail server from Postfix 2.9 to 2.10. Could I get a quick sanity check to ensure my (fairly simple) setup is sane with the new smtpd_relay_restrictions? Thanks :-)
                >>>
                >>> smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
                >>> smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access hash:/etc/postfix/rbl_override reject_rbl_client zen.spamhaus.org
                >>
                >> really, neither of permit_mynetworks nor permit_sasl_authenticated belong in any global restrictions.
                >> smtp auth [e.g sasl] is for submission clients, which should be using submission/587, and these days,
                >
                > fine - in the real life you start not from scratch

                in the real world, both [and more] things happen.

                > have fun calling hundrets and thousands of users especially with broken
                > clients like a iPhone and explain them what to do to change the port

                perhaps, perhaps not.

                > in a perfect world i would even close port 25 from the WAN because
                > the MX is a dedicated spam-firewall, but as said above this world
                > exists mostly only if you are a startup with no existing customers

                huh?

                >> i really just discourage use of permit_mynetworks altogether
                >
                > if you are not stupid enough to add a /24 network there it is pretty fine
                > you do not want to pass every internal server sending a system-message to
                > check_recipient_access which may be a spam-filter

                sorry, i have no idea what you're talking about.
              • Reindl Harald
                ... and another in the subject is a clear sign ... you forgot you mendtioned remove SASL from port 25? ... that your discourage use of permit_mynetworks is
                Message 7 of 12 , Apr 13, 2013
                • 0 Attachment
                  Am 13.04.2013 22:36, schrieb btb@...:
                  >> fine - in the real life you start not from scratch
                  >
                  > in the real world, both [and more] things happen.

                  and "another" in the subject is a clear sign

                  >> have fun calling hundrets and thousands of users especially with broken
                  >> clients like a iPhone and explain them what to do to change the port
                  >
                  > perhaps, perhaps not.
                  >
                  >> in a perfect world i would even close port 25 from the WAN because
                  >> the MX is a dedicated spam-firewall, but as said above this world
                  >> exists mostly only if you are a startup with no existing customers
                  >
                  > huh?

                  you forgot you mendtioned remove SASL from port 25?

                  >>> i really just discourage use of permit_mynetworks altogether
                  >>
                  >> if you are not stupid enough to add a /24 network there it is pretty fine
                  >> you do not want to pass every internal server sending a system-message to
                  >> check_recipient_access which may be a spam-filter
                  >
                  > sorry, i have no idea what you're talking about

                  that your "discourage use of permit_mynetworks" is far from reality as
                  also "do not use SASAL and submission on port 25" as well if someone
                  asks for ANOTHER sanity check after upgrade to a new version?
                • btb@...
                  ... you offer no service whatsoever on port 25? postfix is not listening on that port? if that s truly the case, then, to be pedantic, you re running an msa,
                  Message 8 of 12 , Apr 13, 2013
                  • 0 Attachment
                    On Apr 13, 2013, at 16.03, Russell Jones <russell@...> wrote:

                    > > really, neither of permit_mynetworks nor permit_sasl_authenticated belong in any global restrictions.
                    > smtp auth [e.g sasl] is for submission clients, which should be using submission/587, and these days,
                    >
                    >
                    > This is contrary to what is in the docs as an example, however I have port 25 closed off in master.cf to prevent authentication anyway. 587 is the only port I permit authenticated relaying against.

                    you offer no service whatsoever on port 25? postfix is not listening on that port? if that's truly the case, then, to be pedantic, you're running an msa, not an mta, in which case you could argue that is an exception to the rule, and such global settings wouldn't necessarily be discouraged.

                    > smtpd -o smtpd_sasl_auth_enable=no

                    i'm confused. if you are still listening on port 25, and have set an override in master.cf to disable sasl, then there is no reason for including the aforementioned restrictions in the global restrictions anyway. by leaving them in there, all you're doing is unnecessarily increasing the risk, should somehow, for some unexpected reason, sasl be enabled [yes, stranger things have happened, even to reasonably responsible admins]. also, i'd note that from a security perspective, that approach is backwards. globally, smtpd_sasl_auth_enable should be off, and only enabled for the specific services in master.cf which require it.

                    -ben
                  • btb@...
                    ... i m not sure why it seems to be so hard for you to differentiate between suggestions as to what would be good to do and what may or may not be easy or
                    Message 9 of 12 , Apr 13, 2013
                    • 0 Attachment
                      On Apr 13, 2013, at 16.40, Reindl Harald <h.reindl@...> wrote:
                      >
                      > that your "discourage use of permit_mynetworks" is far from reality as
                      > also "do not use SASAL and submission on port 25" as well if someone
                      > asks for ANOTHER sanity check after upgrade to a new version?

                      i'm not sure why it seems to be so hard for you to differentiate between suggestions as to what would be good to do and what may or may not be easy or hard, given a particular set of circumstances. "reality" takes care of itself. do we really need to attach "reality" disclaimers every time someone makes a suggestion that someone, somewhere, might consider impractical to implement? let's please focus on more useful discussion.

                      -ben
                    • Russell Jones
                      ... I do and I am offering SASL services, let me clarify. It might be useful if I just include what the line looks like. This isn t what I was asking about in
                      Message 10 of 12 , Apr 13, 2013
                      • 0 Attachment
                        On 4/13/2013 3:44 PM, btb@... wrote:
                        > you offer no service whatsoever on port 25? postfix is not listening on that port? if that's truly the case, then, to be pedantic, you're running an msa, not an mta, in which case you could argue that is an exception to the rule, and such global settings wouldn't necessarily be discouraged.

                        I do and I am offering SASL services, let me clarify. It might be useful
                        if I just include what the line looks like. This isn't what I was asking
                        about in my original email, and has been working fine for quite some
                        time, but just for clarification on this subject for others reading
                        here's the config:

                        1.2.3.4:smtp inet n - n - - smtpd -o
                        smtpd_sasl_auth_enable=no -o smtpd_tls_key_file=/etc/postfix/mail.key -o
                        smtpd_tls_cert_file=/etc/postfix/mail.crt -o myhostname=mail.server.com
                        1.2.3.4:submission inet n - n - - smtpd -o
                        smtpd_sasl_auth_enable=yes -o smtpd_tls_key_file=/etc/postfix/mail.key
                        -o smtpd_tls_cert_file=/etc/postfix/mail.crt -o myhostname=mail.server.com


                        I want only servers talking to port 25, not clients. Hence why I do not
                        permit authentication against the smtp port, only the submission port.
                        Then, in the smtpd_relay_restrictions, I permit authenticated clients to
                        relay.


                        > globally, smtpd_sasl_auth_enable should be off, and only enabled for
                        the specific services in master.cf which require it.

                        It is.


                        > really, neither of permit_mynetworks nor permit_sasl_authenticated
                        belong in any global restrictions.

                        Still confused as to why permit_sasl_authenticated shouldn't be in the
                        smtpd_relay/recipient_restrictions section. Is there a better place to
                        define smtpd_relay/recipients configuration instead of main.cf?
                      • btb@...
                        ... this does offer clarity, yes. in the context of my comments, as long as you do not set smtpd_sasl_auth_enable in main.cf, it s not strictly necessary to
                        Message 11 of 12 , Apr 13, 2013
                        • 0 Attachment
                          On Apr 13, 2013, at 17.10, Russell Jones <russell@...> wrote:

                          >
                          > On 4/13/2013 3:44 PM, btb@... wrote:
                          >> you offer no service whatsoever on port 25? postfix is not listening on that port? if that's truly the case, then, to be pedantic, you're running an msa, not an mta, in which case you could argue that is an exception to the rule, and such global settings wouldn't necessarily be discouraged.
                          >
                          > I do and I am offering SASL services, let me clarify. It might be useful if I just include what the line looks like. This isn't what I was asking about in my original email, and has been working fine for quite some time, but just for clarification on this subject for others reading here's the config:
                          >
                          > 1.2.3.4:smtp inet n - n - - smtpd -o smtpd_sasl_auth_enable=no -o smtpd_tls_key_file=/etc/postfix/mail.key -o smtpd_tls_cert_file=/etc/postfix/mail.crt -o myhostname=mail.server.com
                          > 1.2.3.4:submission inet n - n - - smtpd -o smtpd_sasl_auth_enable=yes -o smtpd_tls_key_file=/etc/postfix/mail.key -o smtpd_tls_cert_file=/etc/postfix/mail.crt -o myhostname=mail.server.com

                          this does offer clarity, yes. in the context of my comments, as long as you do not set smtpd_sasl_auth_enable in main.cf, it's not strictly necessary to set smtpd_sasl_auth_enable=no for the smtp service. the compiled in default will be used. that said, it's not really hurting anything, and could be argued to be an extra layer of security, lest something weird happen [but let's please not debate that].

                          > I want only servers talking to port 25, not clients. Hence why I do not permit authentication against the smtp port, only the submission port. Then, in the smtpd_relay_restrictions, I permit authenticated clients to relay.
                          >
                          >
                          > > globally, smtpd_sasl_auth_enable should be off, and only enabled for the specific services in master.cf which require it.
                          >
                          > It is.
                          >
                          >
                          > > really, neither of permit_mynetworks nor permit_sasl_authenticated belong in any global restrictions.
                          >
                          > Still confused as to why permit_sasl_authenticated shouldn't be in the smtpd_relay/recipient_restrictions section. Is there a better place to define smtpd_relay/recipients configuration instead of main.cf?

                          in my opinion, the better place is in master.cf, for only the desired service [e.g. submission]. to go a step further, cases like this can make good use of restriction classes, so you can keep the majority of settings and activity in main.cf - e.g.:

                          main.cf:
                          smtpd_restriction_classes =
                          base_recipient_restrictions,
                          submission_recipient_restrictions

                          base_recipient_restrictions =
                          reject_non_fqdn_sender,
                          reject_unknown_sender_domain,
                          reject_non_fqdn_recipient,
                          reject_unknown_recipient_domain,
                          reject_unauth_pipelining

                          submission_recipient_restrictions =
                          base_recipient_restrictions,
                          permit_sasl_authenticated,
                          reject

                          master.cf:
                          submission inet n - n - - smtpd
                          -o smtpd_sasl_auth_enable=yes
                          -o smtpd_recipient_restrictions=submission_recipient_restrictions
                          -o smtpd_tls_key_file=/etc/postfix/mail.key
                          -o smtpd_tls_cert_file=/etc/postfix/mail.crt
                          -o smtpd_tls_security_level=encrypt
                          -o myhostname=mail.server.com

                          refer to the documentation and examples for more specifics on the submission service, especially the other example overrides.

                          -ben
                        • mouss
                          ... this would come to play for mail sent from mynetworks or by an authenticated user. if you have completely separate services for MX and submission,
                          Message 12 of 12 , Apr 14, 2013
                          • 0 Attachment
                            Le 13/04/2013 21:33, Russell Jones a écrit :
                            > Hi all,
                            >
                            > Upgrading mail server from Postfix 2.9 to 2.10. Could I get a quick
                            > sanity check to ensure my (fairly simple) setup is sane with the new
                            > smtpd_relay_restrictions? Thanks :-)
                            >
                            > smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated
                            > reject_unauth_destination
                            > smtpd_recipient_restrictions = permit_mynetworks
                            > permit_sasl_authenticated check_client_access
                            > hash:/etc/postfix/rbl_override reject_rbl_client zen.spamhaus.org
                            >
                            >
                            > Also, just as a sanity check on my own understanding of this option
                            > being split into two now.... The relay_restrictions section is pretty
                            > self-explanatory, however in the docs it recommends also keeping
                            > permit_mynetworks and permit_sasl_authenticated in the
                            > recipient_restrictions section to exclude those clients from RBL
                            > lookups. This would only come into play when a user of the server is
                            > sending mail to another local user on the box, correct?
                            >

                            "this would" "come to play" for mail sent from mynetworks or by an
                            authenticated user.

                            if you have completely separate services for MX and submission, then you
                            can remove these two permit from your smtpd_restrictions and from your
                            smtpd_relay_restrictions. In the case where the same postfix instance
                            is used for MX and submission, make sure to specify the restrictions
                            that will be used for submission. something along the lines:

                            submission inet n - n - - smtpd
                            -o smtpd_sasl_auth_enable=yes
                            -o syslog_name=${submission_syslog_name}
                            -o cleanup_service_name=cleanmsa
                            -o myhostname=${submission_myhostname}
                            -o smtpd_tls_security_level=${submission_tls_security_level}
                            -o smtpd_client_restrictions=${submission_client_restrictions}
                            -o smtpd_helo_restrictions=${submission_helo_restrictions}
                            -o smtpd_sender_restrictions=${submission_sender_restrictions}
                            -o smtpd_recipient_restrictions=${submission_recipient_restrictions}
                            -o smtpd_relay_restrictions=${submission_relay_restrictions}
                            -o content_filter=${submission_content_filter}
                            -o receive_override_options=no_address_mappings

                            cleanmsa unix n - n - 0 cleanup
                            -o syslog_name=${submission_syslog_name}
                            -o header_checks=${submission_header_checks}
                            -o mime_header_checks=${submission_mime_header_checks}

                            then each submission_mumble is defined in main.cf.
                          Your message has been successfully submitted and would be delivered to recipients shortly.