Exchange 2007 internal SMTP Relaying from Application Server - Help!

[EvilGrin]

Hi guys, having an issue with an application that sits on our SQL server that is supposed to send out reports in PDF format periodically to certain internal email addresses, really need some help with it!

To explain the setup: We have a single Exchange 2007 server, in EMC, under Server Config/Hub Transport, I have configured an SMTP Receive connector which has the IP address of a network scanner that is used every day to "Scan to E-Mail" which works 100% flawlessly, I have now added the IP address of our SQL server as well under "Receive mail from remote servers that have these IP addresses:". After I did this, I figured it'd just work. I was wrong.

The application support team have sent me a document and insist that I need to create a virtual SMTP service on our SQL server to get the relaying to work, I told them that it should not be necessary as this is Ex2007, not 2003, but I said I'd try it anyway. So I created it, configured it to allow relaying from any IP on the network as per their document, then tested the scheduled reports, sending them to internal and external mail addresses. The internal ones never showed up, no trace of them in Mail Tracking either, however the external recipients all received the report... wtf?

I've Telnetted from the SQL server to the Exchange server on port 25 and sent a mail to myself which arrived with no problem, I've turned off anti virus (Symantec Endpoint Protection with Network threat etc. disabled), windows firewall disabled, no ISA server, so there should be nothing blocking network traffic between servers. I'm thorougly confused and could really do with any advice you guys could offer.

Cheers!

 

[EvilGrin]

could it have anything to do with what's selected (or not) on the "authentication" or "permission groups" tabs on the receive connector maybe?

It's been a long while since I've looked at them so can't really remember what's what but it's an idea?

Thanks for the reply Yeah, I thought of that, so I've basically ticked everything on the Permission Groups tab, then I also tried various combinations of TLS auth/Basic Auth/Exchange server auth/Integrated Windows auth and Externally secured by itself. Nothing at all has worked... there isn't even a trace that I can see that any connection attempt is being made to the exchange server from the SQL server... mind you, barring the mail flow tools built into EMC (which are showing no trace), I'm not sure where to start looking.

 

[EvilGrin]

