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

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

Expand Messages
  • 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 1 of 25 , Feb 22, 2013
      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 2 of 25 , Feb 22, 2013
        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.