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

Re: badly broken mx record for bond.com

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