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

anlyzing sudden spam flood, how?

Expand Messages
  • lists@...
    I have a Postfix 2.6.6 with amavisd/policyd, unchanged since long time ago, all s well. since about 24 hours ago, my main own personal address is getting hit
    Message 1 of 18 , Sep 17, 2013
      I have a Postfix 2.6.6 with amavisd/policyd, unchanged since long time
      ago, all's well.

      since about 24 hours ago, my main own personal address is getting hit with
      spam, every hour, some end up marked up on "X-Spam-Score" above threshold,
      but, quite a few, several every hour, end up in my inbox

      it seems most of the spam is addressed to my personal email

      tried looking at the headers, the only common thing I could determine is
      this: "(8.11.3/8.11.3)" and "phpmailer"

      -------------
      Received: (from root@localhost) by mail0.lycos.com (8.11.3/8.11.3)
      id k0V8OhN68980; Tue, 17 Sep 2013 22:27:37 -0700 (PDT envelope-from
      root)
      Date: Tue, 17 Sep 2013 22:00:07 -0700
      Message-Id: <12075867361346.JLuoBItDCg@wraith>
      X-Mailer: phpmailer [version 1.41]

      ----------
      typical header is like so:
      ----------

      Return-Path: <bayedfrescoes@...>
      Delivered-To: <vvvvvv@...>
      Received: from geko.domain.tld
      by geko.domain.tld (Dovecot) with LMTP id H+JqOPvTOFLbcAAAyLbbsQ
      for <vvvvvv@...>; Wed, 18 Sep 2013 08:13:46 +1000
      Received: from localhost (localhost.localdomain [127.0.0.1])
      by geko.domain.tld (Postfix) with ESMTP id 44FAF38288C
      for <vvvvvv@...>; Wed, 18 Sep 2013 08:13:46 +1000 (EST)
      X-Virus-Scanned: amavisd-new geko at domain.tld
      X-Spam-Flag: NO
      X-Spam-Score: -1.106
      X-Spam-Level:
      X-Spam-Status: No, score=-1.106 required=5.8 tests=[BAYES_00=-1.9,
      FSL_HELO_NON_FQDN_1=0.001, RDNS_NONE=0.793] autolearn=no
      Received: from geko.domain.tld ([127.0.0.1])
      by localhost (geko.domain.tld [127.0.0.1]) (amavisd-new geko, port
      10024)
      with LMTP id byKMFpw-ZGmZ for <vvvvvv@...>;
      Wed, 18 Sep 2013 08:13:25 +1000 (EST)
      Received: from p2p (unknown [124.11.170.87])
      by geko.domain.tld (Postfix) with SMTP id 9E40A3827C6
      for <vvvvvv@...>; Wed, 18 Sep 2013 08:13:25 +1000 (EST)
      Received: (from root@localhost) by mail8.reuters.com (8.11.3/8.11.3)
      id k6V9OhN71476; Tue, 17 Sep 2013 22:13:50 -0800 (PDT envelope-from
      root)
      Date: Tue, 17 Sep 2013 21:21:06 -0800
      Message-Id: <03549621943131.qILzJoyzrI@meaty>
      X-Mailer: phpmailer [version 1.41]
      X-BeenThere: flowchart@...
      X-Kaspersky: Checking
      Content-Type: text/plain;
      charset="us-ascii"
      Content-Transfer-Encoding: 7bit
      To: <vvvvvv@...>
      From: "Free trial enlargement" <bayedfrescoes@...>
      Subject: Impress all in the locker room
      ----------

      is there a script to run through a bunch of emails to anylyze some common
      reason..?

      what am I missing, what should I do ?

      ----------------
      smtpd_recipient_restrictions =
      permit_sasl_authenticated,
      permit_mynetworks,
      reject_unauth_destination,
      check_recipient_access hash:/etc/postfix/recipient_no_checks,
      reject_non_fqdn_sender,
      reject_non_fqdn_recipient,
      reject_invalid_hostname,
      reject_non_fqdn_hostname,
      reject_unknown_sender_domain,
      reject_unknown_reverse_client_hostname,
      reject_unlisted_recipient,
      check_sender_access hash:/etc/postfix/freemail_access,
      check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
      check_helo_access hash:/etc/postfix/helo_checks,
      check_sender_access hash:/etc/postfix/sender_checks,
      check_client_access hash:/etc/postfix/client_checks,
      check_client_access pcre:/etc/postfix/client_checks.pcre,
      reject_rbl_client zen.spamhaus.org,
      reject_rhsbl_client dbl.spamhaus.org,
      reject_rhsbl_sender dbl.spamhaus.org,
      reject_rbl_client psbl.surriel.com,
      reject_rbl_client bl.spamcop.net,
      reject_rhsbl_sender dsn.rfc-ignorant.org,
      check_policy_service inet:127.0.0.1:10031,
      permit

      smtpd_restriction_classes = from_freemail_host
      from_freemail_host =
      reject_unknown_client,
      check_client_access hash:/etc/postfix/freemail_hosts,
      check_client_access regexp:/etc/postfix/freemail_reject,
      reject


      smtpd_helo_restrictions =
      permit_mynetworks,
      check_helo_access regexp:/etc/postfix/helo_access
    • Viktor Dukhovni
      ... Everything below this Received header is fiction. The EHLO name is not an FQDN and the IP address does not have matching forward and reverse addresses.
      Message 2 of 18 , Sep 17, 2013
        On Wed, Sep 18, 2013 at 01:00:48PM +1000, lists@... wrote:

        > Return-Path: <bayedfrescoes@...>
        > ...
        > Received: from p2p (unknown [124.11.170.87])
        > by geko.domain.tld (Postfix) with SMTP id 9E40A3827C6
        > for <vvvvvv@...>; Wed, 18 Sep 2013 08:13:25 +1000 (EST)

        Everything below this Received header is fiction. The EHLO name
        is not an FQDN and the IP address does not have matching forward
        and reverse addresses.

        You could try:

        main.cf:
        # Preferred RE map type:
        RE = pcre:${config_directory}/

        # HELO restrictions for remote clients
        smtpd_helo_required = yes
        smtpd_helo_restrictions =
        permit_mynetworks,
        permit_sasl_authenticated,
        check_helo_access ${RE}helo.re

        helo.re
        # Clients with non-fqdn HELO names MUST have working FCrDNS
        /^[^.]*$/ reject_unknown_client_hostname

        > Received: (from root@localhost) by mail8.reuters.com (8.11.3/8.11.3)
        > id k6V9OhN71476; Tue, 17 Sep 2013 22:13:50 -0800 (PDT envelope-from root)
        > [...]

        > is there a script to run through a bunch of emails to anylyze some common
        > reason..?

        Look for common patters in the first Received headers added by your
        MTA. The rest is up to any spam detecting content filters you may have.

        > smtpd_recipient_restrictions =
        > permit_sasl_authenticated,
        > permit_mynetworks,
        > reject_unauth_destination,
        > check_recipient_access hash:/etc/postfix/recipient_no_checks,

        Is your address subject to checks?

        > reject_non_fqdn_sender,
        > reject_non_fqdn_recipient,
        > reject_invalid_hostname,
        > reject_non_fqdn_hostname,

        This should have blocked the example message, but did not. Why?

        --
        Viktor.
      • lists@...
        On Wed, September 18, 2013 1:40 pm, Viktor Dukhovni wrote: Viktor, thanks ... oooops... I OK ed myself in there... ... sorry, I should ve checked the no
        Message 3 of 18 , Sep 17, 2013
          On Wed, September 18, 2013 1:40 pm, Viktor Dukhovni wrote:

          Viktor, thanks

          >> hash:/etc/postfix/recipient_no_checks,
          > Is your address subject to checks?

          oooops... I OK'ed myself in there...


          >> reject_non_fqdn_sender, reject_non_fqdn_recipient,
          >> reject_invalid_hostname, reject_non_fqdn_hostname,
          >
          > This should have blocked the example message, but did not. Why?

          sorry, I should've checked the 'no check' first...sorry

          updated, postmaped, reloaded

          so, my presence in "recipient_no_checks", that would also exempt me from
          policyd greylist, yes ?

          (couldn't see any triplets at all for my address in policyd db)
          (more sheepish grin)

          so, should I still implement the below suggestions ?

          thanks again

          > You could try:
          >
          >
          > main.cf:
          > # Preferred RE map type:
          > RE = pcre:${config_directory}/
          >
          >
          > # HELO restrictions for remote clients
          > smtpd_helo_required = yes smtpd_helo_restrictions = permit_mynetworks,
          > permit_sasl_authenticated, check_helo_access ${RE}helo.re
          >
          > helo.re # Clients with non-fqdn HELO names MUST have working FCrDNS
          > /^[^.]*$/ reject_unknown_client_hostname
          >
          >
        • Viktor Dukhovni
          ... Naturally. ... Not necessarily. Your existing rules may well be sufficient. Try those first. -- Viktor.
          Message 4 of 18 , Sep 17, 2013
            On Wed, Sep 18, 2013 at 02:01:30PM +1000, lists@... wrote:

            > >> hash:/etc/postfix/recipient_no_checks,
            > >
            > > Is your address subject to checks?
            >
            > oooops... I OK'ed myself in there...
            >
            > updated, postmaped, reloaded
            >
            > so, my presence in "recipient_no_checks", that would also exempt me from
            > policyd greylist, yes ?

            Naturally.

            > so, should I still implement the below suggestions ?

            Not necessarily. Your existing rules may well be sufficient. Try
            those first.

            --
            Viktor.
          • Stan Hoeppner
            ... He s using Postfix 2.6.6. The parms in his current config that would have triggered are for 2.2 or older, thus ignored I assume. He should be using
            Message 5 of 18 , Sep 17, 2013
              On 9/17/2013 10:40 PM, Viktor Dukhovni wrote:
              > On Wed, Sep 18, 2013 at 01:00:48PM +1000, lists@... wrote:
              ...
              >> reject_non_fqdn_sender,
              >> reject_non_fqdn_recipient,
              >> reject_invalid_hostname,
              >> reject_non_fqdn_hostname,
              >
              > This should have blocked the example message, but did not. Why?

              He's using Postfix 2.6.6. The parms in his current config that would
              have triggered are for 2.2 or older, thus ignored I assume. He should
              be using

              reject_invalid_helo_hostname
              reject_non_fqdn_helo_hostname

              which should trigger on this.

              --
              Stan
            • Emmanuel Fusté
              ... Hello Viktor, In an access table, could I use any postfix reject_xxx and permit_xxx directive ? I did not find it in the documentation. It could be
              Message 6 of 18 , Sep 18, 2013
                Le 18/09/2013 05:40, Viktor Dukhovni a écrit :
                > On Wed, Sep 18, 2013 at 01:00:48PM +1000, lists@... wrote:
                >
                >> Return-Path: <bayedfrescoes@...>
                >> ...
                >> Received: from p2p (unknown [124.11.170.87])
                >> by geko.domain.tld (Postfix) with SMTP id 9E40A3827C6
                >> for <vvvvvv@...>; Wed, 18 Sep 2013 08:13:25 +1000 (EST)
                > Everything below this Received header is fiction. The EHLO name
                > is not an FQDN and the IP address does not have matching forward
                > and reverse addresses.
                >
                > You could try:
                >
                > main.cf:
                > # Preferred RE map type:
                > RE = pcre:${config_directory}/
                >
                > # HELO restrictions for remote clients
                > smtpd_helo_required = yes
                > smtpd_helo_restrictions =
                > permit_mynetworks,
                > permit_sasl_authenticated,
                > check_helo_access ${RE}helo.re
                >
                > helo.re
                > # Clients with non-fqdn HELO names MUST have working FCrDNS
                > /^[^.]*$/ reject_unknown_client_hostname
                >
                >
                > [...]
                Hello Viktor,

                In an "access" table, could I use any postfix "reject_xxx" and
                "permit_xxx" directive ?
                I did not find it in the documentation. It could be very powerfull.

                Emmanuel.
              • Stan Hoeppner
                ... It s mentioned, sparsely, in access(5): OTHER ACTIONS restriction... Apply the named UCE restriction(s) (permit, reject, reject_unauth_destination, and so
                Message 7 of 18 , Sep 18, 2013
                  On 9/18/2013 4:27 AM, Emmanuel Fusté wrote:
                  > Le 18/09/2013 05:40, Viktor Dukhovni a écrit :
                  >> On Wed, Sep 18, 2013 at 01:00:48PM +1000, lists@... wrote:
                  >>
                  >>> Return-Path: <bayedfrescoes@...>
                  >>> ...
                  >>> Received: from p2p (unknown [124.11.170.87])
                  >>> by geko.domain.tld (Postfix) with SMTP id 9E40A3827C6
                  >>> for <vvvvvv@...>; Wed, 18 Sep 2013 08:13:25 +1000 (EST)
                  >> Everything below this Received header is fiction. The EHLO name
                  >> is not an FQDN and the IP address does not have matching forward
                  >> and reverse addresses.
                  >>
                  >> You could try:
                  >>
                  >> main.cf:
                  >> # Preferred RE map type:
                  >> RE = pcre:${config_directory}/
                  >>
                  >> # HELO restrictions for remote clients
                  >> smtpd_helo_required = yes
                  >> smtpd_helo_restrictions =
                  >> permit_mynetworks,
                  >> permit_sasl_authenticated,
                  >> check_helo_access ${RE}helo.re
                  >>
                  >> helo.re
                  >> # Clients with non-fqdn HELO names MUST have working FCrDNS
                  >> /^[^.]*$/ reject_unknown_client_hostname
                  >>
                  >>
                  >> [...]
                  > Hello Viktor,
                  >
                  > In an "access" table, could I use any postfix "reject_xxx" and
                  > "permit_xxx" directive ?
                  > I did not find it in the documentation. It could be very powerfull.

                  It's mentioned, sparsely, in access(5):

                  OTHER ACTIONS
                  restriction...
                  Apply the named UCE restriction(s) (permit, reject,
                  reject_unauth_destination, and so on).

                  No, you cannot use "any" restriction. You must use only those that
                  apply to the context of the check_foo_access restriction which targets
                  the table. However, if you think clearly about this for a moment,
                  you'll realize that these nested restrictions using tables are
                  completely unnecessary.

                  What Viktor is doing here is suggesting a workaround using a barely
                  documented trick in an effort to make something work which should
                  already be working, but is not. I already stated what I believe the
                  problem is and the simple solution. Just because you're seeing
                  something used in a way you didn't previously know was possible does not
                  mean it is powerful, nor something you should try to imitate. And in
                  fact trying to use this will very likely only cause you additional
                  problems, while solving none.

                  --
                  Stan
                • Wietse Venema
                  ... It *is* documented. OTHER ACTIONS restriction... Apply the named UCE restriction(s) (permit, reject, reject_unauth_destination, and so on).
                  Message 8 of 18 , Sep 18, 2013
                    Emmanuel Fust?:
                    > In an "access" table, could I use any postfix "reject_xxx" and
                    > "permit_xxx" directive ?
                    > I did not find it in the documentation. It could be very powerfull.

                    It *is* documented.

                    OTHER ACTIONS
                    restriction...
                    Apply the named UCE restriction(s) (permit, reject,
                    reject_unauth_destination, and so on).

                    Wietse
                  • Wietse Venema
                    ... And, this is in fact the supported way to implement per-sender (or per-client, per-recipient, etc.) access policies. You index the table with the sender
                    Message 9 of 18 , Sep 18, 2013
                      Wietse Venema:
                      > Emmanuel Fust?:
                      > > In an "access" table, could I use any postfix "reject_xxx" and
                      > > "permit_xxx" directive ?
                      > > I did not find it in the documentation. It could be very powerfull.
                      >
                      > It *is* documented.
                      >
                      > OTHER ACTIONS
                      > restriction...
                      > Apply the named UCE restriction(s) (permit, reject,
                      > reject_unauth_destination, and so on).

                      And, this is in fact the supported way to implement per-sender (or
                      per-client, per-recipient, etc.) access policies. You index the
                      table with the sender (or client, recipient, etc.) and specify
                      some policy on the right-hand side. You can use this in the
                      middle of a longer access list.

                      Wietse
                    • Emmanuel Fusté
                      ... Ok, got it, thank you. I think that it deserve more than just this paragraph. I was looking how to do better per sender access policy and completely
                      Message 10 of 18 , Sep 18, 2013
                        Le 18/09/2013 12:48, Wietse Venema a écrit :
                        > Wietse Venema:
                        >> Emmanuel Fust?:
                        >>> In an "access" table, could I use any postfix "reject_xxx" and
                        >>> "permit_xxx" directive ?
                        >>> I did not find it in the documentation. It could be very powerfull.
                        >> It *is* documented.
                        >>
                        >> OTHER ACTIONS
                        >> restriction...
                        >> Apply the named UCE restriction(s) (permit, reject,
                        >> reject_unauth_destination, and so on).
                        > And, this is in fact the supported way to implement per-sender (or
                        > per-client, per-recipient, etc.) access policies. You index the
                        > table with the sender (or client, recipient, etc.) and specify
                        > some policy on the right-hand side. You can use this in the
                        > middle of a longer access list.
                        >
                        > Wietse
                        Ok, got it, thank you.
                        I think that it deserve more than just this paragraph.
                        I was looking how to do better per sender access policy and completely
                        overlook this paragraph !
                        I'm sorry, all my apologies.

                        Emmanuel.
                      • lists@...
                        ... I ve updated the syntax as per above, BUT, my fault was that the address in question was exempted in recipient_no_checks , for other users, the old-syntax
                        Message 11 of 18 , Sep 18, 2013
                          On Wed, September 18, 2013 2:54 pm, Stan Hoeppner wrote:
                          > On 9/17/2013 10:40 PM, Viktor Dukhovni wrote:

                          >>> reject_non_fqdn_sender, reject_non_fqdn_recipient,
                          >>> reject_invalid_hostname, reject_non_fqdn_hostname,
                          >> This should have blocked the example message, but did not. Why?
                          > He's using Postfix 2.6.6. The parms in his current config that would
                          > have triggered are for 2.2 or older, thus ignored I assume. He should be
                          > using
                          > reject_invalid_helo_hostname reject_non_fqdn_helo_hostname
                          > which should trigger on this.

                          I've updated the syntax as per above, BUT, my fault was that the address
                          in question was exempted in "recipient_no_checks",
                          for other users, the old-syntax was working, now updated

                          thanks again for helping, everyone

                          ---------------------
                          smtpd_recipient_restrictions =
                          permit_sasl_authenticated,
                          permit_mynetworks,
                          reject_unauth_destination,
                          check_recipient_access hash:/etc/postfix/recipient_no_checks,
                          reject_non_fqdn_sender,
                          reject_non_fqdn_recipient,
                          reject_invalid_helo_hostname,
                          reject_non_fqdn_helo_hostname,
                          reject_unknown_sender_domain,
                          reject_unknown_reverse_client_hostname,
                          reject_unlisted_recipient,
                          check_sender_access hash:/etc/postfix/freemail_access,
                          check_recipient_access pcre:/etc/postfix/recipient_checks.pcre,
                          check_helo_access hash:/etc/postfix/helo_checks,
                          check_sender_access hash:/etc/postfix/sender_checks,
                          check_client_access hash:/etc/postfix/client_checks,
                          check_client_access pcre:/etc/postfix/client_checks.pcre,
                          reject_rbl_client zen.spamhaus.org,
                          reject_rhsbl_client dbl.spamhaus.org,
                          reject_rhsbl_sender dbl.spamhaus.org,
                          reject_rbl_client psbl.surriel.com,
                          reject_rbl_client bl.spamcop.net,
                          reject_rhsbl_sender dsn.rfc-ignorant.org,
                          check_policy_service inet:127.0.0.1:10031,
                          permit
                        • Wietse Venema
                          Emmanuel Fust?: [ Charset ISO-8859-1 unsupported, converting... ] ... No need to apologize. The problem is not a shortage of documentation (there even is a
                          Message 12 of 18 , Sep 18, 2013
                            Emmanuel Fust?:
                            [ Charset ISO-8859-1 unsupported, converting... ]
                            > Le 18/09/2013 12:48, Wietse Venema a ?crit :
                            > > Wietse Venema:
                            > >> Emmanuel Fust?:
                            > >>> In an "access" table, could I use any postfix "reject_xxx" and
                            > >>> "permit_xxx" directive ?
                            > >>> I did not find it in the documentation. It could be very powerfull.
                            > >> It *is* documented.
                            > >>
                            > >> OTHER ACTIONS
                            > >> restriction...
                            > >> Apply the named UCE restriction(s) (permit, reject,
                            > >> reject_unauth_destination, and so on).
                            > > And, this is in fact the supported way to implement per-sender (or
                            > > per-client, per-recipient, etc.) access policies. You index the
                            > > table with the sender (or client, recipient, etc.) and specify
                            > > some policy on the right-hand side. You can use this in the
                            > > middle of a longer access list.
                            > >
                            > > Wietse
                            > Ok, got it, thank you.
                            > I think that it deserve more than just this paragraph.
                            > I was looking how to do better per sender access policy and completely
                            > overlook this paragraph !
                            > I'm sorry, all my apologies.

                            No need to apologize.

                            The problem is not a shortage of documentation (there even is a
                            separate document titled "Postfix Per-Client/User/etc. Access
                            Control" with examples of per-sender etc. policies).

                            The "problem" is that many Postfix mechanisms are designed to be
                            combined with other Postfix mechanisms. Unfortunateoly, is not
                            practical to describe in the manpage for feature X (for example,
                            access map) how it can be combined with other features A, B, and
                            so on (for example, permit_xx, reject_xx). That would greatly
                            expand the documentation, and even fewer people would read it.

                            Wietse

                            Wietse
                          • Stan Hoeppner
                            ... I only work with what I can verify. You didn t provide the contents of recipient_no_checks. I try not to guess as that gets you into trouble. The only
                            Message 13 of 18 , Sep 18, 2013
                              On 9/18/2013 8:09 AM, lists@... wrote:
                              > On Wed, September 18, 2013 2:54 pm, Stan Hoeppner wrote:
                              >> On 9/17/2013 10:40 PM, Viktor Dukhovni wrote:
                              >
                              >>>> reject_non_fqdn_sender, reject_non_fqdn_recipient,
                              >>>> reject_invalid_hostname, reject_non_fqdn_hostname,
                              >>> This should have blocked the example message, but did not. Why?
                              >> He's using Postfix 2.6.6. The parms in his current config that would
                              >> have triggered are for 2.2 or older, thus ignored I assume. He should be
                              >> using
                              >> reject_invalid_helo_hostname reject_non_fqdn_helo_hostname
                              >> which should trigger on this.
                              >
                              > I've updated the syntax as per above, BUT, my fault was that the address
                              > in question was exempted in "recipient_no_checks",

                              I only work with what I can verify. You didn't provide the contents of
                              recipient_no_checks. I try not to guess as that gets you into trouble.
                              The only thing verifiably wrong was the syntax of those two restrictions.

                              > for other users, the old-syntax was working, now updated

                              That's strange. Usually when new syntax is introduced the old syntax is
                              removed and no longer works. 2.3 -> 2.6 seems a rather long grace
                              period. Does the pre 2.3 syntax still work today?

                              --
                              Stan
                            • Viktor Dukhovni
                              ... Stan is wrong, both forms work, the older form is deprecated, but still works. ... Those were fine. You did not read my posts upthread. ... With parameter
                              Message 14 of 18 , Sep 18, 2013
                                On Wed, Sep 18, 2013 at 08:54:50AM -0500, Stan Hoeppner wrote:

                                > >>> This should have blocked the example message, but did not. Why?
                                > >> He's using Postfix 2.6.6. The parms in his current config that would
                                > >> have triggered are for 2.2 or older, thus ignored I assume. He should be
                                > >> using reject_invalid_helo_hostname reject_non_fqdn_helo_hostname
                                > >> which should trigger on this.

                                Stan is wrong, both forms work, the older form is deprecated, but
                                still works.

                                > I only work with what I can verify. You didn't provide the contents of
                                > recipient_no_checks. I try not to guess as that gets you into trouble.
                                > The only thing verifiably wrong was the syntax of those two restrictions.

                                Those were fine. You did not read my posts upthread.

                                > > for other users, the old-syntax was working, now updated
                                >
                                > That's strange. Usually when new syntax is introduced the old syntax is
                                > removed and no longer works. 2.3 -> 2.6 seems a rather long grace
                                > period. Does the pre 2.3 syntax still work today?

                                With parameter renames, Postfix introduces backwards compatible defaults:

                                new_name = $old_name

                                with restriction class names the old form is left in place. Incompatible
                                changes are avoided whenever possible.

                                --
                                Viktor.
                              • Wietse Venema
                                ... With Postfix, support for old syntax is removed from documentation, but usually remains in the code. Examples are reject_unknown_hostname and the use of
                                Message 15 of 18 , Sep 18, 2013
                                  Stan Hoeppner:
                                  > > for other users, the old-syntax was working, now updated
                                  >
                                  > That's strange. Usually when new syntax is introduced the old syntax is
                                  > removed and no longer works. 2.3 -> 2.6 seems a rather long grace
                                  > period. Does the pre 2.3 syntax still work today?

                                  With Postfix, support for old syntax is removed from documentation,
                                  but usually remains in the code. Examples are "reject_unknown_hostname"
                                  and the use of an SMTPD access map without "check_mumble_access". Old
                                  syntax is removed when maintaining it becomes a problem.

                                  Wietse
                                • Stan Hoeppner
                                  ... Thank you both for the explanation. I ve always updated my syntax soon after changes are made and never really tested this. Sorry for adding noise to the
                                  Message 16 of 18 , Sep 18, 2013
                                    On 9/18/2013 9:07 AM, Wietse Venema wrote:
                                    > Stan Hoeppner:
                                    >>> for other users, the old-syntax was working, now updated
                                    >>
                                    >> That's strange. Usually when new syntax is introduced the old syntax is
                                    >> removed and no longer works. 2.3 -> 2.6 seems a rather long grace
                                    >> period. Does the pre 2.3 syntax still work today?
                                    >
                                    > With Postfix, support for old syntax is removed from documentation,
                                    > but usually remains in the code. Examples are "reject_unknown_hostname"
                                    > and the use of an SMTPD access map without "check_mumble_access". Old
                                    > syntax is removed when maintaining it becomes a problem.
                                    >
                                    > Wietse


                                    On 9/18/2013 9:06 AM, Viktor Dukhovni wrote:
                                    > With parameter renames, Postfix introduces backwards compatible
                                    > defaults:
                                    >
                                    > new_name = $old_name
                                    >
                                    > with restriction class names the old form is left in place.
                                    > Incompatible changes are avoided whenever possible.


                                    Thank you both for the explanation. I've always updated my syntax soon
                                    after changes are made and never really tested this. Sorry for adding
                                    noise to the thread.

                                    --
                                    Stan
                                  • Stan Hoeppner
                                    ... Wietse can answer this definitively. I can only relay my experience, which is, using the Debian Postfix packages for many years, it does not appear that
                                    Message 17 of 18 , Sep 18, 2013
                                      On 9/18/2013 6:50 PM, Voytek wrote:
                                      > Stan Hoeppner <stan@...> wrote:
                                      >> On 9/18/2013 9:07 AM, Wietse Venema wrote:
                                      >>> Stan Hoeppner:
                                      >>>>> for other users, the old-syntax was working, now updated
                                      >>>>
                                      >>>> That's strange. Usually when new syntax is introduced the old
                                      >> syntax is
                                      >>>> removed and no longer works. 2.3 -> 2.6 seems a rather long grace
                                      >>>> period. Does the pre 2.3 syntax still work today?
                                      >>>
                                      >>> With Postfix, support for old syntax is removed from documentation,
                                      >>> but usually remains in the code. Examples are
                                      >> "reject_unknown_hostname"
                                      >>> and the use of an SMTPD access map without "check_mumble_access". Old
                                      >>> syntax is removed when maintaining it becomes a problem.
                                      >>>
                                      >>> Wietse
                                      >>
                                      >>
                                      >> On 9/18/2013 9:06 AM, Viktor Dukhovni wrote:
                                      >>> With parameter renames, Postfix introduces backwards compatible
                                      >>> defaults:
                                      >>>
                                      >>> new_name = $old_name
                                      >>>
                                      >>> with restriction class names the old form is left in place.
                                      >>> Incompatible changes are avoided whenever possible.
                                      >>
                                      >>
                                      >> Thank you both for the explanation. I've always updated my syntax soon
                                      >> after changes are made and never really tested this. Sorry for adding
                                      >> noise to the thread.
                                      >>
                                      >> --
                                      >> Stan
                                      >
                                      > the fact that I have 'old syntax' in the main.cf , does that imply that at some point, instead of upgrading postfix, a new installation was done, and old config files copied across? (which is a distinct possibility when server was 'moved' from physical to vps), just curious.
                                      >
                                      > Thanks for all the help,

                                      Wietse can answer this definitively. I can only relay my experience,
                                      which is, using the Debian Postfix packages for many years, it does not
                                      appear that the upgrade process walks main.cf and updates syntax.

                                      I do recall that somewhere around 2.9 Wietse added code to check for
                                      some configuration related issues but I don't recall the specifics.
                                      Maybe he can provide a more thorough answer.

                                      --
                                      Stan
                                    • Wietse Venema
                                      ... Postfix as distributed by me will try to update main.cf as you upgrade to a newer release, to avoid surprises. For example, with Postfix 2.9 the
                                      Message 18 of 18 , Sep 18, 2013
                                        Stan Hoeppner:
                                        > the fact that I have 'old syntax' in the main.cf , does that
                                        > imply that at some point, instead of upgrading postfix, a new
                                        > installation was done, and old config files copied across? (which
                                        > is a distinct possibility when server was 'moved' from physical
                                        > to vps), just curious.

                                        Postfix as distributed by me will try to update main.cf as you
                                        upgrade to a newer release, to avoid surprises.

                                        For example, with Postfix 2.9 the inet_protocols default was changed
                                        from "ipv4" to "all" (on platforms where Postfix is built with IPv6
                                        support). The idea is that eventually IPv6 will become mainstream.

                                        However, such a change is problematic when a site has IPv6 support
                                        in the kernel but not in the network infrastructure. To avoid such
                                        painful updates, the Postfix install/upgrade procedure sets
                                        "inet_protocols = ipv4" in main.cf when no explicit setting exists,
                                        so that the change in default does not disrupt operations on sites
                                        that have IPv4 connectivity only.

                                        Of course some distributions don't implement my transitional safety
                                        nets and cause chaos with their users.

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