Troubleshooting 554 Relay Access Denied NDRs

Advertisements

This week I was called up by a former employer to come in and check out their Exchange 2003 server. They had been having problems with a few domains rejecting their e-mails for the past few weeks and what made it a big problem was that one of the domains was their largest customer. Not a good scene there. They were receiving several NDRs of which the most prominent was something like <mail.domain.com #5.7.1 smtp;554 5.7.1 foo@otherdomain.com: Relay access denied> as well as some from another domain referencing authentication. I don’t have it in front of me so unfortunately I can not quote it. Doing some research I found that there was not much information on troubleshooting this and related problems even though there were lots of people asking. So I am putting together a quick little guide based off how I came to a resolution. Your results may vary.

E-mail problems generally break down to two types. Either you are having DNS problems, or you have a misconfigured server. First thing to do of course is to narrow down whether the problem is on your end or if it is on their end. Generally one would suspect the problem to be on their end when it is only a couple of domains giving you a problem, but that isn’t always the case. Easiest way to narrow it down is to break out the command line utilities. First verify that you are using the same DNS as your Exchange server. This is very important otherwise it may skew the results of your test. Next off you need to find your problem domain’s mail server. You have several options for this. The lazy way is to go to MX Lookup Tool and put in the domain. It should return the mail servers for that domain. You’d be best off going with the first one. The site also has some interesting diagnostic utilities that you could run against your mail server as well as their own. The non-lazy method, and one you should learn anyhow, is using nslookup. Pop open your command line and run nslookup. Here’s the steps to go through to get the MX records for their domain.

There’s the mail server that you are working with. Sometimes there are more than one so start from the top and work your way down. Next up is we’re going to send an e-mail the archaic way, through telnet. Note that not all SMTP servers respond with the exact same banners and responses, though the codes should generally line-up. Open up a telnet prompt.

If you get a 250 Ok at this point then telnet will most likely complete successfully. Also if you get a 510 Bad user that is ok as well, since you are not getting a relay access denied which is what your Exchange server is getting when it communicates with this server. This means their server has passed the telnet test so you need to start digging into your server to fix the problem. If you get a 550 Relaying denied error though that is different. Time to modify the test. Change your DNS server to a known good external DNS server that resolves both forward AND reverse look-ups correctly. If it does not resolve reverse look-ups it is no good to you. Switch your machine over to that DNS server and run through the test against. If it is successful then you’ve tracked the problem down. Time to look at what DNS servers your Exchange is using. Or it may also be time to check on your own internal DNS servers, as they may not be resolving addresses correctly. If, though, you receive a failure from your telnet test with a known good set of DNS servers then things may be a bit more complex. Do a look up on whether your domain is in any Realtime Blackhole Lists (RBL). If it is then definitely check to see if you are running an open relay and get yourself off those lists fast. If not then you had best get on the phone with the admin over at problemdomain.com to find out if your domain has been blacklisted. Finally another thing to verify is your SPF record on your external facing DNS. Here is a site to help craft an SPF record.

For completeness here are the rest of the directions to finish sending your e-mail through telnet:

In case you were wondering at the client’s site it turned out the Exchange server was set up to use an external DNS server that was not resolving reverse look-ups. This was causing a few sites to return the 554 relay access denied NDRs.

You can also run a complete security test on http://www.EmailSecurityGrader.com – it has an extensive Open Relay test (including % hacks) and also includes several other email security tests (SPF, DNSBL/Spam Blacklist) which noawadays are at least as important as Open Relay.

I do prefer the simplicity of mxtoolbox.com but for this site I like the write ups it gives about some of the tests that it ran. It could help for explaining some necessities to the client in layman’s terms.

This past Friday morning I sent a text e-mail to a colleague w/o any problem. Later in the day, I received an e-mail from a vendor, requesting an acknowledgement. I pressed YES to acknowledge and OUTLOOK EXPRESS came back w/ the following ERROR message: The message could not be sent because one of the recipients was rejected by the server. The rejected e-mail address was ‘********@gmail.com’. Subject ”, Account: ‘#############. #1’, Server: ‘smtp.knology.net’, Protocol: SMTP, Server Response: ‘554 5.7.1 : Relay access denied’, Port: 25, Secure(SSL): No, Server Error: 554, Error Number: 0x800CCC79
I have blocked out the actual address part (*) for my own security purposes, as well as the company name (#). Since then I have not been able to send any e-mails, even to myself. However, I DO receive e-mails from other sources. This PC is running XP (SP3), and I use OUTLOOK EXPRESS. When I access my gmail acct. through the gmail website, I can send & receive the e-mails normally. I prefer to use OUTLOOK EXPRESS because it is a better screen layout & I can save all my correspondence to individual folders for later recall or reference.
Thank you.

It sounds like you have your SMTP server configured in Outlook Express for smtp.knology.net but you do not have the authentication configured correctly. You’ll either want to figure out the correct authentication for that or configure for sending through gmail’s servers. You can find instructions for configuring that here: http://mail.google.com/support/bin/answer.py?answer=76147
You’ll specifically want to take a look at steps 13 and 14.

I like all of the information that you have presented, but I am still stuck trying to troubleshoot a problem on my own server. I perform the nslookup and use the mxtool.com to verify the recepients mail server. The problem is that when I attempt to telnet to this server, I only get “554 servername.com” and it ends the connection.

I have tried different DNS servers, including google’s 8.8.8.8 to see if it was wrong reverse DNS look up entries, but they all come back correct. I am kinda stumped as to what would cause this problem.

If you’re getting back a 554 that means the server is dropping your connection. It should supply a reason but that doesn’t always mean that it will. Either their server is configured incorrectly or your public IP you are connecting from is on a blacklist they use. I would recommend running the address your system connects from through a blacklist check and also a diagnostic to be sure that you aren’t running an open relay just in case it connects back to verify these things when you connect.

So this is happening for several domains? In that case it is more likely to be a problem on your end rather than their end. Were you ever able to send to these domains? Check over if anything has changed in your configuration. If you have it available try updating your outbound SMTP NAT rule to a different public address and then try your telnet attempts again and see if you’re still being blocked. The connection does get dropped before you send the EHLO, correct? That definitely sounds like a blacklisting to me. If you were freshly blacklisted by someone, such as spamhaus, it can take a bit before the ip is listed in their database when you search against it.

[…] very few Exchange administrators seem to use it. You can see some of this in action in my previous NDR troubleshooting post. So let’s delve into some of the basics of how to use telnet for troubleshooting your mail flow […]