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: John on 28 May 2010 13:05 Exchange 2003 SP2 running on Windows 2003 R2 SP2 I got the following NDR when I sent a message to JDoe at recipientdomain.com (not the real address): The following recipient(s) cannot be reached: 'JDoe(a)recipientdomain.com' on 5/27/2010 5:34 PM There was a SMTP communication problem with the recipient's email server. Please contact your system administrator. <my-exchange-internal-name.mydomainname.com #5.5.0 smtp;554 Denied (Mode: normal)> I was able to send JDoe an email a few days ago but now it bounces back to me with the above message. I've checked my Exchange server (external) IP address at mxtoolbox.com. All of them show OK (3 of the results show TIMEOUT). 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?
From: Rich Matheisen [MVP] on 28 May 2010 13:28 On Fri, 28 May 2010 10:05:29 -0700, "John" <a> wrote: >Exchange 2003 SP2 running on Windows 2003 R2 SP2 > >I got the following NDR when I sent a message to JDoe at recipientdomain.com >(not the real address): > >The following recipient(s) cannot be reached: > 'JDoe(a)recipientdomain.com' on 5/27/2010 5:34 PM > There was a SMTP communication problem with the recipient's >email server. Please contact your system administrator. > <my-exchange-internal-name.mydomainname.com #5.5.0 smtp;554 >Denied (Mode: normal)> > >I was able to send JDoe an email a few days ago but now it bounces back to >me with the above message. I've checked my Exchange server (external) IP >address at mxtoolbox.com. All of them show OK (3 of the results show >TIMEOUT). > >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? Only the admin at the receiving MTA knows why they send a 554 status. There's no meaningful information in the text part of the status. Could it be that your server is incorrectly identifying itself? Sure. Fix it and see it it makes the problem go away. If it doesn't, find someone at the other domain and call them, or use a hotmail, yahoo, aol, etc. account and e-mail them. --- Rich Matheisen MCSE+I, Exchange MVP
From: M on 28 May 2010 13:52 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 "John" <a> wrote in message news:uMcy6fo$KHA.1888(a)TK2MSFTNGP05.phx.gbl... > Exchange 2003 SP2 running on Windows 2003 R2 SP2 > > I got the following NDR when I sent a message to JDoe at > recipientdomain.com (not the real address): > > The following recipient(s) cannot be reached: > 'JDoe(a)recipientdomain.com' on 5/27/2010 5:34 PM > There was a SMTP communication problem with the recipient's > email server. Please contact your system administrator. > <my-exchange-internal-name.mydomainname.com #5.5.0 smtp;554 > Denied (Mode: normal)> > > I was able to send JDoe an email a few days ago but now it bounces back to > me with the above message. I've checked my Exchange server (external) IP > address at mxtoolbox.com. All of them show OK (3 of the results show > TIMEOUT). > > 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? >
From: John on 28 May 2010 14:08 "Rich Matheisen [MVP]" <richnews(a)rmcons.com.NOSPAM.COM> wrote in message news:r2vvv5hvho69oi90jempdth1cfdbl0bn13(a)4ax.com... > > Only the admin at the receiving MTA knows why they send a 554 status. > There's no meaningful information in the text part of the status. Does the following SMTP log from my server help? 220+ I REMOVED THIS PART;+Thu,+27+May+2010+18:34:25+-0600+(MDT);+NO+UCE,+INBOUND 129 0 62 EHLO my-exchange-internal-name.mydomainname.com 4 0 62 250-THEIRSERVER.THEIRDOMAIN.COM 26 0 125 MAIL FROM:<Me(a)mydomainname.com> 4 0 125 250+Sender+Ok 13 0 187 RCPT TO:<JDoe(a)recipientdomain.com> 4 0 187 250+JDoe(a)recipientdomain.com+ok+(RCPTMode:+normal/deferred) 49 0 531 DATA - 4 0 531 354+Start+mail+input;+end+with+<CRLF>.<CRLF> 44 0 593 554+Denied+(Mode:+normal) 25 0 1703 QUIT - 4 0 1734 > Could it be that your server is incorrectly identifying itself? Sure. > Fix it and see it it makes the problem go away. If it doesn't, find > someone at the other domain and call them, or use a hotmail, yahoo, > aol, etc. account and e-mail them. Is this the correct location? ESM - Administrative Group - MyAdminGroup - Servers - my-exchange-internal-name - Protocols - SMTP - Default SMTP Virtual Server - (right click) Properties - Delivery (tab) - Advanced (button) - Fully-qualified domain name: Currently showing: my-exchange-internal-name.mydomainname.com Is this the correct field to change so that my Exchange identifies itself as mail. blah blah (it matches the PTR record)? Thank you very much for your quick reply.
From: John on 28 May 2010 15:15
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 > |