?
Solved

5.7.1. Unable to Relay (despite domain being in Recipient Policies) on Exchange 2003

Posted on 2005-04-07
11
Medium Priority
?
692 Views
Last Modified: 2012-06-21
I have a Windows 2003 Server running Exchange 2003 Standard Edition (machine "Beta" - all names have been searched and replaced with generic names) within a domain currently running Active Directory hosted on a Windows 2000 Server (machine "Alpha"). The server is *not* itself running Active Directory (it is a member server) as documents have advised against upgrading the schema of an Exchange server (it is an unsupported configuration). This server has been used for internal e-mail and shared calendars, etc, but we now wish it to e-mail that is from a standard Internet domain. The internal domain is effectively "domainname.local" (this is the sole domain under Active Directory) and the external domain is "externalname.com".

I have set up Exchange in the past (5.5) to handle external domain names mail being delivered to it. However, I am having trouble with setting up this functionality on 2003. Starting with the defaults provided on the property pages of "Default SMTP virtual server" I changed the following:

Under Delivery, I changed the fully-qualified domain name to mail.externalname.com. I have pointed a MX record to that A record, which in turn points at my firewall with port 25 forwarded to the exchange server. Using an external machine, "telnet mail.externalname.com 25" connects me to my server (I can see the session in "Current Sessions").

When I connect, I get:

220 BETA.DOMAINNAME.LOCAL Microsoft ESMTP MAIL Service, Version: 6.0.3790.211
 ready at  Thu, 7 Apr 2005 09:18:35 -0700
 
And when I run the following:

ehlo testdomain.com
mail from: tester@testdomain.com
rcpt to: administrator@externalname.com

I get:

550 5.7.1 Unable to relay for administrator@externaldomain.com.com

This was the expected result, as only the Active Directory domain "domainname.local" should be available.

I then went to Recipient Policies->Default Policy (the only one we have) property pages.

On the E-Mail Address (Policy), I used New.. to add "@externaldomain.com" and then set it as primary and finally removed the existing "@domainname.local" from the list. I asked for the changes to be applied now on clicking "OK".

I expected to be able to do a "rcpt to: administrator@externalname.com" but was greeted with the same 550 5.7.1 message. So I restarted the SMTP protocol, Exchange and eventually the entire machine to no avail. I then read that you may have to do a "rebuild" on the Recipient Update Services items. I did so on both the (Enterprise Configuration) and (DOMAINNAME) entry lines. It said it may take hours, but we have only 20 users so I expected it to work fairly soon. The next day I came back to this task and I still get the relay message.

So, I apparently missed something essential to convince the Exchange server that it is responsible for the "externaldomain.com" addresses. I'm looking for the step I missed.
0
Comment
Question by:Godeke
  • 7
  • 4
11 Comments
 
LVL 104

Expert Comment

by:Sembee
ID: 13735012
Two things...

Is this new external domain the default domain name listed in recipient policies? Is it enabled in recipient policy?

I would also suggest that you change the FQDN entry on the SMTP Virtual Server as .local isn't valid and some remote servers may trip over that.

ESM, Admin Groups, <your admin group>, Servers, <your server>, Protocols, SMTP. Right click on the Default SMTP Virtual Server. Click on the last tab "Delivery" then the button "Advanced". Enter in the box FQDN the name your machine is know as to the Internet (mail.domain.com or whatever). Apply/OK out.

Simon
Exchange MVP.
0
 

Author Comment

by:Godeke
ID: 13736531
<i>Is this new external domain the default domain name listed in recipient policies? Is it enabled in recipient policy?</i>
@externalname.com was added to the Default Policy and set as primary, the default @domain.local was removed. There are no other policies under Recipient Policy.

<i>I would also suggest that you change the FQDN entry on the SMTP Virtual Server as .local isn't valid and some remote servers may trip over that.</i>
The fully-qualified domain name is "mail.externalname.com". I have pointed a MX record to that A record, which in turn points at my firewall with port 25 forwarded to the exchange server. Using an external machine, "telnet mail.externalname.com 25" connects me to my server (I can see the session in "Current Sessions").

Both of these steps had already been performed, as detailed in the initial message. (I did just double check to ensure they were *saved* that way, and they were.) What bugs me is the fact that despite these changes when I connect I get the "220 BETA.DOMAINNAME.LOCAL Microsoft ESMTP MAIL Service, ..." greeting. You comment leads me to believe that the FQDN change *should* have altered the banner? (That was my naive thinking on the matter, but it has not happened). On the other hand, outbound mail acts as I would expect (and works, just nobody can successfully reply because of the relay message). Outbound e-mail gets the @externaldomain.com suffix properly added to their user name and the message is delivered properly. Attempts to reply in Outlook get the same 550 5.7.1 error as my manual telnet to port 25 does.

I am beginning to think that there is something broken with Exchange, but this it is a default installation except for the changes outlined above, so I can't think of any good reasons to suspect Exchange. (The only other changes made were to add some public folders.) Is there nothing else required beyond the FQDN and recipient policy changes to get Exchange to receieve for a particular name?
0
 
LVL 104

Expert Comment