Ok, I just set the application server to point to the exchange server IP (instead of using the SQL server's virtual SMTP setup malarky) and I'm still receiving the "5.5.4 Invalid Domain Name" error, so I took a look at the receive connector logs and this seems to be the following entry that's going awry:

2010-09-06T09:34:17.728Z,EXCHSVR\Default EXCHSVR,08CD067EA2CA543A,0,exsvrIP:25,sqlsvrIP:4540,+,,
2010-09-06T09:34:17.728Z,EXCHSVR\Default EXCHSVR,08CD067EA2CA543A,1,exsvrIP:25,sqlsvrIP:4540,*,SMTPSubmit SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2010-09-06T09:34:17.728Z,EXCHSVR\Default EXCHSVR,08CD067EA2CA543A,2,exsvrIP:25,sqlsvrIP:4540,>,"220 EXCHSVR.domain.local Microsoft ESMTP MAIL Service ready at Mon, 6 Sep 2010 10:34:17 +0100",
2010-09-06T09:34:17.728Z,EXCHSVR\Default EXCHSVR,08CD067EA2CA543A,3,exsvrIP:25,sqlsvrIP:4540,<,HELO SQLSVR ,
2010-09-06T09:14:24.001Z,EXCHSVR\Default EXCHSVR,08CD067EA2CA53DD,4,exsvrIP:25,sqlsvrIP:4461,>,501 5.5.4 Invalid domain name,

Firstly, it seems that my Default receive connector, "Default EXCHSVR", is over-riding the new one that I created which I named "Internal SMTP" and set it up for relaying from the SQL server IP.

Secondly it's throwing up this Invalid domain name error; I believe that it's the space after the SQL server's computer name in the HELO line, so I'm guessing that's a coding issue on the Application's part?

Not sure how to go about dealing with the fact that the wrong receive connector is being used (this doesn't happen with our network scanner for instance, I checked), and I'm still unsure of the reason why no mail is being received when using the virtual SMTP setup on the SQL box. As I say, mail to a gmail account is received when using the SQL's virtual SMTP setup, but nothing is received by our exchange mail accounts...

Any ideas guys? Much, much appreciated for the help thus far by the way, I also applied the anonymous auth fix Andy100 mentioned on my "Internal SMTP" connector, but I really don't want to do it on the "Default EXCHSVR" connector as it's for all IP's 0.0.0.0-255.255.255.255. For anyone else curious about the anonymous auth fix, this is the powershell command:

Get-ReceiveConnector “Receive Connector Name” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Cheers guys!

 

[EvilGrin]

Yeah, the AD domain is "companyname.local", I just went through and gave everything default names on the log.

Yeah, the FROM address is taken from the user that's logged into the application, so it'll be [email protected] - do you think this could cause issue too? Mind you, from the log, the telnet connection is obviously not quite getting far enough to apply the FROM yet as it falls over at HELO.

Yeah my Client and Default connector settings are pretty much identical to yours except for me client is set to 587, default is 25. Then additionally to that I have my "Internal SMTP" connector which is set specifically for my SQL server's IP only and other than that the settings are the same as "Default EXCHSVR".

I've sent an email to the application's project manager with the logs showing him that there's this superfluous space after the SQL server name during HELO, so will see what he says to that! I'm still puzzling about this bloody virtual SMTP connector though, have no idea why it works sending mail externally, I even set it to route to our smart host if internal routing fails!

 

[EvilGrin]

Well, the plot thickens... Had a reply from the application dev's:

"Hi,

Yes we’re aware of this issue when linking to your MS Exchange 2007 box hence why we’ve gone down the route of setting up a standalone SMTP service on the SQL box in order to route the traffic from the application in the meantime.

Do you have any ideas why I receive the mail when using this service and your internal clients don’t?"

Frankly, I'm raging that they haven't admitted to this bug before, even though they've had ample opportunity to and have had the gall to put the onus on me to get it working even though it's a flaw in their bloody software!

I'd love to throw this back in their face and say "Hey, it's your problem, you've hidden information from me that's cost me at least a day's worth of work, so back over to you.", but the sad reality is that if I don't get the bloody thing working, they sure as hell won't.

So... my problem changes from Exchange SMTP relay to the Virtual SMTP relay on the SQL server. Sigh.

This is what I've pulled from the logs:

2010-09-06 12:47:24 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 HELO - +SQLSVR 250 0 33 15 0 SMTP - - - -
2010-09-06 12:47:24 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 MAIL - +FROM:<[email protected]> 250 0 57 44 0 SMTP - - - -
2010-09-06 12:47:24 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 RCPT - +TO:<[email protected]> 250 0 45 42 0 SMTP - - - -
2010-09-06 12:47:24 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 DATA - <SQLSVR2iz2Mb1s7n00000027@sqlsvrIP> 250 0 122 98953 32 SMTP - - - -
2010-09-06 12:47:24 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 QUIT - SQLSVR 240 47 58 4 0 SMTP - - - -

2010-09-06 12:48:58 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 HELO - +SQLSVR 250 0 33 15 0 SMTP - - - -
2010-09-06 12:48:58 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 MAIL - +FROM:<[email protected]> 250 0 57 44 0 SMTP - - - -
2010-09-06 12:48:58 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 RCPT - +TO:<[email protected]> 250 0 31 28 0 SMTP - - - -
2010-09-06 12:48:58 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 DATA - <SQLSVRdyDd3OJXsN00000028@sqlsvrIP> 250 0 122 99317 31 SMTP - - - -
2010-09-06 12:48:58 sqlsvrIP SQLSVR SMTPSVC1 SQLSVR sqlsvrIP 0 QUIT - SQLSVR 240 47 58 4 0 SMTP - - - -

2010-09-06 12:48:58 209.85.229.27 OutboundConnectionResponse SMTPSVC1 SQLSVR - 25 - - 220+mx.google.com+ESMTP+d9si6883831wbe.64 0 0 41 0 31 SMTP - - - -
2010-09-06 12:48:58 209.85.229.27 OutboundConnectionCommand SMTPSVC1 SQLSVR - 25 EHLO - sqlsvrIP 0 0 4 0 31 SMTP - - - -
2010-09-06 12:48:58 209.85.229.27 OutboundConnectionResponse SMTPSVC1 SQLSVR - 25 - - 250-mx.google.com+at+your+service,+[80.76.124.49] 0 0 49 0 62 SMTP - - - -
2010-09-06 12:48:58 209.85.229.27 OutboundConnectionCommand SMTPSVC1 SQLSVR - 25 MAIL - FROM:<[email protected]>+SIZE=99624 0 0 4 0 62 SMTP - - - -
2010-09-06 12:48:58 209.85.229.27 OutboundConnectionResponse SMTPSVC1 SQLSVR - 25 - - 250+2.1.0+OK+d9si6883831wbe.64 0 0 30 0 93 SMTP - - - -
2010-09-06 12:48:58 209.85.229.27 OutboundConnectionCommand SMTPSVC1 SQLSVR - 25 RCPT - TO:<[email protected]> 0 0 4 0 93 SMTP - - - -
2010-09-06 12:48:58 209.85.229.27 OutboundConnectionResponse SMTPSVC1 SQLSVR - 25 - - 250+2.1.5+OK+d9si6883831wbe.64 0 0 30 0 578 SMTP - - - -
2010-09-06 12:48:58 209.85.229.27 OutboundConnectionCommand SMTPSVC1 SQLSVR - 25 DATA - - 0 0 4 0 578 SMTP - - - -
2010-09-06 12:48:58 209.85.229.27 OutboundConnectionResponse SMTPSVC1 SQLSVR - 25 - - 354++Go+ahead+d9si6883831wbe.64 0 0 31 0 609 SMTP - - - -
2010-09-06 12:48:59 209.85.229.27 OutboundConnectionResponse SMTPSVC1 SQLSVR - 25 - - 250+2.0.0+OK+1283777278+d9si6883831wbe.64 0 0 41 0 968 SMTP - - - -
2010-09-06 12:48:59 209.85.229.27 OutboundConnectionCommand SMTPSVC1 SQLSVR - 25 QUIT - - 0 0 4 0 968 SMTP - - - -
2010-09-06 12:48:59 209.85.229.27 OutboundConnectionResponse SMTPSVC1 SQLSVR - 25 - - 221+2.0.0+closing+connection+d9si6883831wbe.64 0 0 46 0 1000 SMTP - - - -


So, it seems like the connection is being made for gmail, but just nothing at all happens with our exchange mail? Is there any way I can trace or tell whether the email is being sent out, I just have no idea how to track this!

 

[EvilGrin]

Another piece of the puzzle, found an event 4000 error in SMTPSVC on the SQL server:

"Message delivery to the remote domain 'company.com' failed for the following reason: Unable to bind to the destination server in DNS."

So, DNS resolution issue? Both SQL and Exchange servers use our file server (domain DC/GC) as their DNS server, both server names are defined in A records in the forward lookup zone under "company.local", but is this looking for an A record/IP address for "(same as parent folder)" under "company.com", rather than "company.local" as indicated in the error? I'm confused...

 

[EvilGrin]

Well, I've got it fixed... kinda.

Added my ISP's DNS server to secondary list on the SQL server's network adapter alongside my DC's IP, and all the test emails flowed through within 10 seconds after a flush/register. HMMM. Problem with my DNS config then? Seems that way...

As for the telnet test above, here's the result:

250 sqlsvrIP Hello [sqlsvrIP]
mail from: [email protected]
250 2.1.0 [email protected]er OK
rcpt to: [email protected]
250 2.1.5 [email protected]
data
354 Start mail input; end with <CRLF>.<CRLF>
test
.
250 2.6.0 <SQLSVR4FXPvfRHFf00000039@sqlsvrIP> Queued mail for delivery

Thanks a lot so far guys, you've been a great help!

 

[EvilGrin]

So the likelihood is it's a DNS issue (as backed up by the event you found as well). If you check the DNS management console on your primary DNS (your DC I assume from what you're saying) and look for the forward look up zone of your target domain, does it have an MX record associated with it? if not you may need to create one and set it to your domains normal MX record according to the internet to allow mail to flow to you.

Thanks mate, yeah, we were missing our internal MX record on the DNS server, I added it in, removed the external ISP DNS server entry on the network adapter of the SQL server and all works just fine, so that's great.

I have also vented my frustrations at our application dev's, so I'm feeling pretty damn good about myself right now. Haha.

Cheers guys!