450 Host down (us.af.mil)

We have had this issue since the Air Force had changed their MX records for their domain. It started as a 550 Host Unknown but the work around was adding a static path to the Route.cfg file. That lasted for a while and now fails with a 450. All the research I had done pointed towards the DNS as the issue but that is not the case. We had an independent consultant come in and confirmed that it is related to the GWIA.

I have read many threads so I know I am not the only one with that has come across this issue. I just haven't been able to find a fix.

Thank you in advance for the help!

Tom

Tags:

  • Am 14.04.2017 um 19:36 schrieb scecere:
    >
    > We have had this issue since the Air Force had changed their MX records
    > for their domain. It started as a 550 Host Unknown but the work around
    > was adding a static path to the Route.cfg file. That lasted for a while
    > and now fails with a 450. All the research I had done pointed towards
    > the DNS as the issue


    When you use a route.cfg entry for that domain, DNS can't be the issue
    as it never even comes into play. Did you remove the reoute.cfg entry?
    Have you verified it's still correct?


    > but that is not the case. We had an independent
    > consultant come in and confirmed that it is related to the GWIA.


    How so? If the consultant couldn't tell you how this is "related" to
    GWIA, he essentially has no idea whatsoever I'm afraid.

    > I have read many threads so I know I am not the only one with that has
    > come across this issue. I just haven't been able to find a fix.


    A 450 Host Down means:

    1. GWIA (thinks it) knows what server it has to talk to for that domain.
    If it can't resolve the domains MX or A records, you'll get a 550 Host
    Unknown, and yes, that always *is* a DNS issue.

    2. GWIA can't talk to the server it thinks is the right one.

    Debugging is really pretty basic.

    A. Check the verbose GWIA logs what IP address it is trying to connect
    to for that domain.

    B. Verify that is the correct IP. If it's not, find out why your server
    is resolving to the wrong IP. Use nslookup directly on the server
    running GWIA to check.

    C. If the IP is correct, try to connect to that IP using telnet on port
    25. You will probably not get a connection. Next step is to debug the
    communication issue your server is having connecting to the destination.

    That's really all there is. SMTP is no rocket science. There's hardly
    anything GWIA could do wrong here.

    CU,
    --
    Massimo Rosen
    Micro Focus Knowledge Partner
    No emails please!
    http://www.cfc-it.de
  • scecere wrote:

    > and now fails with a 450


    This does not necessarily mean that the host is down although that is
    often how it is interpreted.

    A more accurate interpretation is: Your message was not delivered
    because the other user mailbox was not available.

    This could be a result of "Greylisting".
    https://en.wikipedia.org/wiki/Greylisting

    I encountered similar issues, most of which were resolved by adjusting
    the timings and number of re-send attempts.

    --
    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.
  • In article <scecere.7wyclz@no-mx.forums.microfocus.com>, Scecere wrote:
    > We have had this issue since the Air Force had changed their MX records
    > for their domain


    That sort of change can upset things if there is an old static entry
    anywhere along the line.

    A good tool for testing is NirSoft's DNSDataView
    http://www.nirsoft.net/utils/dns_records_viewer.html
    It allows you to test against specific DNS servers for a given result.
    So you could start with a couple common public DNS servers such as
    Google's 8.8.8.8, compare with the DNS server your GWIA server is
    pointing to, as well as what IP GWIA actually uses as seen in its logs.
    CheckTLS.com is another good tool as it shows the full email connectivity
    from another point of view that you can compare to your results.

    For example, CheckTLS showed a connection to the primary MX record as
    pri-usaf-eemsg.eemsg.mail.mil[156.112.250.199] but DNSDataView pointing
    to 8.8.8.8 showed that host's IP as 156.112.250.198, so clearly they have
    mulitple servers under that host name, likely with some round robin DNS
    going on for the A record.

    Also seen from the CheckTLS is that 156.112.250.199 does not have TLS
    currently available and the rest of the mail hosts have self signed
    certs. So if we had the ability to have TLS set as mandatory, that might
    caused some grief.

    As per Kevin, check your resend options. Whether or not Grey Listing is
    in force, there are many possible transient issues that could stop mail
    from getting through, especially if you are pointing to just one mail
    server for such a busy domain. In the Properties of GWIA, SMTP/MIME
    settings, "Intervals to retry a deferred message" I go for a few rapid
    retries then grow them out to a longer cycle to accommodate different
    reasons a host might not be able to accept mail for a time. Example of
    what I typically put in there is 2,5,10,20,20,60,120 that retries 2
    minutes after first attempt, 5 minutes after that and so on. Handles grey
    listing nicely as well as simple server reboots or busy servers, then
    backs off for the longer outages (power, upgrade, moves, etc..)

    Once you have all that sorted out, what is left is networking basics of
    either routing is obstructed or the port is blocked somehow at some
    point. One possibility is if your IP has been black listed and their
    firewall just drops its packets, so do check it out at
    https://www.rbls.org/ (this checks a whole bunch of black lists.)



    Andy of
    http://KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!