by:Sembee
ID: 13737203
Are you sure that you have changed the right place? The banner is announcing the wrong name so I don't think you have. Even that shouldn't be necessary for the email to come in, it is usually required for sending email when recipient servers check what the banner says and then do a lookup on name to ensure that it matches.

Try pulling the domain out of recipient policy. Leave it for at least 30 minutes to replicate that change out and then replace it. Remember to restart at least the SMTP service, and preferably all of Exchange. The command iisreset is good for restarting what it is required.

Simon.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 

Author Comment

by:Godeke
ID: 13738329
ESM -> Domain (exchange) -> Recipients -> Recipient Policies -> Default Policy [only one in list] (right click) -> Properties -> E-Mail Addresses (Policy) (tab)

Currently shows two items: SMTP with value "@externaldomain.com" and X400 with value "c=us;a= ;p=Domain;o=Exchange;". I can't remove the SMTP (only New and Edit are available buttons) and unchecking it gives "The SMTP primary address cannot be disabled. All recipients must have an SMTP address in Microsoft Exchange".

Hmmm, here is something interesting. I *removed* "@domain.local" and yet when I try leaving the explicit domain off:

=========== test below
telnet mail.escalanteconcrete.com 25

ehlo imkservices.com
mail from: jlopez@imkservices.com
rcpt to: administrator
=========== end test

I get the response: "250 2.1.5 administrator@DOMAIN.LOCAL"

This would seem to indicate that your idea that I didn't make the change in the right place has some merit, but as I only have a Default Policy, I'm not sure where else I *could* make this change. Anyway, for the sake of experimentation, I am changing the default SMTP domain back to "domain.local". This givies "The e-mail Addresses of type(s) [SMTP] have been modified. Do you want to update all corresponding recipient e-mail addresses to match these new address(es)?" I have replied yes. It is interesting to note that my outbound messages from Administrator *were* properly suffixed with "@externaldomain.com" prior to this change, which means the policy *seems* to have propogated the first time.

I will update again once I have had a chance to cycle through your recommened changes. I think you are on the right track, I just need to find out where the problem is.

(As a side note, this server has been exposed to the Internet and had a MX record for a whopping 3 days now, and I already have dozens of "550 5.7.1 Unable to relay for china9988@21cn.com" type log entries. Spammers are relentless. I guess the fact that I can't relay legitimate e-mail because of the default locked down policy is a good thing, I just need to figure out how to get things right.)
0
 

Author Comment

by:Godeke
ID: 13740021
For my next step, I had the Recipient Update Service rebuild (the "do you want to update all corresponding..." message seemed to imply that it would do so, but hours later none of the user accounts showed any change to their e-mail (they were all still "username@remotedomain.com"). Moments after the rebuild was requested, the users now show "username@domain.local". An attempt to send with the administrator account bounced on my personal SMTP server with a 533 5.1.8 (which is good, my server recognized the bogus domain and rejected).

A stop and restart (and hour doing other stuff) later, I figure it is time to restore my desired configuration.

I use the same procedure (and agree to the previously useless rebuild question) and behold, the user accounts almost instantly are respecting the new "@remotedomain.com" suffix.

Stop and restart everything... hopeful that the correctly updated user account information was a sign... and... we are right back where we started. Outbound e-mail is sent as "administrator@remotedomain.com" but attempts to reply to this address fail with the 5.7.1 error. Likewise, the banner still shows beta@domain.local and sending to a domainless name suffixes with @escalante.local.

It is almost like the SMTP server wasn't respecting the changes I am making. I would think that I was connecting to something other than Exchange except for:
a) I only have the Default SMTP Virtual Server
b) I can see the session fire in Current Sessions of the same.
c) I can terminate the current session and my telnet mail.remotedomain.com session is terminated ("Connection to host lost.").

So I'm connecting to exchange, but it apparently really doesn't care about Recipient Policies, except to update the user's SMTP entry in active directory. This is an extraordinarly simple Exchange install (less than 20 users, only two machines: the Exchange machine and the Active Directory machine, no funky connectors or other changes).

0
 
LVL 104

Expert Comment

by:Sembee
ID: 13740111
Did you remove the .local domain or leave it in?

If you removed it, put it back in so that it is alongside the external domain and make it the default.
Force Recipient Update Service to run so that all the users have two addresses. The external address should be the default though.

However if you have changed/added the FQDN information in the exact location that I have indicated, but it isn't changing the banner then I have suspect that the SMTP part of IIS has got corrupt. That would involve a reinstall of IIS. This article at MS explains how to do that: http://support.microsoft.com/?kbid=320202

Simon.
0
 

Author Comment

by:Godeke
ID: 13740315
Yes, I made that change at:

ESM -> Domain (Exchange) -> Servers -> Beta -> Protocols -> SMTP -> Default SMTP Virtual Server -> (right click) Properties -> Delivery (tab) -> Advanced -> Fully-qualified domain name. That is currently set to mail.externaldomain.com. Clicking Check DNS says "the domain name is valid". I also did some testing with the "Exchange Server SMTPDiag Tool" and it came back green lights on all tests, both when run on the local LAN and when run on a remote machine.

