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

Re: smtpd_relay_restrictions

Expand Messages
  • Wietse Venema
    ... With smtpd_client, helo, sender, recipient, and data restrictions, a permit result never skips over other restriction lists. That is a good reason to
    Message 1 of 17 , Sep 28, 2012
    • 0 Attachment
      Michael Storz:
      > If one of the permit-restrictions from smtpd_relay_restrictions fires
      > which restriction will be evaluated next:
      > - the first restriction of smtpd_recipient_restrictions or
      > - the first restriction of smtpd_data_restrictions

      With smtpd_client, helo, sender, recipient, and data restrictions,
      a "permit" result never "skips over" other restriction lists. That
      is a good reason to make relay restrictions behave in the same way.
      It keeps the system consistent, and minimizes the learning curve.

      With smtpd_delay_reject=yes, the basic algorithm is:

      if (eval(restriction_list_1 + permit) == reject
      or eval(restriction_list_2 + permit) == reject
      ..
      or eval(restriction_list_N + permit) == reject)
      reject

      Where "+" is the concatenation operator, and where the sequence of
      "or" clauses is evaluated from left to right and terminates as soon
      as the result is known.

      When people understand how Postfix works, the above is roughly what
      they have in mind. As long as Postfix adheres to this model there
      will be no surprises when smtpd_relay_restrictions is added.

      Wietse
    • Noel Jones
      ... Sounds useful. ... I agree this is a reasonable built-in default. I suppose smtpd_recipient_restrictions will be set empty as its built-in default. ... I
      Message 2 of 17 , Sep 28, 2012
      • 0 Attachment
        On 9/27/2012 4:38 PM, Wietse Venema wrote:
        > Victor discussed smtpd_relay_restrictions 6 years, see
        > http://archives.neohapsis.com/archives/postfix/2006-05/0598.html.
        >
        > The article also discussed a number of other ideas that have potential
        > to increase the Postfix learning curve. I'll leave those for now.
        > My current goal is to make Postfix easier to use by eliminating one
        > opportunity for human error.
        >
        > It seems that smtpd_relay_restrictions can be introduced with little
        > pain, and that it can simplify configuration, with the direct benefit
        > that it would prevent easy-to-make mistakes when all anti-spam
        > features are placed in smtpd_recipient_restrictions.

        Sounds useful.

        >
        > I'm considering the idea to place smtpd_relay_restrictions before
        > smtpd_recipient_restrictions, so that it can eliminate unnecessary
        > work (there is little benefit from querying policy servers or DNSBLs
        > when smtpd_relay_restrictions rejects a recipient).
        >
        > As the built-in default value I consider adopting Victor's suggestion:
        >
        > smtpd_relay_restrictions = permit_mynetworks
        > permit_sasl_authenticated
        > reject_unauth_destination

        I agree this is a reasonable built-in default. I suppose
        smtpd_recipient_restrictions will be set empty as its built-in default.

        >
        > This default setting would almost never need to be changed (by the
        > way, that by itself presents a small usability problem - if people
        > don't need to change this setting then its existence is not obvious).
        >
        > From a user interface point of view there need be no surprises;
        > both smtpd_relay_restrictions and smtpd_recipient_restrictions can
        > behave identically. That reduces the human learning curve, and the
        > effort of implementation and documentation.
        >
        > For usability reasons, I would allow one desirable difference: when
        > smtpd_relay_restrictions contains reject_unauth_destination or
        > reject, then they are not needed in smtpd_recipient_restrictions.
        > This means that sites can avoid a backwards compatibility break
        > simply by setting "smtpd_relay_restrictions =" in main.cf, and get
        > the exact same behavior of previous Postfix versions.
        >
        > Perhaps for the first few years the install procedure should introduce
        > smtpd_relay_restrictions with a safety net, to prevent mail from
        > bouncing unexpectedly:
        >
        > smtpd_relay_restrictions = permit_mynetworks
        > permit_sasl_authenticated
        > permit_auth_destination
        > defer

        I think a better upgrade compatibility shim would be to set
        smtpd_relay_restrictions empty, ie. perform relay checks in
        smtpd_recipient_restrictions as they are now; no behavior change.

        and your proposed safety net looks to me as if it would defer all
        {!mynetworks, !sasl, !auth_destination} mail before
        smtpd_recipient_restrictions is evaluated. This would be surprising
        upgrade behavior.


        -- Noel Jones




        >
        > This is similar to the way that local_recipient_maps was introduced
        > in Postfix 2.0 without unexpectedly bouncing mail after an upgrade.
        >
        > On the other hand the likelihood of breakage is much smaller with
        > smtpd_relay_restrictions than it ever was with local_recipient_maps,
        > so perhaps smtpd_relay_restrictions does not need the temporary
        > safety net.
        >
        > In any case, smtpd_relay_restrictions would feature first in a
        > non-production release so that we can get some experience with it.
        >
        > Wietse
        >
      • Wietse Venema
        Noel Jones: [ Charset ISO-8859-1 unsupported, converting... ] ... Indeed. ... That would not help the transition at all. It would nullify the new parameter,
        Message 3 of 17 , Sep 28, 2012
        • 0 Attachment
          Noel Jones:
          [ Charset ISO-8859-1 unsupported, converting... ]
          > On 9/27/2012 4:38 PM, Wietse Venema wrote:
          > > Victor discussed smtpd_relay_restrictions 6 years, see
          > > http://archives.neohapsis.com/archives/postfix/2006-05/0598.html.
          > >
          > > The article also discussed a number of other ideas that have potential
          > > to increase the Postfix learning curve. I'll leave those for now.
          > > My current goal is to make Postfix easier to use by eliminating one
          > > opportunity for human error.
          > >
          > > It seems that smtpd_relay_restrictions can be introduced with little
          > > pain, and that it can simplify configuration, with the direct benefit
          > > that it would prevent easy-to-make mistakes when all anti-spam
          > > features are placed in smtpd_recipient_restrictions.
          >
          > Sounds useful.
          >
          > >
          > > I'm considering the idea to place smtpd_relay_restrictions before
          > > smtpd_recipient_restrictions, so that it can eliminate unnecessary
          > > work (there is little benefit from querying policy servers or DNSBLs
          > > when smtpd_relay_restrictions rejects a recipient).
          > >
          > > As the built-in default value I consider adopting Victor's suggestion:
          > >
          > > smtpd_relay_restrictions = permit_mynetworks
          > > permit_sasl_authenticated
          > > reject_unauth_destination
          >
          > I agree this is a reasonable built-in default. I suppose
          > smtpd_recipient_restrictions will be set empty as its built-in default.

          Indeed.

          > > This default setting would almost never need to be changed (by the
          > > way, that by itself presents a small usability problem - if people
          > > don't need to change this setting then its existence is not obvious).
          > >
          > > From a user interface point of view there need be no surprises;
          > > both smtpd_relay_restrictions and smtpd_recipient_restrictions can
          > > behave identically. That reduces the human learning curve, and the
          > > effort of implementation and documentation.
          > >
          > > For usability reasons, I would allow one desirable difference: when
          > > smtpd_relay_restrictions contains reject_unauth_destination or
          > > reject, then they are not needed in smtpd_recipient_restrictions.
          > > This means that sites can avoid a backwards compatibility break
          > > simply by setting "smtpd_relay_restrictions =" in main.cf, and get
          > > the exact same behavior of previous Postfix versions.
          > >
          > > Perhaps for the first few years the install procedure should introduce
          > > smtpd_relay_restrictions with a safety net, to prevent mail from
          > > bouncing unexpectedly:
          > >
          > > smtpd_relay_restrictions = permit_mynetworks
          > > permit_sasl_authenticated
          > > permit_auth_destination
          > > defer
          >
          > I think a better upgrade compatibility shim would be to set
          > smtpd_relay_restrictions empty, ie. perform relay checks in
          > smtpd_recipient_restrictions as they are now; no behavior change.

          That would not help the transition at all. It would nullify the new
          parameter, and would merely time-shift the W*T*F bounces that will
          happen when the compatibility shim is removed; it does nothing to
          encourage sites to set up smtpd_relay_restrictions the way they
          want it to be (empty or otherwise) before the new default takes
          effect.

          > and your proposed safety net looks to me as if it would defer all
          > {!mynetworks, !sasl, !auth_destination} mail before
          > smtpd_recipient_restrictions is evaluated. This would be surprising
          > upgrade behavior.

          That is exactly what I want; just like local_recipient_maps, this
          temporary compatibility shim prevents mail from beiing W*T*F bounced,
          so that sites have an opportunity to set up smtpd_relay_restrictions
          the way that they really want it to be (either empty, or otherwise)
          before the shim is removed from the install procedure.

          [an entirely different approach is to have a "config_version"
          parameter in main.cf, but everyone will hate this (me because it
          increases the amount of testing, you because it increases the number
          of configurations that people may have even when they run the latest
          release, and everyone because the documentation will require an
          if-then-else preprocessor to make sense of it all).

          Wietse


          >
          > -- Noel Jones
          >
          >
          >
          >
          > >
          > > This is similar to the way that local_recipient_maps was introduced
          > > in Postfix 2.0 without unexpectedly bouncing mail after an upgrade.
          > >
          > > On the other hand the likelihood of breakage is much smaller with
          > > smtpd_relay_restrictions than it ever was with local_recipient_maps,
          > > so perhaps smtpd_relay_restrictions does not need the temporary
          > > safety net.
          > >
          > > In any case, smtpd_relay_restrictions would feature first in a
          > > non-production release so that we can get some experience with it.
          > >
          > > Wietse
          > >
          >
          >
        • Michael Storz
          ... If smtpd_relay_restrictions behaves like all the other restriction classes, that means after the permit has fired, the first restriction of
          Message 4 of 17 , Sep 28, 2012
          • 0 Attachment
            Am 2012-09-28 14:44, schrieb Wietse Venema:
            > Michael Storz:
            >> If one of the permit-restrictions from smtpd_relay_restrictions
            >> fires
            >> which restriction will be evaluated next:
            >> - the first restriction of smtpd_recipient_restrictions or
            >> - the first restriction of smtpd_data_restrictions
            >
            > With smtpd_client, helo, sender, recipient, and data restrictions,
            > a "permit" result never "skips over" other restriction lists. That
            > is a good reason to make relay restrictions behave in the same way.
            > It keeps the system consistent, and minimizes the learning curve.
            >
            > With smtpd_delay_reject=yes, the basic algorithm is:
            >
            > if (eval(restriction_list_1 + permit) == reject
            > or eval(restriction_list_2 + permit) == reject
            > ..
            > or eval(restriction_list_N + permit) == reject)
            > reject
            >
            > Where "+" is the concatenation operator, and where the sequence of
            > "or" clauses is evaluated from left to right and terminates as soon
            > as the result is known.
            >
            > When people understand how Postfix works, the above is roughly what
            > they have in mind. As long as Postfix adheres to this model there
            > will be no surprises when smtpd_relay_restrictions is added.
            >
            > Wietse

            If smtpd_relay_restrictions behaves like all the other restriction
            classes,
            that means after the permit has fired, the first restriction of
            smtpd_recipient_restrictions is executed, then take the following
            scenario:

            Before introduction of smtpd_relay_restrictions, the restrictions would
            be

            smtpd_recipient_restrictions =
            permit_mynetworks
            permit_sasl_authenticated
            reject_unauth_destination
            uce_restriction1
            ...
            uce_restrictionn

            after the introduction

            smtpd_relay_restrictions =
            permit_mynetworks
            permit_sasl_authenticated
            reject_unauth_destination

            smtpd_recipient_restrictions =
            uce_restriction1
            ...
            uce_restrictionn

            if I understand you correctly. In this case you have a major semantic
            change:
            permitted recipients will be evaluated against the uce_restrictions,
            whereas
            in the old configuration this is not the case.

            Michael
          • Wietse Venema
            ... +---------------------------------+---------------------------------+ ... +---------------------------------+---------------------------------+ ...
            Message 5 of 17 , Sep 28, 2012
            • 0 Attachment
              > smtpd_recipient_restrictions =
              > uce_restriction1
              > ...
              > uce_restrictionn

              +---------------------------------+---------------------------------+
              | In Postfix versions <= 2.9 | In Postfix versions >= 2.10 |
              +---------------------------------+---------------------------------+
              | To exclude a local etc. client | To exclude a local etc. client |
              | from uce_restriction1, place | from uce_restriction1, place |
              | permit_mynetworks etc. before | permit_mynetworks etc. before |
              | it. | it. |
              +---------------------------------+---------------------------------+

              There is no compatibility break. End of discussion. Go have a beer.

              Wietse
            • Noel Jones
              ... No, this is wrong. The new feature means you may *optionally* separate relay decisions from smtpd_recipient_restrictions, providing a little more safety
              Message 6 of 17 , Sep 28, 2012
              • 0 Attachment
                On 9/28/2012 8:37 AM, Michael Storz wrote:
                > Am 2012-09-28 14:44, schrieb Wietse Venema:
                >> Michael Storz:
                > If smtpd_relay_restrictions behaves like all the other restriction
                > classes,
                > that means after the permit has fired, the first restriction of
                > smtpd_recipient_restrictions is executed, then take the following
                > scenario:
                >
                > Before introduction of smtpd_relay_restrictions, the restrictions
                > would be
                >
                > smtpd_recipient_restrictions =
                > permit_mynetworks
                > permit_sasl_authenticated
                > reject_unauth_destination
                > uce_restriction1
                > ...
                > uce_restrictionn
                >
                > after the introduction
                >
                > smtpd_relay_restrictions =
                > permit_mynetworks
                > permit_sasl_authenticated
                > reject_unauth_destination
                >
                > smtpd_recipient_restrictions =
                > uce_restriction1
                > ...
                > uce_restrictionn
                >
                > if I understand you correctly. In this case you have a major
                > semantic change:
                > permitted recipients will be evaluated against the uce_restrictions,
                > whereas
                > in the old configuration this is not the case.
                >
                > Michael
                >


                No, this is wrong. The new feature means you may *optionally*
                separate relay decisions from smtpd_recipient_restrictions,
                providing a little more safety and flexibility than currently
                available. It is not a major semantic change -- IMHO not a semantic
                change at all, just an added feature.


                -- Noel Jones
              • Noel Jones
                ... Thanks for the clarification. Now I see what you intend, and I agree. -- Noel Jones
                Message 7 of 17 , Sep 28, 2012
                • 0 Attachment
                  On 9/28/2012 8:32 AM, Wietse Venema wrote:
                  > Noel Jones:
                  >> I think a better upgrade compatibility shim would be to set
                  >> smtpd_relay_restrictions empty, ie. perform relay checks in
                  >> smtpd_recipient_restrictions as they are now; no behavior change.
                  >
                  > That would not help the transition at all. It would nullify the new
                  > parameter, and would merely time-shift the W*T*F bounces that will
                  > happen when the compatibility shim is removed; it does nothing to
                  > encourage sites to set up smtpd_relay_restrictions the way they
                  > want it to be (empty or otherwise) before the new default takes
                  > effect.
                  >
                  >> and your proposed safety net looks to me as if it would defer all
                  >> {!mynetworks, !sasl, !auth_destination} mail before
                  >> smtpd_recipient_restrictions is evaluated. This would be surprising
                  >> upgrade behavior.
                  >
                  > That is exactly what I want; just like local_recipient_maps, this
                  > temporary compatibility shim prevents mail from beiing W*T*F bounced,
                  > so that sites have an opportunity to set up smtpd_relay_restrictions
                  > the way that they really want it to be (either empty, or otherwise)
                  > before the shim is removed from the install procedure.
                  >
                  > [an entirely different approach is to have a "config_version"
                  > parameter in main.cf, but everyone will hate this (me because it
                  > increases the amount of testing, you because it increases the number
                  > of configurations that people may have even when they run the latest
                  > release, and everyone because the documentation will require an
                  > if-then-else preprocessor to make sense of it all).
                  >
                  > Wietse
                  >


                  Thanks for the clarification. Now I see what you intend, and I agree.


                  -- Noel Jones
                • Michael Storz
                  ... You are right, if smtpd_relay_restrictions is empty and delayed restrictions will only be evaluated in smtpd_recipient_restrictions then there is no
                  Message 8 of 17 , Sep 28, 2012
                  • 0 Attachment
                    Am 2012-09-28 18:39, schrieb Noel Jones:
                    > On 9/28/2012 8:37 AM, Michael Storz wrote:
                    >> Am 2012-09-28 14:44, schrieb Wietse Venema:
                    >>> Michael Storz:
                    >> If smtpd_relay_restrictions behaves like all the other restriction
                    >> classes,
                    >> that means after the permit has fired, the first restriction of
                    >> smtpd_recipient_restrictions is executed, then take the following
                    >> scenario:
                    >>
                    >> Before introduction of smtpd_relay_restrictions, the restrictions
                    >> would be
                    >>
                    >> smtpd_recipient_restrictions =
                    >> permit_mynetworks
                    >> permit_sasl_authenticated
                    >> reject_unauth_destination
                    >> uce_restriction1
                    >> ...
                    >> uce_restrictionn
                    >>
                    >> after the introduction
                    >>
                    >> smtpd_relay_restrictions =
                    >> permit_mynetworks
                    >> permit_sasl_authenticated
                    >> reject_unauth_destination
                    >>
                    >> smtpd_recipient_restrictions =
                    >> uce_restriction1
                    >> ...
                    >> uce_restrictionn
                    >>
                    >> if I understand you correctly. In this case you have a major
                    >> semantic change:
                    >> permitted recipients will be evaluated against the uce_restrictions,
                    >> whereas
                    >> in the old configuration this is not the case.
                    >>
                    >> Michael
                    >>
                    >
                    >
                    > No, this is wrong. The new feature means you may *optionally*
                    > separate relay decisions from smtpd_recipient_restrictions,
                    > providing a little more safety and flexibility than currently
                    > available. It is not a major semantic change -- IMHO not a semantic
                    > change at all, just an added feature.
                    >
                    >
                    > -- Noel Jones

                    You are right, if smtpd_relay_restrictions is empty and delayed
                    restrictions
                    will only be evaluated in smtpd_recipient_restrictions then there is no
                    semantic change.

                    Michael
                  • Viktor Dukhovni
                    ... Nice to see the general idea moving forward, thanks. I d like to make another attempt to sell the complete package. Apart from a possibly tricky
                    Message 9 of 17 , Sep 28, 2012
                    • 0 Attachment
                      On Thu, Sep 27, 2012 at 05:38:20PM -0400, Wietse Venema wrote:

                      > Victor discussed smtpd_relay_restrictions 6 years, see
                      > http://archives.neohapsis.com/archives/postfix/2006-05/0598.html.
                      >
                      > The article also discussed a number of other ideas that have potential
                      > to increase the Postfix learning curve. I'll leave those for now.
                      > My current goal is to make Postfix easier to use by eliminating one
                      > opportunity for human error.

                      Nice to see the general idea moving forward, thanks. I'd like to make
                      another attempt to sell the complete package.

                      Apart from a possibly tricky interaction with the existing
                      smtpd_delay_reject, adding explicit:

                      smtpd_client_restriction_classes = ...
                      smtpd_helo_restriction_classes = ...
                      smtpd_mail_restriction_classes = ...
                      smtpd_rcpt_restriction_classes = ...
                      smtpd_data_restriction_classes = ...
                      smtpd_dot_restriction_classes = ...

                      can I think be backwards compatible since all of these can default
                      empty, and then exhibit legacy behaviour. So the proposal for
                      smtpd_delay_reject is to do away with it when the new parameters
                      are in force. In other words as an example:

                      # Empty? Use legacy behaviour controlled by smtpd_delay_reject
                      #
                      smtpd_rcpt_restriction_classes =

                      # Non-empty, do exactly what the user said:
                      #
                      smtpd_rcpt_restriction_classes =
                      smtpd_relay_restrictions,
                      smtpd_recipient_restrictions

                      This implements the new feature, but makes it completely optional,
                      and gives the user control over ordering and the option to add more
                      classes.

                      --
                      Viktor.
                    • /dev/rob0
                      ... IIUC it will not be possible to have smtpd_relay_restrictions empty. It will be a mandatory setting such as smtpd_recipient_restrictions is now. If
                      Message 10 of 17 , Sep 28, 2012
                      • 0 Attachment
                        On Fri, Sep 28, 2012 at 07:41:22PM +0200, Michael Storz wrote:
                        > > -- Noel Jones
                        > >No, this is wrong. The new feature means you may *optionally*
                        > >separate relay decisions from smtpd_recipient_restrictions,
                        > >providing a little more safety and flexibility than currently
                        > >available. It is not a major semantic change -- IMHO not a
                        > >semantic change at all, just an added feature.
                        >
                        > You are right, if smtpd_relay_restrictions is empty and delayed
                        > restrictions will only be evaluated in smtpd_recipient_restrictions
                        > then there is no semantic change.

                        IIUC it will not be possible to have smtpd_relay_restrictions empty.
                        It will be a mandatory setting such as smtpd_recipient_restrictions
                        is now. If smtpd_relay_restrictions is not defined, the default is
                        used: "permit_mynetworks, permit_sasl_authenticated,
                        reject_unauth_destination".
                        --
                        http://rob0.nodns4.us/ -- system administration and consulting
                        Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                      • /dev/rob0
                        ... I m going to toss out one other tangentially-related issue. I think postconf -n should include the mail_version setting. That might save us here
                        Message 11 of 17 , Sep 28, 2012
                        • 0 Attachment
                          On Fri, Sep 28, 2012 at 06:58:44PM +0000, Viktor Dukhovni wrote:
                          > On Thu, Sep 27, 2012 at 05:38:20PM -0400, Wietse Venema wrote:
                          >
                          > > Victor discussed smtpd_relay_restrictions 6 years, see
                          > > http://archives.neohapsis.com/archives/postfix/2006-05/0598.html
                          > >
                          > > The article also discussed a number of other ideas that have
                          > > potential to increase the Postfix learning curve. I'll leave
                          > > those for now. My current goal is to make Postfix easier to use
                          > > by eliminating one opportunity for human error.
                          >
                          > Nice to see the general idea moving forward, thanks. I'd like to
                          > make another attempt to sell the complete package.

                          I'm going to toss out one other tangentially-related issue. I think
                          "postconf -n" should include the mail_version setting. That might
                          save us here occasionally from wasting a lot of time and ASCII
                          advising people to use smtpd_recipient_restrictions when they should
                          use smtpd_relay_restrictions.
                          --
                          http://rob0.nodns4.us/ -- system administration and consulting
                          Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
                        • Wietse Venema
                          ... Only one of smtpd_relay_restrictions and smtpd_recipient_restrictions has to provide relay authorization. Sites can migrate to Postfix 2.10 by setting
                          Message 12 of 17 , Sep 28, 2012
                          • 0 Attachment
                            /dev/rob0:
                            > On Fri, Sep 28, 2012 at 07:41:22PM +0200, Michael Storz wrote:
                            > > > -- Noel Jones
                            > > >No, this is wrong. The new feature means you may *optionally*
                            > > >separate relay decisions from smtpd_recipient_restrictions,
                            > > >providing a little more safety and flexibility than currently
                            > > >available. It is not a major semantic change -- IMHO not a
                            > > >semantic change at all, just an added feature.
                            > >
                            > > You are right, if smtpd_relay_restrictions is empty and delayed
                            > > restrictions will only be evaluated in smtpd_recipient_restrictions
                            > > then there is no semantic change.
                            >
                            > IIUC it will not be possible to have smtpd_relay_restrictions empty.
                            > It will be a mandatory setting such as smtpd_recipient_restrictions
                            > is now. If smtpd_relay_restrictions is not defined, the default is
                            > used: "permit_mynetworks, permit_sasl_authenticated,
                            > reject_unauth_destination".

                            Only one of smtpd_relay_restrictions and smtpd_recipient_restrictions
                            has to provide relay authorization.

                            Sites can migrate to Postfix 2.10 by setting smtpd_relay_restrictions
                            to an empty value, so that Postfix works exactly as before.

                            This simplifies the user interface, documentation, and migration;
                            it minimizes the amount of new code and the likelihood of new bugs.

                            Wietse
                          • Wietse Venema
                            ... postconf -n shows only parameters that are set in main.cf. As a temporary safety net the install procedure will set an explicit smtpd_relay_restrictions
                            Message 13 of 17 , Sep 28, 2012
                            • 0 Attachment
                              /dev/rob0:
                              > On Fri, Sep 28, 2012 at 06:58:44PM +0000, Viktor Dukhovni wrote:
                              > > On Thu, Sep 27, 2012 at 05:38:20PM -0400, Wietse Venema wrote:
                              > >
                              > > > Victor discussed smtpd_relay_restrictions 6 years, see
                              > > > http://archives.neohapsis.com/archives/postfix/2006-05/0598.html
                              > > >
                              > > > The article also discussed a number of other ideas that have
                              > > > potential to increase the Postfix learning curve. I'll leave
                              > > > those for now. My current goal is to make Postfix easier to use
                              > > > by eliminating one opportunity for human error.
                              > >
                              > > Nice to see the general idea moving forward, thanks. I'd like to
                              > > make another attempt to sell the complete package.
                              >
                              > I'm going to toss out one other tangentially-related issue. I think
                              > "postconf -n" should include the mail_version setting. That might
                              > save us here occasionally from wasting a lot of time and ASCII
                              > advising people to use smtpd_recipient_restrictions when they should
                              > use smtpd_relay_restrictions.

                              postconf -n shows only parameters that are set in main.cf.

                              As a temporary safety net the install procedure will set an explicit
                              smtpd_relay_restrictions value when none is present in main.cf, so
                              there is no problem as long as people cite "postconf -n" output
                              instead of manual cut-and-paste.

                              Wietse
                            • Wietse Venema
                              ... I hadn t noticed that the smtpd_mumble_restriction classes were meant to be optional. Wietse
                              Message 14 of 17 , Sep 28, 2012
                              • 0 Attachment
                                Viktor Dukhovni:
                                > # Empty? Use legacy behaviour controlled by smtpd_delay_reject
                                > #
                                > smtpd_rcpt_restriction_classes =
                                >
                                > # Non-empty, do exactly what the user said:
                                > #
                                > smtpd_rcpt_restriction_classes =
                                > smtpd_relay_restrictions,
                                > smtpd_recipient_restrictions

                                I hadn't noticed that the smtpd_mumble_restriction classes were
                                meant to be optional.

                                Wietse
                              • Viktor Dukhovni
                                ... Perhaps I did not suggest that originally, but 6 years later, with a lot more hindsight, this seems to be a less incompatible approach. -- Viktor.
                                Message 15 of 17 , Sep 28, 2012
                                • 0 Attachment
                                  On Fri, Sep 28, 2012 at 04:18:16PM -0400, Wietse Venema wrote:

                                  > Viktor Dukhovni:
                                  > > # Empty? Use legacy behaviour controlled by smtpd_delay_reject
                                  > > #
                                  > > smtpd_rcpt_restriction_classes =
                                  > >
                                  > > # Non-empty, do exactly what the user said:
                                  > > #
                                  > > smtpd_rcpt_restriction_classes =
                                  > > smtpd_relay_restrictions,
                                  > > smtpd_recipient_restrictions
                                  >
                                  > I hadn't noticed that the smtpd_mumble_restriction classes were
                                  > meant to be optional.

                                  Perhaps I did not suggest that originally, but 6 years later, with
                                  a lot more hindsight, this seems to be a less incompatible approach.

                                  --
                                  Viktor.
                                Your message has been successfully submitted and would be delivered to recipients shortly.