What's Causing this Bounced Mail?
in [Microsoft Exchange]
|
Prev: Can't run Exchange Management Shell - type initializer excepti
Next: Can not Email 17mb file outside our SMTP connector
From: M on 1 Jun 2010 19:00 The correct terminology is that the external DNS record for you Exchange server doesn't match the server's Virtual SMTP Server FQDN. I'm not 100% sure this is the reason. It could be, but I wouldn't go making any changes just yet. One of my previous posts has the instructions for changing the FQDN if you truly need to do that. Yes, changing your external DNS record to match the VSMTPS FQDN would accomplish the same thing, but in most cases, your internal DNS suffix is not unusable externally (ie, some companies use .ad, .local or something like that for their internal AD) so that wouldn't work. If you're only having issues with this one domain, I would wait to hear back from their admin. The fix could be something as simple as them whitelisting your IP addresses. On a related note, you should consider getting some type of appliance to handle Internet e-mail to provide a layer of protection for your Exchange server. -- Regards, M MCTS, MCSA http://SysAdmin-E.com "John" <a> wrote in message news:OPmSoCcALHA.5476(a)TK2MSFTNGP06.phx.gbl... >I have not heard anything from the recipient's mail administrator. > > Going back to my original suspicion shown below: > > Could this issue be related to the fact that my PTR record is > "mail.mydomainname.com" but my SMTP identifies itself as > "my-exchange-internal-name.mydomainname.com" in ehlo command? If that is > true, how can I correct this? > > Instead of makes changes to my Exchange server settings, what if I change > the (publib) DNS settings from "mail" to "my-exchange-internal-name"? I > suppose that'll accomplish the same thing, won't it? > > Thanks again. > > > "M" <m(a)nowhere.com> wrote in message > news:%23bYO29p$KHA.5808(a)TK2MSFTNGP02.phx.gbl... >> Ok. Let us know what happens. If you haven't done so, I would suggest >> that you ask the recipient to put in a helpdesk ticket on his or her end >> and request that it be routed to the group that manages the e-mail >> system. This would obligate the recipient's sys admin to help you. If you >> haven't made any recent server or network changes, then the issue could >> be on their end. Either way, it would be helpful if they could check >> their server logs and see why some of your messages got NDR'd. >> >> -- >> Regards, >> M >> MCTS, MCSA >> http://SysAdmin-E.com >> >> "John" <a> wrote in message >> news:%231eYrop$KHA.5808(a)TK2MSFTNGP02.phx.gbl... >>> Thank you for your explanation. Yes I can telnet from my mail server to >>> their mail server IP address and issue all EHLO, MAIL FROM, RCPT TO, >>> DATA commands without any problem. I just did a telnet test. It went >>> through just fine with the last 2 messages shown below: >>> >>> 250 Backend Replied >>> [4h3f0c4.0.235641.00-105.306933.pc062.theirdomain.com]: Ok (Mode: >>> normal) >>> 221 pc062.theirdomain.com Service closing transmission channel >>> [235641.00] >>> >>> Here's what I found more: >>> Since I posted my question, I've sent them multiple messages with >>> Outlook 2007, only 1 got through. The rest bounces back to me. >>> >>> At this moment, I can only troubleshoot my own server. The next step is >>> to contact their mail admin before making any changes to my mail server. >>> I'm crossing my fingers that they want to help troubleshoot the problem >>> instead of dismissing it as our server's fault. >>> >>> >>> "M" <m(a)nowhere.com> wrote in message >>> news:%23hnpK6o$KHA.3176(a)TK2MSFTNGP05.phx.gbl... >>>> Hello: >>>> >>>> First, contact someone at the recipient domain and see if they made any >>>> recent changes. They might have installed a new anti-spam system or >>>> had some network/server issues. >>>> >>>> You should check the RECIPIENT'S domain with MXToolbox since the >>>> NDR is stating that there was a communications problem between your >>>> servers and the >>>> recipient's. >>>> >>>> Can you telnet to port 25 of the IP addresses of the recipient's MX >>>> records? Maybe there's a >>>> network issue between you and the recipient. MXToolbox does the tests >>>> from their servers >>>> (their meaning MXToolbox) so they might not show any issues. >>>> >>>> If everything checks out, what you suggested as a cause is a >>>> possibility (I don't think PTR is the right term, >>>> but I know what you mean). I had what could be the same or similar >>>> issue, >>>> but the NDR was different (see below). My issue was fixed when I >>>> changed the >>>> FQDN of my Exchange SMTP Virtual Server to match the external host >>>> name. >>>> >>>> There's some debate about what I did, but once I made the change, it >>>> corrected my issue. This might not be related to your issue, but >>>> sometimes >>>> NDRs are not very clear on what exactly the issue is, so you'd need to >>>> try a >>>> few things. >>>> >>>> bob(a)abc.com on 3/9/2009 2:24 PM >>>> You do not have permission to send to this recipient. For >>>> assistance, contact your system administrator. >>>> <ex01.mydomain.com #5.7.1 smtp;554 5.7.1 >>>> <ex01.mydomain.com>: >>>> Helo command rejected: Host not found> >>>> >>>> Here are some notes that I made when I fixed my issue: >>>> ----------------- >>>> Go to the SMTP VS properties --> Delivery tab --> Advanced button. The >>>> FQDN >>>> is what shows up in the message headers. It appears that some recipient >>>> systems will reject messages if the FQDN of the sending SMTP server is >>>> not a >>>> valid server for the sending domain. >>>> >>>> This doesn't make a lot of sense as to why the recipient system would >>>> bother >>>> making sure that the sending server's hostname matches a reverse DNS >>>> lookup. >>>> As long as the IP address of the sending system matches what's in the >>>> MX or >>>> SPF records, that should overrule the hostname discrepancy. A hostname >>>> is >>>> obviously much easier to spoof than an IP address. But apparently some >>>> anti-spam systems check for this and won't accept mail if there's a >>>> discrepancy between the sending hostname and the reverse DNS lookup of >>>> its >>>> IP address. >>>> >>>> Under "Myth 3b: Modifying The FQDN of the SMTP Virtual Server" on >>>> http://msexchangeteam.com/archive/2005/02/25/380481.aspx, it advises >>>> against >>>> changing the FQDN of the default SMTP VS. If you do go ahead and change >>>> the >>>> FQDN, the SMTPSVC SPN must be updated for the server's AD object to >>>> reflect >>>> the change per >>>> http://technet.microsoft.com/en-us/library/aa996905%28EXCHG.80%29.aspx. >>>> Note >>>> that the change can be made using ADSIEdit to edit the >>>> servicePrincipalName >>>> attribute (I've personally done this). >>>> >>>> The reply to this posting states that best practice is to the leave the >>>> FQDN >>>> as is. (Doing that would not resolve the NDR issue then, and I don't >>>> see why >>>> it should not be changed if the field is changeable. If best practice >>>> is to >>>> leave it alone, then why does MS even make the field changeable?): >>>> http://forums.msexchange.org/m_1800493025/mpage_1/key_/tm.htm#1800493025 >>>> ----------------- >>>> >>>> If you don't want to make any changes, then ask the recipient domain's >>>> sys >>>> admin to whitelist your mail servers and see if that corrects the >>>> issue. >>>> >>>> -- >>>> Regards, >>>> M >>>> MCTS, MCSA >>>> http://SysAdmin-E.com >>>> >>> >>> >> >> > >
From: John on 1 Jun 2010 20:09 Thanks again M. "M" <m(a)nowhere.com> wrote in message news:%23yEIA5dALHA.3608(a)TK2MSFTNGP05.phx.gbl... > Yes, changing your external DNS record to match the VSMTPS FQDN would > accomplish the same thing, but in most cases, your internal DNS suffix is > not unusable externally (ie, some companies use .ad, .local or something > like that for their internal AD) so that wouldn't work. Well, in my case, the internal domain name ends with .com (matches the registered public domain name). I figure it's just a modifiable name so this may be a safer choice compared to changing my Exchange settings. Am I right?
From: M on 3 Jun 2010 11:59
Yes, that does seem like the safer choice. So basically you have something like this now: external DNS host is mail.some-domain.com and your internal Exchange SMTP VS FQDN is exchange.some-domain.com? So you propose to make your external DNS host name exchange.some-domain.com? If that's the case, it shouldn't break anything if done properly. Check with your external DNS provider to see what's involved and any possible issues. I would then make mail.some-domain.com an alias pointing to exchange.some-domain.com for backwards compatibility. -- Regards, M MCTS, MCSA http://SysAdmin-E.com "John" <a> wrote in message news:ulD1vfeALHA.980(a)TK2MSFTNGP04.phx.gbl... > Thanks again M. > > "M" <m(a)nowhere.com> wrote in message > news:%23yEIA5dALHA.3608(a)TK2MSFTNGP05.phx.gbl... >> Yes, changing your external DNS record to match the VSMTPS FQDN would >> accomplish the same thing, but in most cases, your internal DNS suffix is >> not unusable externally (ie, some companies use .ad, .local or something >> like that for their internal AD) so that wouldn't work. > > Well, in my case, the internal domain name ends with .com (matches the > registered public domain name). I figure it's just a modifiable name so this > may be a safer choice compared to changing my Exchange settings. Am I right? > > |