http://www.microsoft.com/downloads/details.aspx?familyid=bc1881c7-925d-4a29-bd42-71e8563c80a9&displaylang=en

I'm having to tend to the corruption theory, as nothing I do in the interface seems to impact the actual SMTP. Active directory is updating correctly. I will go ahead and place "domain.local" back in as a SMTP alternative, leaving "remoatedomain.com" as the default. I will then attempt the solution described in the knowledge base article you have linked to. Thank you for the help so far, and here's hoping I can follow those instructions and give you some points for your helpfullness. Heck, I will give them even if it doesn't, if only because you have confirmed I'm not a start raving fool.
0
 

Author Comment

by:Godeke
ID: 13744990
Well, that turned out to be giant waste of time. When Exchange is not installed, I can use the IIS SMTP component and change the FQDN, which is reflected in the banner. I can use the domain names control in IIS SMTP to get the messages to be accepted. As soon as I reinstall Exchange, I'm right back to square one: the SMTP FQDN settings are completely ignored and adding domain names to the Recipient Policies makes no difference to the relay status. As an added bonus, removing exchange so I could reinstall IIS requires that I restore the old message store's data at some point, but I am reluctant to do so with such a seemingly simple function failing so miserably.
0
 

Author Comment

by:Godeke
ID: 13745091
As an additional point of information, I attempted to create a second SMTP Virtual Server, running on port 2525. I did this because I was curious why my settings were not being respected. I just accepted everything as default *except* changing the port number to 2525 to avoid conflicts.

The result was surprising. First, the new Virtual Server wants to default it's directories to "C:\Program Files\Exchsrvr\Mailroot\vsi 2". No problem, except that creating the new virtual server didn't create those directories. So, I copied vsi 1's folder structure and permissions and tried to start the virtual server. In the error log I get "Virtual Server 2: SMTP server cannot read metabase key MailQueueDir." and "Virtual Server 2: SMTP server cannot read metabase key MailPickupDir."

It would appear that Exchange has absolutely zero control over the SMTP subsystem on this machine. I am at a loss to explain this. I would normally say at this point "just reinstall exchange"... but I'm on reinstall number 5 over last night and today and no farther along. I already have a ton of egg on my face over choosing to go with Exchange (in an attempt to replace a ancient Sendmail on Linux box), so any ideas would be helpful.
0
 
LVL 104

Accepted Solution

by:
Sembee earned 2000 total points
ID: 13745205
I have seen some Exchange servers in a mess in my time... but that is a very sick server.

It sounds like the IIS metabase has taken a serious hit.

What I can tell you is that if you go for the reinstall, the restore of the data restores JUST the data. It will not bring any of the corruption from the previous install across. This is a problem with the underlying IIS - not Exchange itself.

I suspect that whatever the problem is with the IIS configuration it isn't being removed as part of the uninstall. Trying to find the corruption could be difficult.

I think that you don't have much choice right now.

The machine needs to be wiped and rebuilt.

A number of options available to you for that...

1. Migrate to a new machine. If you have something that can run Exchange while you do the rebuild you could move the data across. This makes life a lot easier as you haven't got to hack out Exchange from the AD.

2. Export all the data to pst files using exmerge then remove Exchange

3. Reinstall Exchange on the new install using /disasterrecovery switch and then restore backups of the information store.

I feel for you having these problems. As an Exchange MVP I hate to see an Exchange server blow up in someones face with problems as serious as this. I know that Exchange can be a rock solid stable mail server that do what it says on the tin. When there are problems though it can go wrong quite badly and make the person who convinced the company to use Exchange look bad.

Simon.
0
 

Author Comment

by:Godeke
ID: 13755185
OK, for the moment what I have done is make manual edits to the metabase and restored the clients data. Nothing else is giving me any hickups, but when I have more time I will have to rebuild this environment. I'm thinking my best option will be bringing another machine in and making it a part of the organization so I have something to fail over to. Then I can rebuild this machine. It is a small organization, so I will have to bring some other value in with the new server to make that fly with the client (they currently only have a Active Directory machine that also serves up files and this machine).

I have used Exchange in the past and overall have been happy with the product... just very frustrated (and bleary eyed). All of their data is restored and working, and inbound and outbound mail works fine. You are correct that this is something with the IIS (or more specifically, Exchange's control over IIS). When I have Exchange off the machine, IIS works wonderfully. When I put Exchange back on, IIS takes a nosedive. However, thanks to the Metabase Browser I was able to create a second domain for SMTP and get it to work (I simply examined what IIS was doing when there *wasn't* an Exchange server and then manually replicated that process). Ugly, probably incorrect, but gets me through *this* week.
0

Featured Post

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Stellar Exchange Toolkit: this 5 in 1 toolkit comes loaded with mega-software tool. Here’s an introduction to tools’ usage and advantages:
If you have come across a situation where you need to find some EDB mailbox recovery techniques, then here you will find the same. In this article, we will take you through three techniques using which you will be able to perform EDB recovery. You …
In this video we show how to create an Address List in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Organization >> Ad…
To show how to create a transport rule in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Mail Flow >> Rules tab.:  To cr…
Suggested Courses

850 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question