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

postfix 2.7.1 debian - does not query DNS

Expand Messages
  • Simon Loewenthal
    Hi, I have a postfix instance on Debian 6 that has never performed DNS lookups with version number 2.7.1-1+squeeze1. The mail.log lists all connections like
    Message 1 of 16 , Nov 7, 2013
    • 0 Attachment

      Hi,

       

       I have a postfix instance on Debian 6 that has never performed DNS lookups with version number 2.7.1-1+squeeze1.

      The mail.log lists all connections like

      Nov  6 17:40:54 lo postfix/smtpd[10283]: 4AD4292: client=unknown[82.2.1.3], sasl_method=PLAIN, sasl_username=example@...
      Nov  6 17:40:54 lo postfix/smtpd[10283]: disconnect from unknown[82.2.1.3]
      Real IP address obfuscated.

      DNS worked and quickly performs name resolution for all other programmes including SpamAssassin.  Results returned for SpamAssassin's RBL lookups happen quite quickly for this lower end server.  I cannot see performance problems with Power DNS Recursor.

      If I enter IP/host pairs into the /etc/hosts file, then Postfix can get the address back and unknown is replaced with, for example Nov  7 09:49:03 lo postfix/smtpd[13222]: connect from gw1-in.tele2.se[193.12.60.45]

      * Postfix has been left with default options relating to DNS lookups:

      # postconf -d|grep dns
      disable_dns_lookups = no
      lmtp_host_lookup = dns
      smtp_host_lookup = dns
      # postconf -n|grep dns
      # (no results returned)
      # grep dns /etc/postfix/main.cf
      # (no results returned)

       

      * DNS ports both are open for TCP and UDP

      # nc  -z 127.0.0.1 53
      # echo $?
      0
      # nc -u -z 127.0.0.1 53
      # echo $?
      0
      #

      * LSOF

      # lsof -i tcp:53
      COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
      pdns_recu 1247 pdns    4u  IPv4   4733      0t0  TCP localhost:domain (LISTEN)
      # lsof -i udp:53
      COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
      pdns_recu 1247 pdns    3u  IPv4   4731      0t0  UDP localhost:domain

      * Resolv.conf

      nameserver 127.0.0.1
      options attempts:5 timeout:4

      I hope you'll find my postconf -d output of interest:

      # postconf -n
      alias_database = hash:/etc/aliases
      alias_maps = hash:/etc/aliases
      append_dot_mydomain = no
      biff = no
      body_checks = regexp:/etc/postfix/body_checks.regexp
      bounce_template_file = /etc/postfix/bounce.cf
      broken_sasl_auth_clients = yes
      config_directory = /etc/postfix
      disable_vrfy_command = yes
      header_checks = pcre:/etc/postfix/header_checks
      inet_interfaces = all
      mailbox_size_limit = 0
      message_size_limit = 20480000
      milter_connect_macros = j {daemon_name} v {client_addr} _
      milter_default_action = tempfail
      mime_header_checks = regexp:/etc/postfix/mime_header_checks
      mydestination =
      myhostname = example.co.uk
      mynetworks = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
      myorigin = /etc/mailname
      non_smtpd_milters = inet:localhost:8891
      readme_directory = no
      recipient_delimiter = +
      relayhost =
      smtp_helo_timeout = 60s
      smtp_mail_timeout = 160s
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      smtpd_banner = $myhostname ESMTP $mail_name
      smtpd_client_connection_count_limit = 50
      smtpd_client_connection_rate_limit = 50
      smtpd_helo_required = yes
      smtpd_helo_restrictions = permit_mynetworks, reject_invalid_hostname, reject_unlisted_recipient, reject_unlisted_sender, regexp:/etc/postfix/helo.regexp, permit
      smtpd_milters = unix:/spamass/spamass.sock, inet:localhost:8891
      smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, check_recipient_access cidr:/etc/postfix/whitelist, reject_non_fqdn_sender, reject_rbl_client hostkarma.junkemailfilter.com=127.0.0.2, reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client truncate.gbudb.net=127.0.0.2,  check_policy_service unix:private/policy-spf
      smtpd_sasl_auth_enable = yes
      smtpd_sasl_path = private/auth
      smtpd_sasl_type = dovecot
      smtpd_sender_restrictions = hash:/etc/postfix/access
      smtpd_tls_CAfile = /etc/ssl/certs/example_CA.pem
      smtpd_tls_cert_file = /etc/ssl/private/example.co.uk.crt
      smtpd_tls_key_file = /etc/ssl/private/example.co.uk.key
      smtpd_tls_loglevel = 1
      smtpd_tls_received_header = yes
      smtpd_tls_security_level = may
      smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
      smtpd_use_tls = yes
      strict_rfc821_envelopes = yes
      transport_maps = hash:/etc/postfix/transport
      unknown_address_reject_code = 554
      unknown_client_reject_code = 554
      unknown_hostname_reject_code = 554
      virtual_alias_maps = proxy:mysql:/etc/postfix/sql/ms_virtual_alias_maps.cf, proxy:mysql:/etc/postfix/sql/ms_virtual_alias_domain_maps.cf, proxy:mysql:/etc/postfix/sql/ms_virtual_alias_domain_catchall_maps.cf
      virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/ms_virtual_domains_maps.cf
      virtual_mailbox_maps = mysql:/etc/postfix/sql/ms-virtual-mailbox-maps.cf
      virtual_transport = dovecot-spamassassin

      I'd be very grateful if any one would be able to kindly shed some light on this for me.  Please.

      Kind regards, S

    • DTNX Postmaster
      ... [snip] ... Postfix should work just fine in its default configuration, even on Debian. Have you made any changes to your master.cf ? Post that, please.
      Message 2 of 16 , Nov 7, 2013
      • 0 Attachment
        On 07 Nov 2013, at 12:19, Simon Loewenthal <simon@...> wrote:

        > I have a postfix instance on Debian 6 that has never performed DNS lookups with version number 2.7.1-1+squeeze1.
        >
        > The mail.log lists all connections like
        >
        > Nov 6 17:40:54 lo postfix/smtpd[10283]: 4AD4292: client=unknown[82.2.1.3], sasl_method=PLAIN, sasl_username=example@...
        > Nov 6 17:40:54 lo postfix/smtpd[10283]: disconnect from unknown[82.2.1.3]
        > Real IP address obfuscated.
        >
        > DNS worked and quickly performs name resolution for all other programmes including SpamAssassin. Results returned for SpamAssassin's RBL lookups happen quite quickly for this lower end server. I cannot see performance problems with Power DNS Recursor.

        [snip]

        > I'd be very grateful if any one would be able to kindly shed some light on this for me. Please.

        Postfix should work just fine in its default configuration, even on
        Debian. Have you made any changes to your 'master.cf'?

        Post that, please.

        Mvg,
        Joni
      • Peer Heinlein
        ... If forward lookup (A record) and a reverse lookup (PTR) doesn t fit together, Postfix logs unknown . Please check it with a double-lookup. Peer --
        Message 3 of 16 , Nov 7, 2013
        • 0 Attachment
          Am 07.11.2013 12:19, schrieb Simon Loewenthal:



          > I have a postfix instance on Debian 6 that has never performed DNS
          > lookups with version number 2.7.1-1+squeeze1.
          >
          > Nov 6 17:40:54 lo postfix/smtpd[10283]: disconnect from unknown[82.2.1.3]
          > Real IP address obfuscated.


          If forward lookup (A record) and a reverse lookup (PTR) doesn't fit
          together, Postfix logs "unknown".

          Please check it with a double-lookup.

          Peer



          --
          Heinlein Support GmbH
          Schwedter Str. 8/9b, 10119 Berlin

          http://www.heinlein-support.de

          Tel: 030 / 405051-42
          Fax: 030 / 405051-19

          Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
          Berlin-Charlottenburg,
          Geschäftsführer: Peer Heinlein -- Sitz: Berlin
        • Wietse Venema
          ... Debian chroot damage. http://www.postfix.org/DEBUG_README.html#no_chroot Try turning off chroot operation in master.cf A common mistake is to turn on
          Message 4 of 16 , Nov 7, 2013
          • 0 Attachment
            Simon Loewenthal:
            > I have a postfix instance on Debian 6 that has never performed DNS
            > lookups with version number 2.7.1-1+squeeze1.
            >
            > The mail.log lists all connections like
            >
            > Nov 6 17:40:54 lo postfix/smtpd[10283]: 4AD4292:
            > client=unknown[82.2.1.3], sasl_method=PLAIN,
            > sasl_username=example@...
            > Nov 6 17:40:54 lo postfix/smtpd[10283]: disconnect from
            > unknown[82.2.1.3]
            > Real IP address obfuscated.

            Debian chroot damage.

            http://www.postfix.org/DEBUG_README.html#no_chroot

            Try turning off chroot operation in master.cf

            A common mistake is to turn on chroot operation in the master.cf
            file without going through all the necessary steps to set up a
            chroot environment. This causes Postfix daemon processes to fail
            due to all kinds of missing files.

            The example below shows an SMTP server that is configured with
            chroot turned off:

            /etc/postfix/master.cf:
            # =============================================================
            # service type private unpriv chroot wakeup maxproc command
            # (yes) (yes) (yes) (never) (100)
            # =============================================================
            smtp inet n - n - - smtpd

            Inspect master.cf for any processes that have chroot operation not
            turned off. If you find any, save a copy of the master.cf file, and
            edit the entries in question. After executing the command "postfix
            reload", see if the problem has gone away.

            If turning off chrooted operation made the problem go away, then
            congratulations. Leaving Postfix running in this way is adequate
            for most sites. If you prefer chrooted operation, see the Postfix
            BASIC_CONFIGURATION_README file for information about how to prepare
            Postfix for chrooted operation.
          • Simon Loewenthal
            Hi Wietse, Chroot was not turned on. # ========================================================================== # service type private unpriv chroot wakeup
            Message 5 of 16 , Nov 7, 2013
            • 0 Attachment

              Hi Wietse,

               

              Chroot was not turned on.

              # ==========================================================================
              # service type  private unpriv  chroot  wakeup  maxproc command + args
              #               (yes)   (yes)   (yes)   (never) (100)
              # ==========================================================================
              smtp      inet  n       -       -       -       -       smtpd
                -o smtpd_sasl_auth_enable=no
              deadbeats unix  -       -       n       -       -       smtp -o smtp_connect_timeout=5 -o smtp_helo_timeout=5
              submission inet n       -       -       -       -       smtpd
                -o smtpd_tls_security_level=encrypt
                -o smtpd_sasl_auth_enable=yes
                -o smtpd_client_restrictions=permit_sasl_authenticated,reject
                -o smtp_header_checks=regexp:/etc/postfix/add_header
              3325 inet n       -       -       -       -       smtpd
                -o smtpd_tls_security_level=encrypt
                -o smtpd_sasl_auth_enable=yes
                -o smtpd_client_restrictions=permit_sasl_authenticated,reject
                -o smtp_header_checks=regexp:/etc/postfix/add_header
              127.0.0.1:4325 inet n       -       -       -       -       smtpd
                #-o smtpd_sasl_auth_enable=no
                -o smtpd_sasl_auth_enable=yes
                -o smtpd_client_restrictions=permit_sasl_authenticated,reject
                -o smtp_header_checks=regexp:/etc/postfix/add_header
              pickup    fifo  n       -       -       60      1       pickup
              cleanup   unix  n       -       -       -       0       cleanup
              qmgr      fifo  n       -       n       300     1       qmgr
              tlsmgr    unix  -       -       -       1000?   1       tlsmgr
              rewrite   unix  -       -       -       -       -       trivial-rewrite
              bounce    unix  -       -       -       -       0       bounce
              defer     unix  -       -       -       -       0       bounce
              trace     unix  -       -       -       -       0       bounce
              verify    unix  -       -       -       -       1       verify
              flush     unix  n       -       -       1000?   0       flush
              proxymap  unix  -       -       n       -       -       proxymap
              proxywrite unix -       -       n       -       1       proxymap
              smtp      unix  -       -       -       -       -       smtp
              relay     unix  -       -       -       -       -       smtp
                      -o smtp_fallback_relay=
              showq     unix  n       -       -       -       -       showq
              error     unix  -       -       -       -       -       error
              retry     unix  -       -       -       -       -       error
              discard   unix  -       -       -       -       -       discard
              local     unix  -       n       n       -       -       local
              virtual   unix  -       n       n       -       -       virtual
              lmtp      unix  -       -       -       -       -       lmtp
              anvil     unix  -       -       -       -       1       anvil
              scache    unix  -       -       -       -       1       scache
              maildrop  unix  -       n       n       -       -       pipe
                flags=DRhu user=vmail argv=/usr/bin/maildrop -d ${recipient}
              uucp      unix  -       n       n       -       -       pipe
                flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
              ifmail    unix  -       n       n       -       -       pipe
                flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient)
              bsmtp     unix  -       n       n       -       -       pipe
                flags=Fq. user=bsmtp argv=/usr/lib/bsmtp/bsmtp -t$nexthop -f$sender $recipient
              scalemail-backend unix  -       n       n       -       2       pipe
                flags=R user=scalemail argv=/usr/lib/scalemail/bin/scalemail-store ${nexthop} ${user} ${extension}
              mailman   unix  -       n       n       -       -       pipe
                flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
                ${nexthop} ${user}
              dovecot-spamassasin   unix  -       n       n       -       -       pipe
                  flags=DRhu user=vmail:vmail argv=/usr/bin/spamc -u ${recipient} -e /usr/lib/dovecot/deliver -d ${recipient}
              policy-spf  unix  -       n       n       -       -       spawn
                   user=nobody argv=/usr/sbin/postfix-policyd-spf-perl

              On 2013-11-07 12:35, wietse@... wrote:

              Simon Loewenthal:
              I have a postfix instance on Debian 6 that has never performed DNS lookups with version number 2.7.1-1+squeeze1. The mail.log lists all connections like Nov 6 17:40:54 lo postfix/smtpd[10283]: 4AD4292: client=unknown[82.2.1.3], sasl_method=PLAIN, sasl_username=example@... Nov 6 17:40:54 lo postfix/smtpd[10283]: disconnect from unknown[82.2.1.3] Real IP address obfuscated.
              Debian chroot damage.
              
              http://www.postfix.org/DEBUG_README.html#no_chroot
              
              Try turning off chroot operation in master.cf
              
              A common mistake is to turn on chroot operation in the master.cf
              file without going through all the necessary steps to set up a
              chroot environment. This causes Postfix daemon processes to fail
              due to all kinds of missing files.
              
              The example below shows an SMTP server that is configured with
              chroot turned off:
              
                  /etc/postfix/master.cf:
                      # =============================================================
                      # service type  private unpriv  chroot  wakeup  maxproc command
                      #               (yes)   (yes)   (yes)   (never) (100)
                      # =============================================================
                      smtp      inet  n       -       n       -       -       smtpd
              
              Inspect master.cf for any processes that have chroot operation not
              turned off. If you find any, save a copy of the master.cf file, and
              edit the entries in question. After executing the command "postfix
              reload", see if the problem has gone away.
              
              If turning off chrooted operation made the problem go away, then
              congratulations. Leaving Postfix running in this way is adequate
              for most sites. If you prefer chrooted operation, see the Postfix
              BASIC_CONFIGURATION_README file for information about how to prepare
              Postfix for chrooted operation.
              
            • Charles Marcus
              ... Look again... ... Notice anything different? -- Best regards, */Charles/*
              Message 6 of 16 , Nov 7, 2013
              • 0 Attachment
                On 2013-11-07 6:39 AM, Simon Loewenthal <simon@...> wrote:
                Chroot was not turned on

                Look again...

                # ==========================================================================
                # service type  private unpriv  chroot  wakeup  maxproc command + args
                #               (yes)   (yes)   (yes)   (never) (100)
                # ==========================================================================
                smtp      inet  n       -       -       -       -       smtpd


                Compare yours above to Wietse's example below of a non-chroot'd version:

                        # =============================================================
                        # service type  private unpriv  chroot  wakeup  maxproc command
                        #               (yes)   (yes)   (yes)   (never) (100)
                        # =============================================================
                        smtp      inet  n       -       n       -       -       smtpd
                

                Notice anything different?

                --

                Best regards,

                Charles
              • Wietse Venema
                ... Turn off the damned chroot. Wietse
                Message 7 of 16 , Nov 7, 2013
                • 0 Attachment
                  Simon Loewenthal:
                  > # service type private unpriv chroot ...
                  > # (yes) (yes) (yes) ...
                  > #
                  > ==========================================================================
                  > smtp inet n - - ...

                  Turn off the damned chroot.

                  Wietse
                • Simon Loewenthal
                  Damned chroot now turned off, and lookups now work like they should have done :D And this nicely solved my RDNS_NONE scoring issue with SA, of course! Nov 7
                  Message 8 of 16 , Nov 7, 2013
                  • 0 Attachment

                    Damned chroot now turned off, and lookups now work like they should have done :D

                    And this nicely solved my RDNS_NONE scoring issue with SA, of course!

                    Nov  7 12:49:16 lo postfix/smtpd[15712]: 32FD892: client=english-breakfast.cloud9.net[168.100.1.7]
                    Thanks, I did not think that chroot had been turned on by default.

                    Dag!

                     

                    On 2013-11-07 12:48, wietse@... wrote:

                    Simon Loewenthal:
                    # service type private unpriv chroot ... # (yes) (yes) (yes) ... # ========================================================================== smtp inet n - - ...
                    Turn off the damned chroot.
                    
                    	Wietse
                    
                  • DTNX Postmaster
                    ... One suggestion; if you still have a need for Debian Squeeze and cannot upgrade to Debian Wheezy, consider upgrading to the 2.9.x Postfix that s in the
                    Message 9 of 16 , Nov 7, 2013
                    • 0 Attachment
                      On 07 Nov 2013, at 12:53, Simon Loewenthal <simon@...> wrote:

                      > Damned chroot now turned off, and lookups now work like they should have done :D
                      >
                      > And this nicely solved my RDNS_NONE scoring issue with SA, of course!
                      >
                      > Nov 7 12:49:16 lo postfix/smtpd[15712]: 32FD892: client=english-breakfast.cloud9.net[168.100.1.7]
                      > Thanks, I did not think that chroot had been turned on by default.
                      >
                      > Dag!

                      One suggestion; if you still have a need for Debian Squeeze and cannot
                      upgrade to Debian Wheezy, consider upgrading to the 2.9.x Postfix
                      that's in the squeeze-backports repository. This will give you access
                      to things like postscreen.

                      Also, please turn off HTML for posting to lists.

                      Mvg,
                      Joni

                      --

                      > On 2013-11-07 12:48, wietse@... wrote:
                      >
                      >> Simon Loewenthal:
                      >>> # service type private unpriv chroot ... # (yes) (yes) (yes) ... # ========================================================================== smtp inet n - - ...
                      >> Turn off the damned chroot.
                      >>
                      >> Wietse
                      >>
                    • lists@rhsoft.net
                      ... Debian is the only known distribution doing this stupid default config over years and only god knows why they insist doing this damage
                      Message 10 of 16 , Nov 7, 2013
                      • 0 Attachment
                        Am 07.11.2013 12:53, schrieb Simon Loewenthal:
                        > Damned chroot now turned off, and lookups now work like they should have done :D
                        >
                        > And this nicely solved my RDNS_NONE scoring issue with SA, of course!
                        >
                        > Nov 7 12:49:16 lo postfix/smtpd[15712]: 32FD892: client=english-breakfast.cloud9.net[168.100.1.7]
                        > Thanks, I did not think that chroot had been turned on by default

                        Debian is the only known distribution doing this stupid default config
                        over years and only god knows why they insist doing this damage
                      • Stan Hoeppner
                        ... The default Postfix chroot environment in Debian 6 Squeeze works fine out of the box, as did Lenny. You have to go back to Etch or Sarge to find it
                        Message 11 of 16 , Nov 7, 2013
                        • 0 Attachment
                          On 11/7/2013 5:53 AM, Simon Loewenthal wrote:

                          > Damned chroot now turned off, and lookups now work like they should have
                          > done :D

                          The default Postfix chroot environment in Debian 6 Squeeze works fine
                          out of the box, as did Lenny. You have to go back to Etch or Sarge to
                          find it broken. I'd guess you've modified something in your
                          configuration that broke the chroot.

                          I'm not defending Debian's shipping of Postfix chroot'd, I'm simply
                          stating it works correctly out of the box. It was broken way back in
                          Etch or Sarge (5+ years ago), and Wietse assisted me in troubleshooting
                          such at that time. But it has worked fine in both Lenny and Squeeze,
                          out of the box.

                          > And this nicely solved my RDNS_NONE scoring issue with SA, of course!
                          >
                          > Nov 7 12:49:16 lo postfix/smtpd[15712]: 32FD892:
                          > client=english-breakfast.cloud9.net[168.100.1.7]
                          > Thanks, I did not think that chroot had been turned on by default.
                          >
                          > Dag!
                          >
                          > On 2013-11-07 12:48, wietse@... wrote:
                          >
                          >> Simon Loewenthal:
                          >>
                          >>> # service type private unpriv chroot ... # (yes) (yes) (yes) ... # ========================================================================== smtp inet n - - ...
                          >>
                          >> Turn off the damned chroot.
                          >>
                          >> Wietse
                          >
                          >
                        • DTNX Postmaster
                          ... I set up Postfix on Wheezy a few weeks ago. No problems either. Also, the differences between package and source are documented; == $ cat
                          Message 12 of 16 , Nov 8, 2013
                          • 0 Attachment
                            On 08 Nov 2013, at 01:34, Stan Hoeppner <stan@...> wrote:

                            > On 11/7/2013 5:53 AM, Simon Loewenthal wrote:
                            >
                            >> Damned chroot now turned off, and lookups now work like they should have
                            >> done :D
                            >
                            > The default Postfix chroot environment in Debian 6 Squeeze works fine
                            > out of the box, as did Lenny. You have to go back to Etch or Sarge to
                            > find it broken. I'd guess you've modified something in your
                            > configuration that broke the chroot.
                            >
                            > I'm not defending Debian's shipping of Postfix chroot'd, I'm simply
                            > stating it works correctly out of the box. It was broken way back in
                            > Etch or Sarge (5+ years ago), and Wietse assisted me in troubleshooting
                            > such at that time. But it has worked fine in both Lenny and Squeeze,
                            > out of the box.

                            I set up Postfix on Wheezy a few weeks ago. No problems either. Also,
                            the differences between package and source are documented;

                            ==
                            $ cat /usr/share/doc/postfix/README.Debian
                            There are some significant differences between the Debian Postfix packages,
                            and the source from upstream:

                            1. The Debian install is chrooted by default.
                            2. Dynamically loadable map support.
                            3. For policy reasons:
                            a. SASL configuration goes in /etc/postfix/sasl
                            b. myhostname=/path/to/file is supported (and used) in main.cf
                            4. IPV6 support is enabled: postfix listens on ipv6/ipv4 by default,
                            (see: inet_protocols)
                            5. TLS/SASL support is enabled.
                            6. rmail comes from sendmail, not from postfix.
                            7. The upstream main.cf is delivered as /usr/share/postfix/main.cf.dist,
                            rather than cluttering /etc/postfix/main.cf with comments.
                            ==

                            As annoying as Debian can be at times with the choices they make, I
                            would suggest that it's ultimately the responsibility of the deploying
                            administrator to be aware of any caveats, especially when they are
                            listed in the documentation, or relatively easy to find with a web
                            search.

                            Mvg,
                            Joni
                          • lists@rhsoft.net
                            ... there are only rare situations where a chrooted postfix makes sense and so they should not making a problematic default which gains nothing on 999 out of
                            Message 13 of 16 , Nov 8, 2013
                            • 0 Attachment
                              Am 08.11.2013 10:42, schrieb DTNX Postmaster:
                              > $ cat /usr/share/doc/postfix/README.Debian
                              > There are some significant differences between the Debian Postfix packages,
                              > and the source from upstream:
                              >
                              > 1. The Debian install is chrooted by default.
                              > 2. Dynamically loadable map support.
                              > 3. For policy reasons:
                              > a. SASL configuration goes in /etc/postfix/sasl
                              > b. myhostname=/path/to/file is supported (and used) in main.cf
                              > 4. IPV6 support is enabled: postfix listens on ipv6/ipv4 by default,
                              > (see: inet_protocols)
                              > 5. TLS/SASL support is enabled.
                              > 6. rmail comes from sendmail, not from postfix.
                              > 7. The upstream main.cf is delivered as /usr/share/postfix/main.cf.dist,
                              > rather than cluttering /etc/postfix/main.cf with comments.
                              >
                              > As annoying as Debian can be at times with the choices they make, I
                              > would suggest that it's ultimately the responsibility of the deploying
                              > administrator to be aware of any caveats, especially when they are
                              > listed in the documentation, or relatively easy to find with a web
                              > search

                              there are only rare situations where a chrooted postfix
                              makes sense and so they should not making a problematic
                              default which gains nothing on 999 out of 1000 setups
                            • Stan Hoeppner
                              ... The reason for chrooting Postfix is due to a Debian policy established loooong ago, and it is not Postfix specific. IIRC there s a class of services that
                              Message 14 of 16 , Nov 8, 2013
                              • 0 Attachment
                                On 11/8/2013 4:05 AM, lists@... wrote:

                                > there are only rare situations where a chrooted postfix
                                > makes sense and so they should not making a problematic
                                > default which gains nothing on 999 out of 1000 setups

                                The reason for chrooting Postfix is due to a Debian policy established
                                loooong ago, and it is not Postfix specific. IIRC there's a class of
                                services that all get chrooted in Debian, but for the life of me I can't
                                seem to find the policy doc that explains this. So far I can't find it
                                in the Debian Policy Manual

                                http://www.debian.org/doc/debian-policy/

                                Not sure where it is, but the chroot policy is described somewhere.
                                Debian is pretty good WRT documentation. Good at making it easy to find
                                is another matter...

                                --
                                Stan
                              • Hans Spaans
                                ... As far as I know it was only under consideration long ago (around the time when Solaris Containers where introduced it became a topic again if I m not
                                Message 15 of 16 , Nov 11, 2013
                                • 0 Attachment
                                  Stan Hoeppner schreef op 2013-11-09 04:22:
                                  > On 11/8/2013 4:05 AM, lists@... wrote:
                                  >
                                  >> there are only rare situations where a chrooted postfix
                                  >> makes sense and so they should not making a problematic
                                  >> default which gains nothing on 999 out of 1000 setups
                                  >
                                  > The reason for chrooting Postfix is due to a Debian policy established
                                  > loooong ago, and it is not Postfix specific. IIRC there's a class of
                                  > services that all get chrooted in Debian, but for the life of me I
                                  > can't
                                  > seem to find the policy doc that explains this. So far I can't find it
                                  > in the Debian Policy Manual
                                  >
                                  > http://www.debian.org/doc/debian-policy/
                                  >
                                  > Not sure where it is, but the chroot policy is described somewhere.
                                  > Debian is pretty good WRT documentation. Good at making it easy to
                                  > find
                                  > is another matter...

                                  As far as I know it was only under consideration long ago (around the
                                  time when Solaris Containers where introduced it became a topic again if
                                  I'm not mistaken) and it is an advisory for building packages on a
                                  developer machine. Postfix is still one of the few services doing it and
                                  I still wonder why as it makes things complex to a point where admins
                                  start playing with ln, chmod and cp to get things working. Reading
                                  bugreport 151692[1], seeing all the chroot bugreports and taking the
                                  request from the SELinux Debian Developers into account it makes me
                                  wonder a lot who is going to end this. Wietse or Debian Technical
                                  Committee.

                                  Hans

                                  [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151692
                                • Scott Kitterman
                                  ... This is increasingly off topic for postfix-users. I d suggest taking this up in a Debian specific forum. Personally, I run postfix in a chroot
                                  Message 16 of 16 , Nov 11, 2013
                                  • 0 Attachment
                                    On Monday, November 11, 2013 20:41:05 Hans Spaans wrote:
                                    > Stan Hoeppner schreef op 2013-11-09 04:22:
                                    > > On 11/8/2013 4:05 AM, lists@... wrote:
                                    > >> there are only rare situations where a chrooted postfix
                                    > >> makes sense and so they should not making a problematic
                                    > >> default which gains nothing on 999 out of 1000 setups
                                    > >
                                    > > The reason for chrooting Postfix is due to a Debian policy established
                                    > > loooong ago, and it is not Postfix specific. IIRC there's a class of
                                    > > services that all get chrooted in Debian, but for the life of me I
                                    > > can't
                                    > > seem to find the policy doc that explains this. So far I can't find it
                                    > > in the Debian Policy Manual
                                    > >
                                    > > http://www.debian.org/doc/debian-policy/
                                    > >
                                    > > Not sure where it is, but the chroot policy is described somewhere.
                                    > > Debian is pretty good WRT documentation. Good at making it easy to
                                    > > find
                                    > > is another matter...
                                    >
                                    > As far as I know it was only under consideration long ago (around the
                                    > time when Solaris Containers where introduced it became a topic again if
                                    > I'm not mistaken) and it is an advisory for building packages on a
                                    > developer machine. Postfix is still one of the few services doing it and
                                    > I still wonder why as it makes things complex to a point where admins
                                    > start playing with ln, chmod and cp to get things working. Reading
                                    > bugreport 151692[1], seeing all the chroot bugreports and taking the
                                    > request from the SELinux Debian Developers into account it makes me
                                    > wonder a lot who is going to end this. Wietse or Debian Technical
                                    > Committee.
                                    >
                                    > Hans
                                    >
                                    > [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=151692

                                    This is increasingly off topic for postfix-users. I'd suggest taking this up in
                                    a Debian specific forum. Personally, I run postfix in a chroot everywhere, so I
                                    don't understand the fuss. There are occasional problems and they get fixed.

                                    The Debian maintainer has a different view than the upstream developer on
                                    default configuration is not at all an unusual thing to happen, but it needs to
                                    be addressed in the distro, not here.

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