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

Re: setting up postscreen on a system with multiple external interfaces

Expand Messages
  • Viktor Dukhovni
    ... Take a DEEP breath, relax and don t *try* implementing new configurations you don t yet understand. The shots in the dark will just get you more confused.
    Message 1 of 25 , Feb 21, 2013
    • 0 Attachment
      On Thu, Feb 21, 2013 at 05:46:26PM +0100, Erik Slagter wrote:

      > Another variation I tried ("pass" and "postscreen" the other way
      > around). This works, but gives the original problem, the smtpd
      > options are not honoured (especially banner and starttls="may"),
      > even though I set both:

      Take a DEEP breath, relax and don't *try* implementing new
      configurations you don't yet understand. The shots in the dark will
      just get you more confused.

      It is time to try to *understand*.

      1. A running Postfix instance is a collection of separate background
      services (daemons) launched by an inetd-like service supervisor known
      as "master. These services run independently in separate processes
      and communicate with each other using unix-domain sockets.

      They are configured either via main.cf (best practice) or via
      master.cf "-o parameter=$value" overrides (when you must).

      The MOST important thing you need to understand about this is:

      Adding "-o FOO=BAR" to the master.cf entry for SERVICEA has
      NO EFFECT on the value of FOO in SERVICEB!

      Even when the MESSAGE is passed from SERVICEA to SERVICEB the
      parameter settings ARE NOT.

      Thus when you convert an existing "smtpd" entry to a "postscreen"
      entry, it is a grave mistake to leave the "smtpd" (-o options)
      that tune the functionality of smtpd attached to the "postscreen"
      service. It (postscreen) won't care and the destination "smtpd"
      to which the message is handed off will no longer know the parameters.

      2. To provide multiple smtpd personalities, you need to implement multiple
      "smtpd" services each with their own settings. (As you do when smtpd
      listens directly on an "inet" socket).

      3. To implement 2. with postscreen, each "inet" listening postscreen
      (with settings relevant for postscreen) must hand the message off
      to an "smtpd" appropriate for its listening IP address.

      4. Therefore, you need multiple "smtpd" "pass" services for "postscreen"
      to hand the connection to. The postscreen(8) manual page refers you to

      http://www.postfix.org/postconf.5.html#smtpd_service_name

      which must specify the service name of a "pass" entry in master.cf,
      you need one of these for each distinct postscreen instance.

      192.0.2.1:25 inet ... postscreen
      -o smtpd_service_name=25@192.0.2.1
      -o <postscreen-related-settings> ...
      25@192.0.2.1 pass ... smtpd
      -o <smtpd-related-settings> ...

      Lather, rinse, repeat:

      192.0.2.1:587 inet ... postscreen
      -o smtpd_service_name=587@192.0.2.1
      -o <postscreen-related-settings> ...
      587@192.0.2.1 pass ... smtpd
      -o <smtpd-related-settings> ...

      Lather, rinse, repeat:

      192.0.2.2:25 inet ... postscreen
      -o smtpd_service_name=25@192.0.2.2
      -o <postscreen-related-settings> ...
      25@192.0.2.2 pass ... smtpd
      -o <smtpd-related-settings> ...

      Lather, rinse, repeat:

      192.0.2.3:25 inet ... postscreen
      -o smtpd_service_name=25@192.0.2.3
      -o <postscreen-related-settings> ...
      25@192.0.3.2 pass ... smtpd
      -o <smtpd-related-settings> ...

      ... but do stop eventually ... :-)

      --
      Viktor.
    • Erik Slagter
      ... And THAT is exactly the clue I was looking for! It works! The only thing that would have to be in the README file is the need to use smtpd service names
      Message 2 of 25 , Feb 22, 2013
      • 0 Attachment
        On 21-02-13 20:07, Viktor Dukhovni wrote:

        > [ ... ] (lot of patronising text removed)

        > 4. Therefore, you need multiple "smtpd" "pass" services for "postscreen"
        > to hand the connection to. The postscreen(8) manual page refers you to
        >
        > http://www.postfix.org/postconf.5.html#smtpd_service_name
        >
        > which must specify the service name of a "pass" entry in master.cf,
        > you need one of these for each distinct postscreen instance.

        And THAT is exactly the clue I was looking for! It works!

        The only thing that would have to be in the README file is the need to
        use "smtpd service names" in case of multiple smtp listeners, point to
        http://www.postfix.org/postconf.5.html#smtpd_service_name and then add a
        bit of really helpful text to the current one:

        "The internal service that postscreen(8) hands off allowed connections
        to. In a future version there may be different classes of SMTP service."

        If you google for this command, you'll get references to either this
        text or this thread :-(

        So for other people seeking to do the same, this does the trick, it's
        also simple once you know, the "service" parameter of a "pass" service
        is not an address:portno combo but an identifier:

        #
        # outside -> inside
        # postfix(25) -> amavis(10025)
        #

        mx1.ipv4.slagter.name:smtp inet n - n - 1 postscreen
        -o postscreen_cache_map=btree:$data_directory/postscreen_cache-ipv4
        -o
        postscreen_greet_banner=mx1.slagter.name-ESMTP-mx1-postscreen-1-ppp0-ipv4-25
        -o smtpd_banner=mx1.slagter.name-ESMTP-mx1-postscreen-2-ppp0-ipv4-25
        -o postscreen_tls_security_level=none
        -o smtpd_service_name=mx1_ipv4

        mx1_ipv4 pass - - n - - smtpd
        -o myhostname=mx1.slagter.name
        -o smtpd_banner=mx1.slagter.name-ESMTP-$mail_name-mx1-ppp0-ipv4-25
        -o smtpd_tls_security_level=may
        -o smtpd_proxy_filter=nemesis.ipv4:10025 # amavis

        mx1.ipv6.slagter.name:smtp inet n - n - 1 postscreen
        -o postscreen_cache_map=btree:$data_directory/postscreen_cache-ipv6
        -o
        postscreen_greet_banner=mx1.slagter.name-ESMTP-mx1-postscreen-1-ppp0-ipv6-25
        -o smtpd_banner=mx1.slagter.name-ESMTP-mx1-postscreen-2-ppp0-ipv6-25
        -o postscreen_tls_security_level=none
        -o smtpd_service_name=mx1_ipv6

        mx1_ipv6 pass - - n - - smtpd
        -o myhostname=mx1.slagter.name
        -o smtpd_banner=mx1.slagter.name-ESMTP-$mail_name-mx1-ppp0-ipv6-25
        -o smtpd_tls_security_level=may
        -o smtpd_proxy_filter=nemesis.ipv4:10025 # amavis
      • Viktor Dukhovni
        On Fri, Feb 22, 2013 at 11:04:34AM +0100, Erik Slagter wrote: First, a quick comment, all of the sturm and drang in this thread is the result of a peculiar
        Message 3 of 25 , Feb 22, 2013
        • 0 Attachment
          On Fri, Feb 22, 2013 at 11:04:34AM +0100, Erik Slagter wrote:

          First, a quick comment, all of the sturm and drang in this thread
          is the result of a peculiar reluctance of most users to heed the
          advice in MULTI_INSTANCE_README and simplify their configurations
          by handling each distinct message flow in a separate Postfix
          instance, each of which can be configured with few if any master.cf
          tweaks, and understood and maintained much more easily.

          A combination of MULTI_INSTANCE_README and POSTSCREEN_README would
          get you there much more quickly, and even allow simpler configuration
          of cases where identical policies apply to multiple protocol:address
          endpoints, since you can just set inet_interfaces in main.cf to list
          one or more network addresses for a given instance.

          I strongly recommend that you take the time to refactor your
          configuration to separate each flow into its own queue. The initial
          investment of time pays off quickly in easier to manage configurations
          and operational support (e.g. separate queues make it easier to
          see which flow is having problems).

          > On 21-02-13 20:07, Viktor Dukhovni wrote:
          >
          > > [ ... ] (lot of patronising text removed)

          Text that is required background knowledge to understand what
          follows, misconstrued to be patronizing rather than emphatic. Chill
          man, the blustery tone of this thread is mostly the result of your
          reticense to (AFAIK you never did) post the actual master.cf
          configuration that failed to meet your expectations. You should
          probably also not have included the text below in the initial post:

          The options (-o) that I specify on the various per-interface
          smtpd instances are NOT honoured anymore. ...

          Is this intentional? A know[n] bug? ...

          I must say the "howto" isn't very clear on this matter, it assumes you
          only have only one external interface.

          This is rude to the developers who take great pains to make Postfix
          unusually robust and well documented. The "patronising" text is
          sufficient to logically deduce that (and why) you need multiple
          smtpd "pass" services, at which point one looks for a parameter to
          specify the pass service, and finds it (in this case clustered
          sub-optimally with unrelated settings, we'll fix that) in the postscreen(8)
          manpage.

          If Wietse is still reading this, we should move "smtpd_service_name"
          to its ownn section nearer the top of the postscreen(8) manpage.

          Fortunately, the parameter name is just what you'd expect if you've
          ever seen "cleanup_service_name" which plays the same role one
          handoff downstream.

          > >4. Therefore, you need multiple "smtpd" "pass" services for "postscreen"
          > > to hand the connection to. The postscreen(8) manual page refers you to
          > >
          > > http://www.postfix.org/postconf.5.html#smtpd_service_name
          > >
          > > which must specify the service name of a "pass" entry in master.cf,
          > > you need one of these for each distinct postscreen instance.
          >
          > And THAT is exactly the clue I was looking for! It works!

          Naturally, since it is simply a logical consequence of understanding
          the patronising text. :-) Perhaps some people even spotted the
          transposition error in the last "Lather, rinse, repeat" example.
          (It has been observed that students pay more attention to technical
          books that contain minor errors that require them to pause and
          think, and that they learn more from these than from polished
          material that requires less attention).

          [
          Plus the fact that "unix" and "pass" service names are just file
          names in /var/spool/postfix/private/ which I started to describe
          in my first post, but decided to keep it more concise in the hope
          that this will be apparent from context.

          The master.cf services live in one of three namespaces:

          - inet/public (inet can't be private).

          - unix/public

          - unix/private

          Each of the "unix" cases subsumes "unix", "fifo" and "pass" since these
          all are accessed via paths in /var/spool/postfix/{public,private}.

          All delivery agents are "private" while "pickup", "qmgr", "flush"
          and "showq" are "public" to support postdrop(1) and postqueue(1)
          and their sendmail(1) interfaces. Almost everything else is private,
          except for cleanup(8) which AFAIK is public only for historical
          reasons.
          ]

          --
          Viktor.
        • Wietse Venema
          ... This was changed from private into public , so that postdrop could directly submit mail into cleanup, using the maildrop directory only as a fall-back
          Message 4 of 25 , Feb 22, 2013
          • 0 Attachment
            Viktor Dukhovni:
            > All delivery agents are "private" while "pickup", "qmgr", "flush"
            > and "showq" are "public" to support postdrop(1) and postqueue(1)
            > and their sendmail(1) interfaces. Almost everything else is private,
            > except for cleanup(8) which AFAIK is public only for historical
            > reasons.

            This was changed from "private" into "public", so that postdrop
            could directly submit mail into cleanup, using the maildrop directory
            only as a fall-back mechanism in case cleanup transaction failed.
            Recovering from all possible failure modes is complicated and I did
            not get around to write that code (and there are few people who I
            would trust to write it).

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