2010 - Sending to domains with secondary MX records require anything special?
Greetings, I had a user complain this morning about not being able to send mail to a domain whose DNS looks ... "wonky" ... to say the least and they apparently are having issues with their primary mail server which does not respond at the moment. I CAN pass mail to them through my GroupWise mail system but for some reason Exchange is rejecting them and kicking back a failure notice. Both of my systems relay in and out through a forward-facing M+Guardian server. - Exchange is not handing mail for this questionable domain off to M+ for delivery but GroupWise is.. I'm pretty new to Exchange.. - Is there something I should set to get Exchange to see the secondary MX and hand it off to M+? Thanks! Norm
July 12th, 2010 10:18pm

Define "wonky". Please be specific and provide a real example. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "Norm Allen" wrote in message news:84e950ab-0ad2-4c05-84ea-1eb48d9bf952... Greetings, I had a user complain this morning about not being able to send mail to a domain whose DNS looks ... "wonky" ... to say the least and they apparently are having issues with their primary mail server which does not respond at the moment. I CAN pass mail to them through my GroupWise mail system but for some reason Exchange is rejecting them and kicking back a failure notice. Both of my systems relay in and out through a forward-facing M+Guardian server. - Exchange is not handing mail for this questionable domain off to M+ for delivery but GroupWise is.. I'm pretty new to Exchange.. - Is there something I should set to get Exchange to see the secondary MX and hand it off to M+? Thanks! Norm Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
Free Windows Admin Tool Kit Click here and download it now
July 12th, 2010 10:22pm

Please disregard the "wonky".. - Their MX records are fine and suit the purpose of my question. Again, GroupWise has no issue passing the message off to M+ which has no issue sending to the secondary MX. Exchange does not hand off delivery to M+ and generates an undeliverable. Exchange has been in place for roughly 3 months, this is the first and only occurrence of sending to a (somewhat) functional domain known to have any issue. Also: SPF is not in place on either system.
July 12th, 2010 11:31pm

On Mon, 12 Jul 2010 20:31:43 +0000, Norm Allen wrote: > > >Please disregard the "wonky".. - Their MX records are fine and suit the purpose of my question. > > > >Again, GroupWise has no issue passing the message off to M+ which has no issue sending to the secondary MX. > > > >Exchange does not hand off delivery to M+ and generates an undeliverable. So "M+" is acting as a smart host? Your Exchange Send Connector sends all e-mail to "M+" and "M+" delivers it to the target domain? What's the contents of the Send Connector's "Address Space" tab? How about posting the NDR? "Generates an undeliverable" doesn't provide any useful information. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP
Free Windows Admin Tool Kit Click here and download it now
July 13th, 2010 3:08am

Yes, M+ is acting as a smart host. Send connector address space is: SMTP * 1 Not sure why, but Exchange seems to be sending to the troubled domain this morning. - Their primary MX is still down. I was hoping to pick off a bounce myself since the original complaint was from an end user who didn't forward me a full NDR... - I went right to checking the smart host for activity and then checking the domain since messages from GroupWise were making their way thru. Perhaps the smart host wasn't being smart. - Not sure, but thanks anyway. Norm
July 13th, 2010 6:11pm

As I remind my users, if you get an NDR (Non Delivery Report), include that in these sections, as it (Usually) makes clear what is failing and where. I would also be curious as to how do you know for sure Exchange isn't bypassing your M+ server and attempting to connect directly outside? It seems if one mail system can send but another can not, it would be the place they commonly attempt to send to which really is your "smart host". Just my thoughts. Good luck!
Free Windows Admin Tool Kit Click here and download it now
July 13th, 2010 7:31pm

