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

badly broken mx record for bond.com

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.