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

Re: RBLs, submission port, and permit_sasl_authenticated

Expand Messages
  • Noel Jones
    ... I suggest explicitly specify all the smtpd_{client, helo, sender, recipient, relay, data, end_of_data}_restrictions in the master.cf submission service
    Message 1 of 12 , Jan 8, 2013
    • 0 Attachment
      On 1/8/2013 5:38 PM, Quanah Gibson-Mount wrote:
      > So, with the breakout in Postfix 2.10 for smtpd_relay_restrictions
      > and smtpd_recipient_restrictions, I seem to have goofed in relation
      > to RBLs and the submission port.
      >
      > Right now, we have RBLs added to smtpd_recipient_restrictions. In
      > smtpd_relay_restrictions, I have permit_sasl_authenticated.

      I suggest explicitly specify all the smtpd_{client, helo, sender,
      recipient, relay, data, end_of_data}_restrictions in the master.cf
      submission service definition to prevent surprises -- most of these
      would be set to empty.

      That way there won't be any RBLs anywhere on the submission port,
      regardless of what happens in main.cf.

      If email is submitted on port 25, you would need to add
      permit_sasl_authenticated to every used smtpd_*_restrictions.


      -- Noel Jones
    • Quanah Gibson-Mount
      --On Tuesday, January 08, 2013 3:38 PM -0800 Quanah Gibson-Mount ... Thanks Noel and Patrick for the responses. I accidentally deleted them when removing the
      Message 2 of 12 , Jan 9, 2013
      • 0 Attachment
        --On Tuesday, January 08, 2013 3:38 PM -0800 Quanah Gibson-Mount
        <quanah@...> wrote:

        > Should I have RBLs in smtpd_relay_restrictions instead? Or should I have
        > moved permit_sasl_authenticated into smtpd_recipient_restrictions? Or
        > something else entirely?

        Thanks Noel and Patrick for the responses. I accidentally deleted them
        when removing the thread on destination_rate_delay, but grabbed them from
        the archives.

        For port 465, should I do the same thing as with the submission port, i.e.,
        clear out permit_{client, helo, sender, recipient, relay, data,
        end_of_data}_restrictions as necessary?

        --Quanah


        --

        Quanah Gibson-Mount
        Sr. Member of Technical Staff
        Zimbra, Inc
        A Division of VMware, Inc.
        --------------------
        Zimbra :: the leader in open source messaging and collaboration
      • Noel Jones
        ... Submission and smtps perform essentially the same function, and should get identical settings, with the obvious addition of tls wrappermode for smtps. --
        Message 3 of 12 , Jan 9, 2013
        • 0 Attachment
          On 1/9/2013 12:26 PM, Quanah Gibson-Mount wrote:
          > --On Tuesday, January 08, 2013 3:38 PM -0800 Quanah Gibson-Mount
          > <quanah@...> wrote:
          >
          >> Should I have RBLs in smtpd_relay_restrictions instead? Or should
          >> I have
          >> moved permit_sasl_authenticated into
          >> smtpd_recipient_restrictions? Or
          >> something else entirely?
          >
          > Thanks Noel and Patrick for the responses. I accidentally deleted
          > them when removing the thread on destination_rate_delay, but grabbed
          > them from the archives.
          >
          > For port 465, should I do the same thing as with the submission
          > port, i.e., clear out permit_{client, helo, sender, recipient,
          > relay, data, end_of_data}_restrictions as necessary?
          >
          > --Quanah

          Submission and "smtps" perform essentially the same function, and
          should get identical settings, with the obvious addition of tls
          wrappermode for smtps.



          -- Noel Jones
        • Quanah Gibson-Mount
          --On Wednesday, January 09, 2013 12:50 PM -0600 Noel Jones ... Perfect, thank you very much! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff
          Message 4 of 12 , Jan 9, 2013
          • 0 Attachment
            --On Wednesday, January 09, 2013 12:50 PM -0600 Noel Jones
            <njones@...> wrote:

            > On 1/9/2013 12:26 PM, Quanah Gibson-Mount wrote:
            >> --On Tuesday, January 08, 2013 3:38 PM -0800 Quanah Gibson-Mount
            >> <quanah@...> wrote:
            >>
            >>> Should I have RBLs in smtpd_relay_restrictions instead? Or should
            >>> I have
            >>> moved permit_sasl_authenticated into
            >>> smtpd_recipient_restrictions? Or
            >>> something else entirely?
            >>
            >> Thanks Noel and Patrick for the responses. I accidentally deleted
            >> them when removing the thread on destination_rate_delay, but grabbed
            >> them from the archives.
            >>
            >> For port 465, should I do the same thing as with the submission
            >> port, i.e., clear out permit_{client, helo, sender, recipient,
            >> relay, data, end_of_data}_restrictions as necessary?
            >>
            >> --Quanah
            >
            > Submission and "smtps" perform essentially the same function, and
            > should get identical settings, with the obvious addition of tls
            > wrappermode for smtps.

            Perfect, thank you very much!

            --Quanah


            --

            Quanah Gibson-Mount
            Sr. Member of Technical Staff
            Zimbra, Inc
            A Division of VMware, Inc.
            --------------------
            Zimbra :: the leader in open source messaging and collaboration
          • Quanah Gibson-Mount
            --On Wednesday, January 09, 2013 10:53 AM -0800 Quanah Gibson-Mount ... Ok, I ve modified my master.cf for the smtpd daemons to the following. Does it appear
            Message 5 of 12 , Jan 17, 2013
            • 0 Attachment
              --On Wednesday, January 09, 2013 10:53 AM -0800 Quanah Gibson-Mount
              <quanah@...> wrote:

              >> Submission and "smtps" perform essentially the same function, and
              >> should get identical settings, with the obvious addition of tls
              >> wrappermode for smtps.
              >
              > Perfect, thank you very much!

              Ok, I've modified my master.cf for the smtpd daemons to the following.
              Does it appear in general, more sane?

              smtp inet n - n - - smtpd
              -o content_filter=scan:[127.0.0.1]:10029
              465 inet n - n - - smtpd
              -o content_filter=scan:[127.0.0.1]:10029
              -o smtpd_tls_wrappermode=yes
              -o smtpd_sasl_auth_enable=yes
              -o smtpd_client_restrictions=
              -o smtpd_data_restrictions=
              -o smtpd_end_of_data_restrictions=
              -o smtpd_helo_restrictions=
              -o smtpd_recipient_restrictions=
              -o smtpd_relay_restrictions=
              -o smtpd_sender_restrictions=
              submission inet n - n - - smtpd
              -o content_filter=scan:[127.0.0.1]:10029
              -o smtpd_etrn_restrictions=reject
              -o smtpd_sasl_auth_enable=yes
              -o smtpd_tls_security_level=may
              -o smtpd_client_restrictions=permit_sasl_authenticated,reject
              -o smtpd_data_restrictions=
              -o smtpd_end_of_data_restrictions=
              -o smtpd_helo_restrictions=
              -o smtpd_recipient_restrictions=
              -o smtpd_relay_restrictions=
              -o smtpd_sender_restrictions=
              [127.0.0.1]:10025 inet n - n - - smtpd
              -o content_filter=
              -o local_recipient_maps=
              -o virtual_mailbox_maps=
              -o virtual_alias_maps=
              -o relay_recipient_maps=
              -o smtpd_restriction_classes=
              -o smtpd_delay_reject=no
              -o smtpd_client_restrictions=permit_mynetworks,reject
              -o smtpd_data_restrictions=
              -o smtpd_end_of_data_restrictions=
              -o smtpd_helo_restrictions=
              -o smtpd_milters=
              -o smtpd_sender_restrictions=
              -o smtpd_relay_restrictions=
              -o smtpd_recipient_restrictions=permit_mynetworks,reject
              -o mynetworks_style=host
              -o mynetworks=127.0.0.0/8,[::1]/128
              -o strict_rfc821_envelopes=yes
              -o smtpd_error_sleep_time=0
              -o smtpd_soft_error_limit=1001
              -o smtpd_hard_error_limit=1000
              -o smtpd_client_connection_count_limit=0
              -o smtpd_client_connection_rate_limit=0
              -o
              receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_address_mappings
              -o local_header_rewrite_clients=
              [127.0.0.1]:10029 inet n - n - - smtpd
              -o content_filter=
              -o local_recipient_maps=
              -o virtual_mailbox_maps=
              -o virtual_alias_maps=
              -o relay_recipient_maps=
              -o smtpd_restriction_classes=
              -o smtpd_delay_reject=no
              -o smtpd_milters=inet:localhost:8465
              -o smtpd_client_restrictions=permit_mynetworks,reject
              -o smtpd_sender_restrictions=
              -o smtpd_helo_restrictions=
              -o smtpd_recipient_restrictions=permit_mynetworks,reject
              -o smtpd_relay_restrictions=
              -o smtpd_data_restrictions=
              -o smtpd_end_of_data_restrictions=

              Thanks!

              --Quanah

              --

              Quanah Gibson-Mount
              Sr. Member of Technical Staff
              Zimbra, Inc
              A Division of VMware, Inc.
              --------------------
              Zimbra :: the leader in open source messaging and collaboration
            • Noel Jones
              ... I don t think postfix will start (or at least won t start this service) with both smtpd_recipient_restricions and smtpd_relay_restrictions set empty. For
              Message 6 of 12 , Jan 17, 2013
              • 0 Attachment
                On 1/17/2013 3:56 PM, Quanah Gibson-Mount wrote:
                > --On Wednesday, January 09, 2013 10:53 AM -0800 Quanah Gibson-Mount
                > <quanah@...> wrote:
                >
                >>> Submission and "smtps" perform essentially the same function, and
                >>> should get identical settings, with the obvious addition of tls
                >>> wrappermode for smtps.
                >>
                >> Perfect, thank you very much!
                >
                > Ok, I've modified my master.cf for the smtpd daemons to the
                > following. Does it appear in general, more sane?
                >
                > smtp inet n - n - - smtpd
                > -o content_filter=scan:[127.0.0.1]:10029
                > 465 inet n - n - - smtpd
                > -o content_filter=scan:[127.0.0.1]:10029
                > -o smtpd_tls_wrappermode=yes
                > -o smtpd_sasl_auth_enable=yes
                > -o smtpd_client_restrictions=
                > -o smtpd_data_restrictions=
                > -o smtpd_end_of_data_restrictions=
                > -o smtpd_helo_restrictions=
                > -o smtpd_recipient_restrictions=
                > -o smtpd_relay_restrictions=

                I don't think postfix will start (or at least won't start this
                service) with both smtpd_recipient_restricions and
                smtpd_relay_restrictions set empty.

                For submission/smtps, one of these needs to be set eg.

                smtpd_relay_restrictions=permit_sasl_authenticated,reject

                It's also customary to set
                -o milter_macro_daemon_name=ORIGINATING
                in case a milter gets put in the loop,

                and I find it very useful to set the syslog name
                -o syslog_name=postfix/smtps
                (similar for postfix/submission).





                -- Noel Jones
              • Quanah Gibson-Mount
                --On Thursday, January 17, 2013 4:12 PM -0600 Noel Jones ... Hi Noel, ... Yeah, I just ran into that in testing the changes in more detail. ... Thanks, done,
                Message 7 of 12 , Jan 17, 2013
                • 0 Attachment
                  --On Thursday, January 17, 2013 4:12 PM -0600 Noel Jones
                  <njones@...> wrote:

                  > On 1/17/2013 3:56 PM, Quanah Gibson-Mount wrote:
                  >> --On Wednesday, January 09, 2013 10:53 AM -0800 Quanah Gibson-Mount
                  >> <quanah@...> wrote:
                  >>
                  >>>> Submission and "smtps" perform essentially the same function, and
                  >>>> should get identical settings, with the obvious addition of tls
                  >>>> wrappermode for smtps.
                  >>>
                  >>> Perfect, thank you very much!
                  >>
                  >> Ok, I've modified my master.cf for the smtpd daemons to the
                  >> following. Does it appear in general, more sane?
                  >>
                  >> smtp inet n - n - - smtpd
                  >> -o content_filter=scan:[127.0.0.1]:10029
                  >> 465 inet n - n - - smtpd
                  >> -o content_filter=scan:[127.0.0.1]:10029
                  >> -o smtpd_tls_wrappermode=yes
                  >> -o smtpd_sasl_auth_enable=yes
                  >> -o smtpd_client_restrictions=
                  >> -o smtpd_data_restrictions=
                  >> -o smtpd_end_of_data_restrictions=
                  >> -o smtpd_helo_restrictions=
                  >> -o smtpd_recipient_restrictions=
                  >> -o smtpd_relay_restrictions=

                  Hi Noel,

                  >
                  > I don't think postfix will start (or at least won't start this
                  > service) with both smtpd_recipient_restricions and
                  > smtpd_relay_restrictions set empty.

                  Yeah, I just ran into that in testing the changes in more detail.

                  > For submission/smtps, one of these needs to be set eg.
                  >
                  > smtpd_relay_restrictions=permit_sasl_authenticated,reject

                  Thanks, done, and it looks much better. ;)

                  > It's also customary to set
                  > -o milter_macro_daemon_name=ORIGINATING
                  > in case a milter gets put in the loop,

                  Ok, that is quite helpful to know.

                  > and I find it very useful to set the syslog name
                  > -o syslog_name=postfix/smtps
                  > (similar for postfix/submission).

                  That's really helpful, thank you. :)

                  --Quanah

                  --

                  Quanah Gibson-Mount
                  Sr. Member of Technical Staff
                  Zimbra, Inc
                  A Division of VMware, Inc.
                  --------------------
                  Zimbra :: the leader in open source messaging and collaboration
                • Quanah Gibson-Mount
                  --On Thursday, January 17, 2013 2:26 PM -0800 Quanah Gibson-Mount ... Hi Noel, With testing, I have the following for 465/submission. Thanks again for the
                  Message 8 of 12 , Jan 17, 2013
                  • 0 Attachment
                    --On Thursday, January 17, 2013 2:26 PM -0800 Quanah Gibson-Mount
                    <quanah@...> wrote:

                    > Hi Noel,
                    >
                    >>
                    >> I don't think postfix will start (or at least won't start this
                    >> service) with both smtpd_recipient_restricions and
                    >> smtpd_relay_restrictions set empty.
                    >
                    > Yeah, I just ran into that in testing the changes in more detail.
                    >
                    >> For submission/smtps, one of these needs to be set eg.
                    >>
                    >> smtpd_relay_restrictions=permit_sasl_authenticated,reject
                    > That's really helpful, thank you. :)

                    Hi Noel,

                    With testing, I have the following for 465/submission. Thanks again for
                    the pointers! I used reject_unauth_destination because with just "reject",
                    some of my mail tests failed.

                    465 inet n - n - - smtpd
                    -o content_filter=scan:[127.0.0.1]:10029
                    -o smtpd_tls_wrappermode=yes
                    -o smtpd_sasl_auth_enable=yes
                    -o smtpd_client_restrictions=
                    -o smtpd_data_restrictions=
                    -o smtpd_end_of_data_restrictions=
                    -o smtpd_helo_restrictions=
                    -o smtpd_recipient_restrictions=
                    -o
                    smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination
                    -o smtpd_sender_restrictions=
                    -o syslog_name=postfix/smtps
                    -o milter_macro_daemon_name=ORIGINATING
                    submission inet n - n - - smtpd
                    -o content_filter=scan:[127.0.0.1]:10029
                    -o smtpd_etrn_restrictions=reject
                    -o smtpd_sasl_auth_enable=yes
                    -o smtpd_tls_security_level=may
                    -o smtpd_client_restrictions=permit_sasl_authenticated,reject
                    -o smtpd_data_restrictions=
                    -o smtpd_end_of_data_restrictions=
                    -o smtpd_helo_restrictions=
                    -o smtpd_recipient_restrictions=
                    -o
                    smtpd_relay_restrictions=permit_sasl_authenticated,reject_unauth_destination
                    -o smtpd_sender_restrictions=
                    -o syslog_name=postfix/submission
                    -o milter_macro_daemon_name=ORIGINATING


                    --Quanah

                    --

                    Quanah Gibson-Mount
                    Sr. Member of Technical Staff
                    Zimbra, Inc
                    A Division of VMware, Inc.
                    --------------------
                    Zimbra :: the leader in open source messaging and collaboration
                  • Noel Jones
                    ... That implies you were sending unauthenticated mail to a local domain via smtps. As a general rule, that s something you want to prevent since it bypasses
                    Message 9 of 12 , Jan 17, 2013
                    • 0 Attachment
                      On 1/17/2013 4:42 PM, Quanah Gibson-Mount wrote:
                      >
                      > With testing, I have the following for 465/submission. Thanks again
                      > for the pointers! I used reject_unauth_destination because with
                      > just "reject", some of my mail tests failed.


                      That implies you were sending unauthenticated mail to a local domain
                      via smtps. As a general rule, that's something you want to prevent
                      since it bypasses all your carefully crafted antispam controls. I
                      have seen a few attempts to deliver spammy-looking unauthenticated
                      mail via smtps/465, haven't noticed it on submission/587 (but never
                      really looked for it).

                      So reject_unauth_destination is OK for testing, but for production I
                      would strongly suggest leaving it at reject.

                      If you need to send unauthenticated mail over smtps/submission on an
                      ongoing basis, you can define a very limited -o mynetworks=...
                      setting and add permit_mynetworks before the reject.



                      -- Noel Jones
                    • Quanah Gibson-Mount
                      --On Thursday, January 17, 2013 10:17 PM -0600 Noel Jones ... Hi Noel, Thanks again. There was a problem with my simple test script (it wasn t actually
                      Message 10 of 12 , Jan 18, 2013
                      • 0 Attachment
                        --On Thursday, January 17, 2013 10:17 PM -0600 Noel Jones
                        <njones@...> wrote:

                        > On 1/17/2013 4:42 PM, Quanah Gibson-Mount wrote:
                        >>
                        >> With testing, I have the following for 465/submission. Thanks again
                        >> for the pointers! I used reject_unauth_destination because with
                        >> just "reject", some of my mail tests failed.
                        >
                        >
                        > That implies you were sending unauthenticated mail to a local domain
                        > via smtps. As a general rule, that's something you want to prevent
                        > since it bypasses all your carefully crafted antispam controls. I
                        > have seen a few attempts to deliver spammy-looking unauthenticated
                        > mail via smtps/465, haven't noticed it on submission/587 (but never
                        > really looked for it).
                        >
                        > So reject_unauth_destination is OK for testing, but for production I
                        > would strongly suggest leaving it at reject.
                        >
                        > If you need to send unauthenticated mail over smtps/submission on an
                        > ongoing basis, you can define a very limited -o mynetworks=...
                        > setting and add permit_mynetworks before the reject.

                        Hi Noel,

                        Thanks again. There was a problem with my simple test script (it wasn't
                        actually authenticating). I fixed that, and "reject" is definitely what I
                        want.

                        --Quanah

                        --

                        Quanah Gibson-Mount
                        Sr. Member of Technical Staff
                        Zimbra, Inc
                        A Division of VMware, Inc.
                        --------------------
                        Zimbra :: the leader in open source messaging and collaboration
                      Your message has been successfully submitted and would be delivered to recipients shortly.