On Tue, 13 Jul 2010 15:11:12 +0000, Norm Allen wrote: >Yes, M+ is acting as a smart host. > >Send connector address space is: SMTP * 1 > > > >Not sure why, but Exchange seems to be sending to the troubled domain this morning. - Their primary MX is still down. Exchange shouldn't sending to "the troubled domain" at all. It should be sending to the smart host. The smart host should be sending to the target server. Exchange is either not using your smart host, or your smart host is refusing the e-mail from Exchange (which is why I asked for the contents of one of the NDRs). Try running this and see if you have everything set the way you expect it to be: Get-SendConnector |fl name,addressspaces,smarthosts,smarthostsstring >I was hoping to pick off a bounce myself since the original complaint was from an end user who didn't forward me a full NDR... Okay . . . but your SMTP protocol log files would have the conversation with the machine that either generated the NDR or the machine that sent the NDR. If you don't see an error status code (either 4xx or 5xx) in the SMTP log then Exchange wasn't the one talking to the target host. >- I went right to checking the smart host for activity and then checking the domain since messages from GroupWise were making their way thru. > >Perhaps the smart host wasn't being smart. - Not sure, but thanks anyway. Your SMTP log files will tell all. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP
July 14th, 2010 12:02am

Thanks Rich, I'll check those out and see if I can trace back what was going on. I have seen both inbound and outbound activity to/from Exchange on the smart host so I'm not sure how Exchange would use the smart host one time and not another. Its certainly not how I would want it configured at least.. I'll try to dig into it tomorrow and if I learn anything, give an update. Thanks again, Norm
Free Windows Admin Tool Kit Click here and download it now
July 14th, 2010 3:28am

Ok, now this is odd.... The Send Connector still looks good looking @ it from the shell vs EMC.. Its clear that all is set to go to the smart host, no confusion there. But the SmtpSend log file path is empty. - SmtpReceive has a months worth of transactions to review but the send directory doesn't have a single log file in it. HTTPClient is empty as well, not sure if thats supposed to be the log path for OWA transactions or not (which is in place and appears to be working fine) but yeah, SmtpSend is empty so tracking this problem report back to isolate the fault is looking even more challenging than 1st thought.. And yes, the log file path for SmtpSend is defined and correct In EMC / Server Conf / Server / Properties / Log Settings But, "Server Diagnostic Logging Properties" on SmtpSend is set to Lowest but then so is SmtpReceive. - Does it need to be bumped up to one of the other 4 or 5 higher levels in order to create a log at all?? Whats really odd is that the smart host doesn't show anything in its logs coming from Exchange for the problem message(s) either (but other traffic at that time is there) which is what lead me to the assumption that the issue was with Exchange. Are there other places I should be looking at log settings for SmtpSend?? Thanks again, Norm
July 14th, 2010 5:47pm

On Wed, 14 Jul 2010 14:47:15 +0000, Norm Allen wrote: > > >Ok, now this is odd.... > >The Send Connector still looks good looking @ it from the shell vs EMC.. Its clear that all is set to go to the smart host, no confusion there. > > > >But the SmtpSend log file path is empty. - SmtpReceive has a months worth of transactions to review but the send directory doesn't have a single log file in it. HTTPClient is empty as well, not sure if thats supposed to be the log path for OWA transactions or not (which is in place and appears to be working fine) but yeah, SmtpSend is empty so tracking this problem report back to isolate the fault is looking even more challenging than 1st thought.. > >And yes, the log file path for SmtpSend is defined and correct In EMC / Server Conf / Server / Properties / Log Settings Are the permissions on the SmtpSend and SmtpReceive directores the same? Is logging set to "verbose"? Get-SendConnector |ft name,ProtocolLoggingLevel -auto >But, "Server Diagnostic Logging Properties" on SmtpSend is set to Lowest but then so is SmtpReceive. - Does it need to be bumped up to one of the other 4 or 5 higher levels in order to create a log at all?? No. Protocol and diagnostic logging aren't the same thing. >Whats really odd is that the smart host doesn't show anything in its logs coming from Exchange for the problem message(s) either (but other traffic at that time is there) which is what lead me to the assumption that the issue was with Exchange. How many Send Connectors do you have in your organization? >Are there other places I should be looking at log settings for SmtpSend?? No. The value's kept in the AD. But if you want to check: Get-TransportServer | fl --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP
Free Windows Admin Tool Kit Click here and download it now
July 15th, 2010 4:14am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics