Can't Solve Relay Access Denied Issues

I'm sorry to beat this issue any further, but i have had no luck on all my searches for a solution. I have a 2003 Server with Exchange 2003. I have various clients who are using RPC over HTTP and it has been very successful. In fact, 95% of the emails go through properly. At least every day however, one of my clients forwards me a message with an NDR. Sometimes it's the same, sometimes it is different. Here's what we might receive:

#5.5.0 smtp;553 sorry, mail to that recipient is not accepted (#5.7.1)>
smtp;554: Relay access denied
#5.7.1 smtp;550 5.7.1 Unable to relay for ...
;553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)>
5.5.0 smtp;550 No such user - psmtp
18591 is currently not permitted to

Now, i've tried many of the things that are suggested out there, with turning off/on SMTP Auth, i've verified that the reverse DNS is to my correct server address. I have a Barracuda firewall scanning incoming email, which i have removed and still get the messages. I've even gotten messages bounced back saying "no such user" when we are sure that there is a user at the destination address.

I get a 'relay access denied' when i, myself send a message to a particular domain. If i re-send the email two seconds later, the reciipient gets it.

I'm sorry to be so vague in my descriptions, but i' can't seem for the life of me to solve this problem once and for all! Any advice would be appreciated.
gloafmanAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

debuggerauCommented:
Yes, I got this too sometimes, what really improved its reliability was to use a better DNS server for the lookups. It appears some DNS servers fail to give the right MX record, or were set to use another server where a SMTP receiver was not present.

I still get them occasionally when sending to flaking domains, but at least now I can point the customer to their email server or provider.

I also used the detailed SMTP logs to deduce this, really helps...
0
Xyptilon2Commented:
Relay access denied, means a server will not send the message because it is configured not to do so. Either because the sender is unknown or the IP from where the email is coming is unknown.

First, looking at the latter, a server might employ SMTP authentication (with, or without SSL or TLS) or POP BEFORE SMTP authentication to tell the server that the connecting IP address (client machine) is allowed to send email and the server will relay in this case. (I hope your machine is not an open relay so you should be employing one of these 2 methods).

Second, not all NDR are legitimate, some are spam, however I'm guessing we can rule that out as a possibility for now and we are dealing with a real issue.

Setting up a PTR record with whoever manages your IP address/range is a good idea to minimize spam, since receiving mailservers or anti-spam appliances (like Barracudas) might do a reverse DNS check to see if it matches the hostname in the email header.. if not, it may be tagged as spam.. However...though it may be tagged, it is unlikely to generate the above mentioned error messages. It will more likely generate a 451 or 452 message (if any at all).

In a case like this, it would be very useful if you have access to the mailserver logs, particularly from the smtpd daemon/service or better yet, if you can record the SMTP conversation between the servers. Either with a "recordio" like utility or a TCP sniffer in verbose mode to troubleshoot the issue.

If that is not an option, open a telnet window on port 25 to your mailserver and manually inject a message. Sometimes you get a more meaningful error message there: Just search Google for "telnet test smtp" and many hits will come up.

Lastly, the above error, really is a relaying issue, sometimes this happens because of DomainKeys or SPF violations. Is your mailserver using this? To what behaivour is it set? tag only or does it do more? If there is an anti-spam appliance in between (like the Barracuda), what do these logs say? Probably they would say "allowed", but they can still be blocked for technical reasons or SPF violations.  For example if Domain A sends to you through the Barracuda then it will be blocked since the Barracuda is not in the SPF record of Domain A. and will not arrive at B, though this should generate another message (and not one of the above).


0
mikeshaverCommented:
Is the server GC?
0
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

gloafmanAuthor Commented:
Apologies on all the late replies...The problem was that my domain manager had an SSL arranged and pointing to the domain 'mail.theserver.com', whereas my server's actual name (net BIOS and all) was exchange.theserver.com. The ssl was mismatched and I am positive that this mismatch affected the reverse look up. Most recipients did not care if their servers didn't do reverse lookups, but for the odd percent that did, it was a huge pain.

While i could have probably re-generated an SSL, and reconfigured the domain settings to match that of my server, i was in no way going to change the 'server' name of a running exchange box. I created a new domain, new SSL and ensured that it all matched, then migrated all of my users to a new server. Yes, definately 'overkill', but it worked and never got a 571 again.

Phew.

Thanks to all those that contributed.
0
mikeshaverCommented:
So you're GC?
0
gloafmanAuthor Commented:
Apologies on all the late replies...The problem was that my domain manager had an SSL arranged and pointing to the domain 'mail.theserver.com', whereas my server's actual name (net BIOS and all) was exchange.theserver.com. The ssl was mismatched and I am positive that this mismatch affected the reverse look up. Most recipients did not care if their servers didn't do reverse lookups, but for the odd percent that did, it was a huge pain.

While i could have probably re-generated an SSL, and reconfigured the domain settings to match that of my server, i was in no way going to change the 'server' name of a running exchange box. I created a new domain, new SSL and ensured that it all matched, then migrated all of my users to a new server. Yes, definately 'overkill', but it worked and never got a 571 again.

Phew.

Thanks to all those that contributed.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Email Servers

From novice to tech pro — start learning today.