Exchange 2007 internal SMTP Relaying from Application Server - Help!

EvilGrin

EvilGrin

EvilGrin

Associate
Joined
12 Oct 2004
Posts
1,432
Location
Aberdeen, Scotland
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!
 
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?
 
Penguin said:
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?
Click to expand...

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.
 
Exchange 2007 won't by default allow anonymous relaying even if you've unticked all of the authentication methods. You're on the right track, all you have to do now is run a script in the exchange powershell to allow anonymous relaying.

On my iPhone so don't have it on me but if you google anonymous relay exchange 2007 you should get some hits with the command.

Edit: anon relaying from every ip on your network is a really bad idea. Lock it down to specific ip's.
 
Last edited:
Ah that little issue.

We had something similar.

What you need to check is the FROM address your app is sending the email from.

Ex2007 will not relay if the from address is not correctly formatted. So a from address of reports would fail but [email protected] will work fine

Kimbie
 
Correct me if i'm wrong but if you've setup the SMTP service on the SQL box, does it accept mail for your internal domain? it could be blackholing it and trying to deliver to the SQL server instead of hitting your Exchange server.

I'd suggest configuring SMTP logging on your SMTP Virtual Server on the SQL box if you can as well to get a better indication of what it's doing, from memory you have to go into the VS properties and find the logging bit, then tick pretty much everything :)
 
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!
 
Is the name of your active directory domain "domain.local" or is it your company name?

Have you checked the FROM address that the application server is sending?

My connectors are setup as follows:


Client MAILSRV1 Properties

General Tab

Protocol logging none
FQDN is mailsrv1.ourdomain.co.uk
Max Message Size 15360

Network Tab

Use these local IP addresses:
All available IP6 and IP4 on port 587

Receive mail from remote servers
0.0.0.0-255.255.255.255
and the IP6 one

Authentication Tab

Everything is ticked APART from:

Enable Domain Security (Mutual Auth TLS)
Exchange Server authentication
Externally secured

Permission Groups

Only these ticked:

Exchange users
Exchange servers

Default MAILSRV1 Properties

General Tab

Protocol logging none
FQDN is mailsrv1.ourdomain.co.uk
Max Message Size 15360

Network Tab

Use these local IP addresses:
All available IP6 and IP4 on port 587

Receive mail from remote servers
0.0.0.0-255.255.255.255
and the IP6 one

Authentication Tab

Everything is ticked APART from:

Enable Domain Security (Mutual Auth TLS)
Externally secured

Permission Groups

All ticked apart from "Partners"

Hope this helps in some way

Kimbie
 
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!
 
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!
 
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 said:
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!
Click to expand...

It still looks to me like your SQL server is accepting mail for your domain, as it's making an external connection for gmail.com but doesn't appear to be for your others.

If you run the following from your SQL server what's the result?:

Start > run > cmd > Enter

telnet 127.0.0.1 25

<at the telnet prompt>

Helo X (replace X with whatever)
mail from: [email protected]
rcpt to: [email protected]

If it says 250 OK then it accepts mail for the domain and won't relay out to it externally unless configured to do so.

Also worth checking your DNS and MX record config.

From the SQL server:

Start > run > cmd > Enter

nslookup

<It should display what DNS server it's using here btw>

set type=mx

domainyouwanttosendmailto.com. (the dot is there on purpose so add it)

It should tell you what the MX records are for your domain as far as it's concerned, as the MX is used for mail delivery it could be pertinent to your situation if it can't find any on your DNS.
 
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!
 
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.
 
Eulogy said:
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.
Click to expand...

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!
 
You must log in or register to reply here.
Back
Top Bottom