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

Interesting situation.

Expand Messages
  • Varadi Gabor
    Hi all. Sorry because my English. I squeeze under debian use postfix. # dpkg -l | grep postfix ii postfix 2.7.1-1+squeeze1 High-performance mail transport
    Message 1 of 8 , Aug 2, 2012
    • 0 Attachment
      Hi all.

      Sorry because my English.
      I squeeze under debian use postfix.

      # dpkg -l | grep postfix
      ii postfix 2.7.1-1+squeeze1 High-performance mail transport agent

      Such an experience last night:

      1. (smtp) Ask about DNS MX records for the bond.com
      2. (smtp) DSN response 0.0.0.0
      3. (smtp) connect to 0.0.0.0
      4. (smtpd) in localhost accept connection and received mail
      5. (qmgr) mail in queue
      6. GOTO 1.

      I send myself a mail loop.

      Unable to withstand this level of Postfix?
      No connect to address 0.0.0.0 if response from DNS is 0.0.0.0.


      The log details:

      Jul 31 23:58:22 fw postfix/smtpd[17580]: 6ABF8F: client=localhost[127.0.0.1]
      Jul 31 23:58:22 fw postfix/cleanup[18032]: 6ABF8F: message-id=<20120731065514.5F401D0D@...>
      Jul 31 23:58:22 fw postfix/qmgr[7846]: 6ABF8F: from=<>, size=3109, nrcpt=1 (queue active)
      Jul 31 23:58:22 fw postfix/smtp[18030]: 6ABF8F: to=<info@...>, relay=0.0.0.0[0.0.0.0]:25, conn_use=24, delay=0.04, delays=0.01/0/0/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 6E00018E)
      Jul 31 23:58:22 fw postfix/smtp[18030]: warning: numeric domain name in resource data of MX record for bond.com: 0.0.0.0
      Jul 31 23:58:22 fw postfix/qmgr[7846]: 6ABF8F: removed

      Jul 31 23:58:22 fw postfix/smtpd[15695]: 6E00018E: client=localhost[127.0.0.1]
      Jul 31 23:58:22 fw postfix/cleanup[18031]: 6E00018E: message-id=<20120731065514.5F401D0D@...>
      Jul 31 23:58:22 fw postfix/qmgr[7846]: 6E00018E: from=<>, size=3109, nrcpt=1 (queue active)
      Jul 31 23:58:22 fw postfix/smtp[18029]: 6E00018E: to=<info@...>, relay=0.0.0.0[0.0.0.0]:25, conn_use=6833, delay=0.03, delays=0.02/0/0/0.01, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 74407F)
      Jul 31 23:58:22 fw postfix/smtp[18029]: warning: numeric domain name in resource data of MX record for bond.com: 0.0.0.0
      Jul 31 23:58:22 fw postfix/qmgr[7846]: 6E00018E: removed

      # dig mx bond.com

      ; <<>> DiG 9.7.3 <<>> mx bond.com
      ;; global options: +cmd
      ;; Got answer:
      ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56868
      ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0

      ;; QUESTION SECTION:
      ;bond.com. IN MX

      ;; ANSWER SECTION:
      bond.com. 600 IN MX 1000 0.0.0.0.

      ;; AUTHORITY SECTION:
      bond.com. 7950 IN NS ns2.digimedia.com.
      bond.com. 7950 IN NS ns1.digimedia.com.

      ;; Query time: 145 msec
      ;; SERVER: 127.0.0.1#53(127.0.0.1)
      ;; WHEN: Thu Aug 2 08:22:23 2012
      ;; MSG SIZE rcvd: 95



      Thank you.

      --
      [Varadi Gabor]
    • Jim Reid
      ... No problem. It s *far* better than my Hungarian. :-) Besides, you ve provided full, unedited information -- log entries, dig output, etc -- which makes it
      Message 2 of 8 , Aug 2, 2012
      • 0 Attachment
        On 2 Aug 2012, at 08:38, Varadi Gabor wrote:

        > Sorry because my English.

        No problem. It's *far* better than my Hungarian. :-)

        Besides, you've provided full, unedited information -- log entries,
        dig output, etc -- which makes it clear exactly what the problem is.
        If only everyone did that....

        > The log details:
        >
        > Jul 31 23:58:22 fw postfix/smtpd[17580]: 6ABF8F:
        > client=localhost[127.0.0.1]
        > Jul 31 23:58:22 fw postfix/cleanup[18032]: 6ABF8F: message-id=<20120731065514.5F401D0D@...
        > >
        > Jul 31 23:58:22 fw postfix/qmgr[7846]: 6ABF8F: from=<>, size=3109,
        > nrcpt=1 (queue active)
        > Jul 31 23:58:22 fw postfix/smtp[18030]: 6ABF8F: to=<info@...>,
        > relay=0.0.0.0[0.0.0.0]:25, conn_use=24, delay=0.04,
        > delays=0.01/0/0/0.02, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
        > as 6E00018E)
        > Jul 31 23:58:22 fw postfix/smtp[18030]: warning: numeric domain name
        > in resource data of MX record for bond.com: 0.0.0.0
        > Jul 31 23:58:22 fw postfix/qmgr[7846]: 6ABF8F: removed
        >
        > # dig mx bond.com
        >
        > ; <<>> DiG 9.7.3 <<>> mx bond.com
        > ;; global options: +cmd
        > ;; Got answer:
        > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56868
        > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
        >
        > ;; QUESTION SECTION:
        > ;bond.com. IN MX
        >
        > ;; ANSWER SECTION:
        > bond.com. 600 IN MX 1000 0.0.0.0.

        First off, this is not a Postfix problem. The MX record for bond.com
        is spectacularly broken. It's an epic fail. That's what needs to be
        fixed. The administrator of this domain has to fix this. There's
        nothing you should do apart from contact him/her. According to whois,
        the contact for bond.com is administrator@.... Perhaps you
        could contact them? Maybe he/she has done this deliberately to prevent
        bond.com getting any email?

        The MX record is broken in two ways. The target of an MX record should
        be a hostname. It must not be a dotted-decimal string representing an
        IPv4 address. Next, an IP address of 0.0.0.0 is remarkably stupid. For
        most TCP/IP stacks, this will default to the current host. [It's
        actually more complex than that, but the detail isn't important here.]
        So your postfix implementation connects to itself whenever it opens a
        connection to port 25 on 0.0.0.0.

        BTW, I think it's wrong for Postfix to kludge around broken MX records
        like this. Though I realise that ugly/bad things like that are
        sometimes necessary to work around other people's stupid mistakes.
        However if the DNS lookup returns an MX record that looks to have a
        dotted-decimal instead of a domain name, this should not be getting
        treated as an IP address. IMO your postfix setup should be looking up
        that dotted decimal string in the DNS and then bouncing the mail when
        the DNS returns an NXDOMAIN because 0.0.0.0 (say) does not exist as a
        domain name.

        I would not reconfigure postfix to work around bond.com's brokenness.
        For one thing, that would be the start of a very slippery slope. How
        many more changes would you make to the configuration for errors
        elsewhere and how soon would that make your postfix setup impossible
        to maintain or debug? For another thing, if you did add some sort of
        special relay hook for bond.com, where would that domain's mail be sent?
      • Varadi Gabor
        ... I did not say that postfix would be a mistake :) The log also shows that the warning: numeric domain name in resource data of MX record for bond.com:
        Message 3 of 8 , Aug 2, 2012
        • 0 Attachment
          On Thu, Aug 02, 2012 at 10:18:42AM +0100, Jim Reid wrote:
          > First off, this is not a Postfix problem. The MX record for bond.com is
          > spectacularly broken. It's an epic fail. That's what needs to be fixed.

          I did not say that postfix would be a mistake :)
          The log also shows that the "warning: numeric domain name in resource data of MX record for bond.com: 0.0.0.0"

          I want solutions not only in this case in particular, but all similar cases.

          All DNS admin can not speak one at a time when there is an error.

          But I want to avoid mail loop.

          MAILER-DAEMON in this case would be sent mail back to the bond.com (mail was probably SPAM).
          Thus, deleting the mail queue was permitted.

          > I would not reconfigure postfix to work around bond.com's brokenness.
          > For one thing, that would be the start of a very slippery slope. How
          > many more changes would you make to the configuration for errors
          > elsewhere and how soon would that make your postfix setup impossible to
          > maintain or debug? For another thing, if you did add some sort of
          > special relay hook for bond.com, where would that domain's mail be sent?

          There mail.bond.com entry in the DNS.

          Thank you for your answer.

          --
          [Varadi Gabor]
        • Jim Reid
          ... Yes, I saw that. This should have resulted in a hard error, not a warning. ... IMO, the solution is to make sure postfix does The Right Thing and refuse to
          Message 4 of 8 , Aug 2, 2012
          • 0 Attachment
            On 2 Aug 2012, at 10:44, Varadi Gabor wrote:

            > The log also shows that the "warning: numeric domain name in
            > resource data of MX record for bond.com: 0.0.0.0"

            Yes, I saw that. This should have resulted in a hard error, not a
            warning.

            > I want solutions not only in this case in particular, but all
            > similar cases.

            IMO, the solution is to make sure postfix does The Right Thing and
            refuse to treat broken MX records that look like dotted decimals as IP
            addresses. Or at the very least make this behaviour configurable and
            have a sensible default. Weitse?

            If you're getting loops, perhaps you should install a current version
            of postfix? You said you had 2.7.something. Here's what happened with
            on a version 2.9.2 server when I just tried to email bond.com:


            Aug 2 10:57:20 hutch postfix/smtp[20772]: warning: numeric domain
            name in resource data of MX record for bond.com: 0.0.0.0
            Aug 2 10:57:20 hutch postfix/smtpd[20768]: connect from
            localhost[127.0.0.1]
            Aug 2 10:57:20 hutch postfix/smtp[20772]: warning: host
            0.0.0.0[0.0.0.0]:25 greeted me with my own hostname hutch.rfc1035.com
            Aug 2 10:57:20 hutch postfix/smtp[20772]: warning: host
            0.0.0.0[0.0.0.0]:25 replied to HELO/EHLO with my own hostname
            hutch.rfc1035.com
            Aug 2 10:57:20 hutch postfix/smtp[20772]: CA6391542837: to=<test@...
            >, relay=0.0.0.0[0.0.0.0]:25, delay=0.57, delays=0.24/0.01/0.32/0,
            dsn=5.4.6, status=bounced (mail for bond.com loops back to myself)
            Aug 2 10:57:20 hutch postfix/smtpd[20768]: disconnect from
            localhost[127.0.0.1]
            Aug 2 10:57:20 hutch postfix/cleanup[20771]: A4568154283E: message-
            id=<20120802095720.A4568154283E@...>
            Aug 2 10:57:20 hutch postfix/qmgr[32110]: A4568154283E: from=<>,
            size=2175, nrcpt=1 (queue active)
            Aug 2 10:57:20 hutch postfix/bounce[20773]: CA6391542837: sender non-
            delivery notification: A4568154283E
            Aug 2 10:57:20 hutch postfix/qmgr[32110]: CA6391542837: removed
            Aug 2 10:57:21 hutch postfix/smtp[20772]: A4568154283E: to=<jim@...
            >, relay=mailhost.rfc1035.com[93.186.33.42]:25, delay=0.51,
            delays=0.11/0/0.35/0.05, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
            as 24269CBC41C)
            Aug 2 10:57:21 hutch postfix/qmgr[32110]: A4568154283E: removed
          • Wietse Venema
            ... If you don t like the result, use one of the following in the SMTP daemon to block their mail: check_client_mx_access (ditto for helo, sender, recipient,
            Message 5 of 8 , Aug 2, 2012
            • 0 Attachment
              Jim Reid:
              > On 2 Aug 2012, at 10:44, Varadi Gabor wrote:
              >
              > > The log also shows that the "warning: numeric domain name in
              > > resource data of MX record for bond.com: 0.0.0.0"
              >
              > Yes, I saw that. This should have resulted in a hard error, not a
              > warning.

              If you don't like the result, use one of the following in
              the SMTP daemon to block their mail:

              check_client_mx_access (ditto for helo, sender, recipient, etc.)
              check_client_mx_access (ditto for helo, sender, recipient, etc.)

              Wietse
            • Wietse Venema
              ... [the second one should be check_mumble_ns_access, for blocking mail by their name server name or IP address] ... The prime directive for Postfix is to
              Message 6 of 8 , Aug 2, 2012
              • 0 Attachment
                Wietse:
                > If you don't like the result, use one of the following in
                > the SMTP daemon to block their mail:
                >
                > check_client_mx_access (ditto for helo, sender, recipient, etc.)
                > check_client_mx_access (ditto for helo, sender, recipient, etc.)

                [the second one should be check_mumble_ns_access, for blocking mail
                by their name server name or IP address]

                Jim Reid:
                > How do any of these things make postfix obey the DNS specs? RFC1034

                The prime directive for Postfix is to deliver mail reliably without
                sucking from a performance or human interface point of view, and
                without granting unnecessary privileges to random strangers.

                The prime directive is not to force other systems or operators to
                abide by RFCs. People who have enough time on their hands can write
                a suitable plugin for the policy protocol or Milter interface.

                Wietse
              • Wietse Venema
                ... I have an A record for warez.porcupine.org that resolves to 127.0.0.1. I could have used 0.0.0.0 instead and have gotten a similar result. Postfix
                Message 7 of 8 , Aug 2, 2012
                • 0 Attachment
                  Jim Reid:
                  > On 2 Aug 2012, at 14:17, Wietse Venema wrote:
                  >
                  > > The prime directive for Postfix is to deliver mail reliably without
                  > > sucking from a performance or human interface point of view, and
                  > > without granting unnecessary privileges to random strangers.
                  >
                  > Too bad your prime directive includes opening connections to port 25
                  > for 0.0.0.0 when people have misconfigured their MX records. :-)

                  I have an A record for warez.porcupine.org that resolves to 127.0.0.1.
                  I could have used 0.0.0.0 instead and have gotten a similar result.

                  Postfix documentation has plenty examples where sending mail to the
                  loopback address is entirely legitimate. It would be a mistake to
                  disallow sending mail to "reserved" address ranges by default. Such
                  decisions are necessarily site-specific.

                  This is what I use to exclude mail sources that resolve to a reserved
                  address range. Note that I exclude sources, not destinations:

                  /etc/postfix/main.cf:
                  smtpd_whatever_restrictions =
                  ...
                  check_sender_mx_access hash:/etc/postfix/mx_access
                  ...

                  /etc/postfix/mx_access
                  #64.94.110.11 reject mail host in verisign wild-card domain
                  127 reject mail host in loopback network
                  10 reject mail host in reserved network 10
                  192.168 reject mail host in reserved network 192.168

                  Other sites may have a local address range in 10.* or 192.168.*,
                  and therefore can't exclude those as invalid mail sources. There
                  is no rule that works for everyone.

                  Wietse
                • Viktor Dukhovni
                  ... By default though Postfix would have accepted the message, the delivery attempt to 0.0.0.0 would have failed with a loops back to myself error. The OP
                  Message 8 of 8 , Aug 2, 2012
                  • 0 Attachment
                    On Thu, Aug 02, 2012 at 11:27:52AM -0400, Wietse Venema wrote:

                    > > On 2 Aug 2012, at 14:17, Wietse Venema wrote:
                    > >
                    > > > The prime directive for Postfix is to deliver mail reliably without
                    > > > sucking from a performance or human interface point of view, and
                    > > > without granting unnecessary privileges to random strangers.
                    > >
                    > > Too bad your prime directive includes opening connections to port 25
                    > > for 0.0.0.0 when people have misconfigured their MX records. :-)
                    >
                    > I have an A record for warez.porcupine.org that resolves to 127.0.0.1.
                    > I could have used 0.0.0.0 instead and have gotten a similar result.

                    By default though Postfix would have accepted the message, the delivery
                    attempt to 0.0.0.0 would have failed with a "loops back to myself" error.
                    The OP must have tweaked his configuration to disable loop detection.

                    Refusing to connect 0.0.0.0 is not substantially more effective
                    than detecting the loop on the first delivery attempt. As for
                    blocking mail from sites with bad MX records, such policies need
                    to be site-specific, as many a clueless administrator operates the
                    DNS for someone's most important sender. More legitimate mail would
                    be lost by strict enforcement than spam rejected.

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